Дисклеймер: все нижесказанное является личным мнением автора. Я ни в коем случае не претендую на истину в последней инстанции и могу сильно заблуждаться.
Во многих бигтех-компаниях, да и в целом в IT-отрасли, сейчас происходит (или, по крайней мере, пытается происходить) масштабная и кардинальная трансформация процесса разработки - менеджеры просят или прямо требуют использовать ИИ-агентов для написания кода, проводятся регулярные воркшопы на тему использования ИИ в работе, создаются инструкции по настройке рабочего окружения, появляются всё новые и новые способы ещё более эффективно работать с этим "чудо-инструментом, меняющим правила игры" и так далее. Повсюду витает атмосфера светлого будущего.
И иногда я тоже начинаю верить, что это счастливое будущее действительно вот-вот настанет: больше не нужно будет писать код руками, рутинно писать очередную 100500-ую шаблонную интеграцию с внешним сервисом и DTOшки к ней, и, самая неприятная часть разработки лично для меня, писать тесты - всё это будет делать ИИ.
Я пробовал: старался описывать задачи подробно, добавлял контекст, объяснял не только что нужно сделать, но и как. Замечу, что на формулирование и написание детализированного промпта для получения мало-мальски приемлемого результата уходило немало времени - иногда сопоставимо с тем, чтобы написать код самому.
Но с каждым разом я понимал, что даже если сгенерированный агентом код работает, то он почти никогда не следует каким-либо best-practice. Он многословен, избыточен, а порой и неэффективен по использованию ресурсов. Условно говоря, что можно уместить в 20 строк, агент реализует в 30-40. Если масштабировать данную формулу на изменения в большом количестве файлов, мы получаем тонну нейрокода, и хорошо, если работающего и без багов. Но чаще всего не работающего, особенно с первого раза, и с вероятными критическими, незаметными глазу проблемами, которые, если повезёт, будут обнаружены на стадии разработки или код ревью, а не в ходе тестирования или вообще на продуктивном контуре.
Отдельная история с генерацией тестов - полный швах. Несмотря на наличие в проекте большого количество примеров того, как должны быть написаны юнит-тесты, почти всегда генерируется тонна лишнего инфраструктурного кода с моками, сетапами окружения, билдер-методами и т.д. Сами же тесты очень часто либо не проверяют буквально ничего (такого очень много), либо не компилируются, либо не соответствуют логике основного кода, из-за чего фейлятся.
Но бог с ним, с этим кодом, неважно, что его намного больше, чем нужно, и из-за этой многословности решения ИИ иногда очень тяжелы для понимания. Главное - чтобы работало, верно?
Проблема в том, что доведение сгенерированного кода до качества, соответствующего уровню продуктивного контура, занимает ничуть не меньше, а иногда и намного больше времени, чем если бы код писался руками.
Думаю, многие со мной согласятся, что изучение чужого кода намного сложнее, чем понимание своего собственного, и требует значительно большей когнитивной нагрузки. Частенько в какой-то момент изучения сгенерированного кода у меня возникает с трудом подавляемое желание пробить монитор рукой, потому что часами копаться в ужасном нейрослопе мне кажется невыносимым. В такие моменты я обычно удаляю почти все изменения, сделанные агентом, и начинаю писать код сам, практически с нуля.
С каждой неудачной попыткой, моё раздражение от упоминания ИИ всё росло, и я не понимал - неужели я один такой глупый и не умею/не хочу пользоваться отличным инструментом для упрощения работы? Судя по комментариям и постам в интернете, и в частности на Хабре, у многих всё получается: "вкалывают роботы, а не человек".
Ирония в том, что только недавно до меня дошло: в ИИ, а точнее, в LLM-ках, меня бесит их фундаментальное качество - недетерменированность результата.
Когда я пишу код сам, я знаю, что получится (или должно получиться) на выходе. Когда я генерирую код агентом, я не уверен ни в чём: будет ли использован несуществующий метод? Правильно ли агент понял архитектурные ограничения проекта? Не придумает ли он несуществующую библиотеку? Не перепишет ли заодно другие классы для "улучшения качества кода"?
Каждый запрос похож на игру в казино на слот-машине. Конечно, иногда агент выдаёт вполне приличный результат даже с первого раза. Но непредсказуемость сама по себе создаёт дополнительную когнитивную нагрузку, которой нет при самостоятельном написании кода. Я не могу доверять тому, что написано сгенерировано, а значит, должен тщательно проверить все изменения. Но, как я уже говорил, тщательная проверка сотни-другой строк изменений выматывает не меньше, чем самостоятельное написание такого же объёма кода руками. Особенно когда видишь какой-то заведомо неправильно и неэффективно написанный участок, понимаешь, что его придётся переделывать, а значит, проводить перепроверку. И так до тех пор, пока не будешь уверен, что код соответствует каким-никаким стандартам. Сколько итераций код-ревью тонн нейрокода придётся провести до достижения этой цели - неизвестно. Сколько сил и времени будет на это потрачено - тоже.
Судя по моему скромному личному опыту, использование агентов в повседневной разработке и полный отказ от написания кода "руками" приводит к повышенной, иногда чрезмерной для среднестатистического человека умственной нагрузке. В долгосрочной перспективе ни к чему хорошему это не приведёт: усталость (в т.ч. хроническая), невозможность нормально думать после 8-часового рабочего дня, и, в конце концов, выгорание и вероятный уход из профессии. ИМХО.
Буду рад почитать в комментариях ваше мнение по поводу агентов в разработке. Особенно интересен положительный опыт использования от разработчиков уровня миддл и выше. Не исключаю, что мне просто не хватает каких-то специфических навыков использования агентов и написания промптов или банальной экспертизы и опыта, чтобы держать ИИ под контролем.
P.S. В качестве CLI-агента я использовал opencode. Из LLM-моделей - Claude Sonnet 4.6, немного Claude Opus 4.6, и Qwen 3.5-397B.
Комментарии (17)

nidalee
05.06.2026 07:39Claude Code действительно пишет Next как-то через жопу. На Opus 4.8 с high effort вроде нормально, а 4.7 обе модели - стабильно как минимум 1 ошибка из-за которой стейджинг\прод упадет. GPT5.5 на high в этом плане лучше - ни разу за месяц не было регрессий. Мог что-то не так понять или не доделать, но все работало.
В итоге для себя решил Opus для планирования и реально тяжелых задач, типа reverse engineering, Codex для работы по планам Opus-а и прочей мелочи типа отцентровать div.

Gorthauer87
05.06.2026 07:39High effort так то дороговато выходит

nidalee
05.06.2026 07:39Для планирования нормально. Для reverse engineering выбирать больше не из чего кмк... Пока использовал GPT как исполнителя, даже тарифа за 20 баксов хватало.

Dhwtj
05.06.2026 07:39Одна из причин почему LLM многословен:
Он не знает, какие данные придут (хотя вы знаете), в месте обработки поставит много защитного кода (хотя это вы должны были создать типы чтобы невалидные данные были невозможны). Тогда в любом случае код не упадет.
Проблема ещё в том, что он не знает куда кидать ошибку (а это вы должны были позаботиться чтобы создать типы исключений или кодов возврата ошибок), поэтому молча её поглотит и не предупредит (а это вы должны были решить допустимо это мои надо падать и надо ли логировать)
LLM склонен к catch-and-swallow, потому что его цель "чтобы прошло/скомпилировалось", а не "чтобы упало громко при нарушении инварианта". Ну так вы должны были его предупредить что сверху кто-то ловит и исключения кидать можно. Ещё сильнее: дать ему как именно кидать тип ошибки (Result<T,Error> или конкретные exception-типы), тогда у него появляется куда кидать и он перестаёт импровизировать

Arseny88 Автор
05.06.2026 07:39хотя это вы должны были создать типы чтобы невалидные данные были невозможны
вы должны были позаботиться чтобы создать типы исключений или кодов возврата ошибок
Выходит, что на плечи агента можно возложить в основном только написание конкретной бизнес-логики, когда всё "окружение" для новой фичи в виде DTO, исключений, REST-клиентов, JMS-слушателей и проч. уже написано?

Dhwtj
05.06.2026 07:39Как минимум, спроектировано полное описание контракта (а контракт включает типы данных на входе , выходе и обработку ошибок) и одобрено человеком

netricks
05.06.2026 07:39Стандартная выработка программиста - две тысячи строк в неделю. Стандартная выработка вайбкодера - шестьдесят тысяч строк в неделю. При таких масштабах сама идея прочитать код написанный сеткой попахивает безумием. Не вы первый, кто заметил, что стратегия эта не работает.

Arseny88 Автор
05.06.2026 07:39Вайбкодинг это вообще отдельная история. Мне кажется, там пытаться что-то понять вообще не имеет смысла, если проект хоть сколько-нибудь большой, так как все изменения делались человеком, который в принципе не имеет каких-либо знаний и экспертизы, вследствие чего и способности определить правильность написанного кода. При попытке ревьюить такое количество нейрокода, который не подвергся хотя бы первичной валидации тем, кто его генерировал, есть риск получить психическую травму :)
Думаю, в данном случае уместнее сравнивать выработку обладающего квалификацией инженера с использованием агента и без него.

netricks
05.06.2026 07:39Vibe code, ai assistant programming, ai agentic enginering... Какая разница, как это называть. Вы не сможете нормально пользоваться нейросетями при разработке, пока не научитесь проверять код не читая его.

Gorthauer87
05.06.2026 07:39Я вот активнее всего использую ИИ для анализа кода, анализа текстов, анализа логов, и ещё для саммаризации изменений во время ревью пул реквестов. И ещё для поиска и разборов информации.
И вот это жизнь куда больше упрощает, чем вайбкодинг. В плане написания кода я ИИ доверяю лишь рефакторинг и то очень понятный и дописание тестов по примеру.
Ну и документацию, потому что лучше такая дока чем вообще никакая.

radim_tcar
05.06.2026 07:39Сейчас они реально полезны только как инструмент для ускорения рутинных задач. Но в задачах со строгими архитектурными ограничениями они часто увеличивают общий объём работы, генерируют избыточный, нестандартный или потенциально некорректный код, который потом нужно тщательно вычищать и перепроверять. По факту происходит не снижение когнитивной нагрузки, а её перераспределение, с написания кода на его ревью и контроль качества, причём часто с ростом затрат. Поэтому твой вывод корректный, сегодня ИИ это не замена разработчика, а инструмент с высоким риском и неоднородной выгодой, эффективность которого сильно зависит от типа задачи и зрелости процесса разработки.

sWitched0ff
05.06.2026 07:39Странное заявление про детерминированный результат от человека. Неужели вот прям действительно каждый раз реализацию делаете одними и теми же методами? Никакого развития и повых методов, копипаста одного и того же? У меня часто бывает пока какой-то незначительный баг копаю находится повод поразмыслить а не переписать ли ещё половину системы чтобы лучше работало.

janvarev
05.06.2026 07:39Интересно, что да - вот я хоть и занимаюсь сетками профессионально, а на практике скорее склонен кинуть конкретную задачу в чат по конкретному куску кода, нежели использовать агентов (агенты как-то пока не прижились).
По конкретному куску кода отвечает и переписывает хорошо.

jetnet
05.06.2026 07:39Но непредсказуемость сама по себе создаёт дополнительную когнитивную нагрузку,
А кому щас легко?
Roma_habr
Пожалуй, соглашусь, но с оговоркой.
По моему субъективному опыту, выбор модели сильно влияет на результат. Использование последних выпусков Opus сократило бы необходимое количество дебагов по сравнению с Sonnet.
Но полностью не исключило бы ошибки 100%.