Метод read исчез из кода четыре коммита назад. За это время успели выкатить три фичи — и никто не заметил, что программа перестала читать данные. Файл открывался, файл закрывался, между ними было пусто. Именно с этого эпизода начинается большое эссе об агентном программировании, опубликованное на Хабре разработчиком, который провёл с ИИ-агентом около полугода в режиме полного погружения.
Агентное программирование — это подход, при котором разработчик не пишет код руками, а ставит задачи языковой модели, встроенной в среду разработки (Cursor, VS Code с расширениями, терминальные агенты). Агент сам исследует кодовую базу, запускает скрипты, вносит правки и отчитывается. Разработчик работает на уровне архитектуры и постановки задач, а не синтаксиса. Такой режим принято называть вайбкодингом — термин закрепился в профессиональном сообществе как обозначение разработки, где человек задаёт направление, а модель реализует детали.
Автор эссе за четыре месяца создал пет-проект объёмом 250 тысяч строк: четыре языка с интеропом, собственный встроенный UI-фреймворк, два графических бэкенда, два физических движка в рабочем состоянии и поддержка VR. Типовая неделя — 60 тысяч строк кодовых правок. Сам разработчик открывает редактор лишь в экстраординарных случаях: когда нужно переосмыслить архитектуру или поработать с особо ответственным участком.
Агент удалил метод read из кода — баг обнаружился спустя четыре коммита и три выкаченные фичи.
Самый тяжёлый эпизод в истории проекта — перевод кода с Python-прототипа на C++/C-ядро. Ошибки управления памятью, связанные с передачей объектов через nanobind-слой, преследовали команду неделю и давали о себе знать ещё месяц. Агент, по описанию автора, «метался аки в паутине», пытаясь разобраться с владением объектами. Выход нашли в архитектурном решении: перевели интероп на слабые связи, жёстко ограничили точки проникновения Python-объектов в C и установили политику работы со счётчиками ссылок. После этого характер ошибок изменился — вместо расползающегося фундамента стали появляться локальные, изолированные поломки.
Центральный тезис эссе — агент не ломает проекты из лени или вредности, он буквально выполняет то, что ему сказали. Это одновременно главное достоинство и главная опасность. Модель патологически внимательна к формулировкам: любое вскользь упомянутое указание будет учтено и немедленно сузит пространство поиска решений. Если нужен конкретный результат — запрос должен быть конкретным. Если нужно, чтобы агент сам предложил подход, — формулировку стоит намеренно оставить открытой. Просить «сделать хорошо» бессмысленно: агент не знает, что для вас означает это слово.
Автор противопоставляет одноагентный подход многоагентным оркестрациям. Последние надёжнее и лучше поддаются рациональному контролю, но существенно дороже и требуют больше кода для настройки. Одноагентная работа — это «тонкая психология» и прямой диалог, где качество результата во многом определяется умением разработчика объяснить задачу. Скриншоты, рисунки, аналогии, ссылки на известные проекты — всё это легитимные инструменты постановки задачи наравне с текстовым описанием.
На Хабре давно обсуждают, что вайбкодерские проекты со временем разваливаются под собственным весом. Эссе претендует на практический ответ: не разваливаются те проекты, где архитектурные решения принимает человек, а агент работает в строго очерченных границах — с понятной политикой владения данными, информативными логами и тестами, которые модель пишет сама. Нейросеть, по наблюдению автора, не ленится обрабатывать исключения и проверять крайние случаи — именно то, ивой разработчик склонен откладывать.
