Это вторая статья об использовании LLM в проекте разработки компилятора языка программирования как транспилятора в код на C++. Я продолжаю историю и хочу рассказать о своих наблюдениях и впечатлениях от попыток применять автономных агентов в большом и сложном проекте. А также о навязчивой рекламе и встроенных «закладках» в коде некоторых инструментов, которые, похоже, целенаправленно ухудшают работу с моделями конкурентов.

Спор о терминах: от «вайб-кодинга» к «вайб-инжинирингу»

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

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

Неотключаемая реклама в Cline и закладки против конкурентов

По мере роста кодовой базы проекта trust-lang я стал обращать внимание, что качество кода постепенно ухудшается. Это был ожидаемый, но очень неприятный момент, способный поставить крест на самой идее использования вайб-инжиниринга в крупных проектах. Ведь моя основная задача, это не пилить собственный проект, а наработать опыт использования LLM для продуктовых проектов компании.

И первая проблема, это периодически вылетающая неотключаемая реклама в расширении Cline, которым я пользуюсь в VSCode:

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

Но если сообщение о сложности запроса ещё как-то можно объяснить и появляется оно не так уж часто, то бороться с закладкой против моделей конкурентов в виде постоянно существующего бага значительно сложнее. А ведь именно она напрямую влияет на качество конечного результата.

Я экспериментировал с DeepSeek-4-flash, у которой размер входного контекста 1M, и заметил, что при работе он редко превышает 10% от заданной в конфигурации плагина величины. Поначалу я даже немного гордился собой: думал, что удалось так настроить проект и распределить кодовую базу по компонентам, что контекст используется очень оптимально.

Но, внимательно понаблюдав за ходом работы, понял: я не гений, а лох. Cline игнорирует установленный размер входного контекста и принудительно делает автокомпакт при достижении объёма чуть более 100K. Именно этим объясняется редкое превышение 10% от 1M входных токенов и резкое падение качества кода для длительных итераций, - контекст безжалостно сжимается, несмотря на существующие настройки.

Поиск решения обеих проблем подтвердил их реальное наличие. Даже нашлось несколько связанных issues на GitHub, но на текущий момент эти проблемы остаются нерешёнными, поэтому я решил, что настал хороший момент попробовать другие агенты и поэкспериментировать с автономным кодингом.

Автономный кодинг с помощью OpenHands

Поначалу начитавшись восторженных статей об использовании различных Claw-агентов, я пошёл именно по этому пути - попытаться настроить универсального агента для разработки кода. Однако через несколько дней безуспешных попыток выявилось фундаментальное противоречие: чем шире функциональность агента, тем ниже его качество в каждом узком сценарии и выше сложность его настройки и поддержки. Поэтому прекратил издевательства над собой с универсальными агентами и решил использовать готовые специализированные self-hosted агенты. И после непродолжительных экспериментов выбор пал на OpenHands.

OpenHands выигрывает сравнение по совокупности ключевых критериев. Это полностью открытая платформа под лицензией MIT с более чем 70 000 звёзд на GitHub, не привязывающая к одному вендору и позволяющая развернуть агента в собственной инфраструктуре с поддержкой любого LLM-бэкенда. Используется изолированная песочница Docker для выполнения кода и «из коробки» настроен рабочий процесс, максимально приближенный к поведению разработчика, который уже интегрированный для работы с GitHub без ручного вмешательства.

Агент реализует workflow, соответствующий обычным практикам работы в свободных проектах. Он не просто генерирует дифф, а самостоятельно создаёт ветку, коммитит изменения, оформляет Pull Request с осмысленным описанием и связывает его с Issue. И в отличие от Copilot, где разработчик должен копировать код в редактор и вручную открывать PR, OpenHands работает как полноценный участник репозитория, что делает историю коммитов чистой, а процесс - прозрачным для других участников.

При подключении к репозиторию, каждый запуск агента выполняется в отдельном Docker-контейнере. Это исключает ситуацию, когда сгенерированный код из непроверенной ветки получает неявный доступ к секретам CI/CD или переменным окружения. OpenHands не привязан к API одного провайдера. В конфигурации можно указать любую модель - от облачного Claude до локального Llama 3.1, развёрнутого через Ollama. Это гарантия того, что проект не встанет из-за изменения цен или отзыва доступа к конкретному AI-сервису.

Правда, с последним достоинством вылезла неожиданная сложность при подключении к некоторым LLM-провайдерам. В OpenHands тип API провайдера настраивается префиксом модели, например llm_model = "openai/model-name", а при формировании URL запроса к провайдеру этот префикс удаляется. Поэтому мне не сразу удалось настроить LLM-провайдер, и получилось разобраться в проблеме только после подключения к Bothub.ru, у которого API https://openai.bothub.ru/v1 не использует префиксы для типов моделей.

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

Грустные итоги автономного вайб-кодинга

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

Использование песочниц для разработки кода хоть и выглядит интересным, но на деле сильно мешает. В песочницу нужно устанавливать все необходимые инструменты для работы с кодом. И это может оказаться весьма нетривиальной задачей, если, например, используются вспомогательные утилиты или внешняя инфраструктура для сборки (скажем, кеширующий компилятор вроде ccache). А использование нескольких субагентов серьёзно замедляет и утяжеляет запуск и выполнение отдельных подзадач.

Например, вместо нужного для сборки проекта clang-22 агент зачем-то установил GCC. Ожидаемо у него ничего не собралось, и он принял решение «исправить ошибки сборки», переделав всё на другой компилятор. Но версия GCC оказалась довольно старой, и многие новые фичи из C++23 в ней отсутствовали. Тогда агент решил исправить ошибки уже в коде проекта.

В итоге, проработав автономно всю ночь, (использование Docker для автономных агентов оказалось небыстрым), и результат на выходе получился ожидаемый. Код был очень далёк от желаемого, хоть и компилировался с «зелёными» тестами. Я сделал несколько попыток запустить автономного агента, но все они оказались с одинаково печальным исходом. Несмотря на рабочий код, итоговый результат был неудовлетворительным.

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

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

Наверное, можно попытаться настроить одного агента на онлайн-мониторинг рассуждений другого, чтобы он контролировал направление мыслей в правильном русле или сделать какую нибудь дополнительную «обвязку» для анализа работы агента, но эту задачу я решил оставить на будущее, а сейчас продолжить работать в «парном режиме».

Фиксим Cline

Эксперимент с автономным агентом начался из-за проблем с Cline, но в результате пришлось к нему вернуться. Поэтому требовалось решить проблему с принудительным ограничением размера контекста при работе с моделями через агрегатор. Оказалось, ничего сложного: натравил на исходники Cline его же самого и обозначил задачу - увеличить окно контекста по умолчанию с 128K до 1M.

В результате сделал сборку плагина для VS Code с исправленным размером контекста, который не обрезается принудительно на 128K, а использует весь доступный объём, примерно вот так:

Максимальный размер контекста, пока не надоело за этим следить :)

После подобного фикса даже встроенная и неотключаемая реклама Claude 4.5 Sonnet стала появляться значительно реже, потому что модель перестала терять контекст. Как итог, качество кода заметно повысилось, несмотря на возрастающий объём анализируемой кодовой базы.

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

Для желающих поддержать мой проект, кроме оценки самой статьи (если её выводы показались вам полезными), можно еще зарегистрироваться на BotHub по моей реферальной ссылке, чтобы добавить мне немного CAPS’ов для продолжения дальнейших экспериментов и развития проекта.