Вайбкодинг на практике: опыт разработки, траты на токены и выводы

Подробности изложены в материале первоисточника. Данный материал — это личный и субъективный опыт работы с современными AI-агентами, написанный от лица разработчика, который решил собрать крупный проект с нуля. Я не причисляю себя к радикалам, считающим вайбкодинг абсолютным злом или, напротив, манной небесной. Моя цель — честно рассказать о применении автономных инструментов, организации процессов, реальных затратах и тех подводных камнях, с которыми неизбежно сталкиваешься, когда нейросеть выдает тысячу строк кода каждые полчаса.

Мой путь в IT начался еще со школы со стека на базе документации и форумов, а к третьему курсу направления ИВТ я подошел с твердым намерением испытать передовые агентские среды. Вместо шаблонного резюме я решил довести до ума учебный проект по созданию умного университетского ассистента с базой данных и RAG-поиском. На старте мы с коллегой действовали вручную, но после того как проект перешел ко мне одному, я полностью переключился на ИИ-инструменты.

О чем эта статья

Подробности этого пути читайте далее в моем материале.

Что такое вайбкодинг на практике

Основываясь на личном опыте, я формулирую вайбкодинг как процесс написания программного обеспечения с помощью LLM, при котором сам код практически не проверяется человеком или анализируется очень бегло. Если вы просто копируете куски текста из браузерного чата, это еще не настоящий вайбкодинг. Полноценные агентские среды берут на себя гораздо больше рутины: они самостоятельно читают файлы, запускают bash-скрипты, используют MCP и выстраивают логику без ежеминутного вмешательства человека.

На раннем этапе мы тестировали базовые возможности моделей для взаимодействия с базами данных, и стало очевидно, что автоматизация сокращает время выполнения рутинных задач с дней до считанных минут. Именно тогда я начал тестировать различные среды, стремясь найти инструмент, способный работать быстро и эффективно.

Для работы мне требовалась среда, которую потянет относительно скромное железо вроде MacBook Air на M2, но при этом она должна была предоставлять полный набор инструментов для автономной разработки.

Агентская обвязка и выбор среды

Чтобы модель могла читать файлы и выполнять команды, ей необходима правильная обвязка. Архитектура современных агентов строится на строгой логике: ИИ генерирует типизированный JSON на основе системного промпта и описания инструментов, после чего программа валидирует этот вызов, выполняет действие и возвращает результат вместе с историей диалога обратно в модель.

На рынке существует множество готовых решений, каждое из которых обладает своими достоинствами и недостатками:

• Codex: имеет приятное нативное приложение для macOS, но страдает от громоздкой виртуальной среды, о которую модель постоянно спотыкается, тратя токены впустую.
• Claude Code: минималистичное и подробное CLI-решение, однако оно жестко привязано к моделям Anthropic, а непрозрачные лимиты отталкивают от покупки подписки.
• Vibe (Mistral), Gemini-cli и Qwen Coder: аналоги Claude Code под собственные линейки моделей с приятными бесплатными лимитами, но пока еще недостаточно продвинутые для сложных архитектурных задач.
• Zcode: разработка на базе GLM со встроенным браузером для тестирования фронтенда, но без избыточного виртуального окружения.
• Hermes: мощная система на «стероидах» с поддержкой CLI и нативных приложений, требующая тщательной настройки под конкретные задачи.
• Manus: китайская разработка с изолированными контейнерами, которая отлично справляется с изоляцией задач, но скрывает слишком много процессов от глаз разработчика.
• Pi: мой осознанный выбор. Это аналог Arch Linux в мире агентских сред — максимально минималистичная база (чтение, запись, редактирование, bash), поверх которой вы сами выстраиваете нужную конфигурацию и подключаете любых провайдеров.

Модели, выбор железа и расходы на токены

Главный вопрос при построении рабочего процесса — какую модель использовать. Полноценные подписки стоят от 18–20 долларов в месяц и выше, но страдают от внезапных ограничений токенов. Локальный инференс на потребительских видеокартах или памяти ноутбука упирается в пропускную способность шины: для комфортной работы агента требуется высокая скорость и большой объем KV-кэша, иначе генерация затягивается на непозволительно долгое время.

В итоге самым разумным вариантом с точки зрения доступа к передовым возможностям оказалась покупка токенов через API. Мой выбор пал на связку Pi с моделями DeepSeek V4 Flash (а позднее GLM-5.3 Flash и DeepSeek V4.1). За время активной разработки через панель провайдера прошло более 6 000 рублей. В среднем на старых тарифах уходило от 150 до 300 рублей в день, однако после резкого скачка цен пришлось активнее переключаться на временные акции и бесплатные лимиты.

При выборе облачных моделей бенчмарки часто вводят в заблуждение, а провайдеры могут незаметно подменять версии ради экономии. Поэтому важнее ориентироваться на соотношение цены, архитектурных особенностей дистиллированных моделей и их реального поведения при решении сложных задач. Топовые модели имеют смысл для декомпозиции и поиска концептуальных решений, тогда как для чернового написания кода вполне хватает доступных эффективных моделей.

Проблема первая: недостаток внимания и умственный долг

Когда проект успешно собирается и работает, у разработчика незаметно пропадает критическое восприятие кода. Поскольку агент справляется с рутиной, ты перестаешь досконально проверять каждый diff, доверяясь автоматике. Это приводит к фатальным ошибкам: когда код сталкивается со сложной нагрузкой, заложенная на самотек базовая логика генерации тулов из схемы базы данных полностью рассыпается.

В результате возникает так называемый «умственный долг» — аналог технического долга, но существующий исключительно в голове разработчика. Ты понимаешь, что сгенерированный код стал непрозрачным черным ящиком, но продолжаешь наращивать новые фичи, пока система окончательно не ломается, требуя сложнейшего рефакторинга.

Проблема вторая: документация для ИИ

На старте проекта хватает базового README, но по мере роста кодовой базы хаос нарастает лавинообразно. Обычный подход к написанию документации для людей здесь не работает: ИИ иначе воспринимает структуру файлов. Если позволить агенту бесконечно сжимать или переписывать объемные текстовые файлы с описанием сервисов, важная техническая информация будет потеряна.

Для решения этой проблемы я выделил отдельную директорию `docs/`, а в главном файле `AGENTS.md` прописал четкие указания, где именно хранится вся актуальная документация. Дополнительно пришлось внедрить проверку валидности ссылок внутри файлов через CI, чтобы агент не блуждал по устаревшим путям.

Проблема третья: слепая зона и избыточный код

Самая опасная ситуация возникает тогда, когда вы отдаете на откуп ИИ ту область, в которой сами разбираетесь поверхностно — например, верстку и фронтенд. Переложив задачу на агента и не проверяя его логику, я получил разросшийся файл `app.js` размером в три тысячи строк, в котором старый код не удалялся, а лишь обрастал костылями и пристройками.

Современные модели обладают высокой настойчивостью: если агент уходит в дебри и начинает совершать логические ошибки, он может игнорировать вопросы и продолжать портить кодовую базу. Для защиты от подобных инцидентов я настроил специальную прослойку безопасности (вроде `cc-safety-net`), которая физически запрещает агенту производить несанкционированные действия с критически важными файлами конфигурации.

Проблема четвертая: ограничения контекста трансформеров

Архитектура нейросетей устроена так, что модель видит каждый токен в сессии и удерживает его в KV-кэше. По мере удлинения диалога старые логи и диффы начинают смешиваться с актуальной информацией, что приводит к эффекту «lost in the middle», когда середина контекста используется хуже всего. Даже при большом контекстном окне модель может проигнорировать свежую документацию, полагаясь на уже заученные паттерны, что приводит к появлению архитектурно уязвимого кода.

Проблема пятая: ложные надежды на сторонние инструменты

Многочисленные плагины, графы знаний и MCP-модули, рекламируемые в сети, на практике часто оказываются малоэффективными. Модели не всегда используют сторонние расширения самостоятельно без постоянных напоминаний со стороны пользователя. Реальную пользу приносят лишь те кастомные скиллы и инструкции, которые вы пишете осознанно под конкретные боли своего проекта, тогда как скачанные из репозиториев универсальные пакеты чаще создают дополнительный шум.

Проблема шестая: решение кейса вместо общей задачи

Агент склонен решать узкий локальный кейс, описанный в промпте, совершенно не учитывая общую картину и семантику приложения. Если поставить задачу без предварительного проектирования, ИИ сгенерирует работающий в вакууме код, который полностью разрушит логику взаимодействия соседних микросервисов. Бороться с этим помогает строгая дисциплина: сначала составляется детальный план в формате Markdown, утверждается разработчиком, и только затем запускается написание кода.

Проблема седьмая: асинхронность и ветвистый код

Особенно остро проблемы проявляются в асинхронном коде со сложной ветвистой логикой. Поскольку LLM не имеет реального рантайма и не может оценить состояние удерживаемых локов или отмененных задач в памяти, она рассуждает умозрительно. На файлах длиннее тысячи строк агенты часто зацикливаются, бесконечно находя мнимые критические баги.

Против таких проблем не помогают обычные тесты — здесь требуются прицельные стресс-тесты, хаос-тестирование и профилирование под реальной нагрузкой. Личное понимание архитектуры ключевых классов экономит часы бесплодного ожидания исправлений от нейросети.

К чему я пришел: итоговые выводы и рекомендации

Обобщив полученный опыт, можно выделить несколько ключевых правил выживания при вайбкодинге:

• Никогда не беритесь за проект на технологиях, базу которых вы не понимаете лично.
• Не доверяйте ИИ проектирование бизнес-логики без предварительного ручного плана.
• Строго контролируйте команды, которые вызывает агент, особенно операции с системой контроля версий.
• Используйте браузерные чаты с фронтир-моделями в качестве аналитического наставника для проверки идей перед их передачей в агентскую среду в терминале.
• Внедряйте модульное тестирование, линтеры и pre-commit хуки с самого первого дня разработки.

Вайбкодинг не заменяет инженерное мышление, а лишь переносит разработчика из позиции написания кода в роль строгого архитектора и тестировщика. Сохранение личного контроля над ключевыми узлами системы остается единственным способом создать надежный продукт с помощью искусственного интеллекта.