Дисклеймер: все нижесказанное является личным мнением автора. Я ни в коем случае не претендую на истину в последней инстанции и могу сильно заблуждаться.
Во многих бигтех-компаниях, да и в целом в 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.
Комментарии (72)
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Как минимум, спроектировано полное описание контракта (а контракт включает типы данных на входе , выходе и обработку ошибок) и одобрено человеком
Spiritschaser
05.06.2026 07:39А может, он просто обучен на худших решениях с stackoverflow?
Rive
05.06.2026 07:39Агенты же уже не просто предсказатели следующего слова по промпту и сиду, а закольцованные системы, которые при хорошей настройке проверяют код на компилируемость, запах, соответствие задаче, прохождение тестов и тому подобные вещи.
Spiritschaser
05.06.2026 07:39при хорошей настройке проверяют код на компилируемость, запах, соответствие задаче, прохождение тестов и тому подобные вещи.
Где-то тут была история, как агенты к ТЗ нафигачили тесты, чтобы их проще проходить было
компилируемость
Да ладно, а на утечки памяти проверяют?
cdriper
05.06.2026 07:39в месте обработки поставит много защитного кода
а вы лично хоть раз агента пользовали или только по телевизору смотрели?
гарантированная проблема всего сгенерированного кода это ужасная обработка ошибок и граничных условий.
а многословен он потому, что генерит все "как есть" даже не пытаясь "вспомнить", что секунду назад он генерировать метод, который почти полностью совпадает с текущим, и поэтому общее тело надо выделить в отдельный метод и переиспользовать.
Spiritschaser
05.06.2026 07:39Мне вчера ИИ ещё и выстраданный мной парсер хитровыдуманного JSON "оптимизировал". Долго искал, где косяк.
Spiritschaser
05.06.2026 07:39Вот буквально вчера вычищал "проверки" из сгенерённого кода. Вообще не нужные (в случае, который проверялся, из ветки выход был бы раньше).
youngmysteriouslight
05.06.2026 07:39Не вайбкодер, но считаю эту аргументацию шаткой.
Он не знает, какие данные придут (хотя вы знаете)
Это написано в документации к методу.
Проблема ещё в том, что он не знает куда кидать ошибку
Автор пишет:
Несмотря на наличие в проекте большого количества примеров того, как должны быть написаны юнит-тесты,
значит, в контексте агента есть множество стереотипных примеров, куда кидать ошибку, а он их проигнорировал. Кстати, раньше мне казалось, что LLM должны хорошо справляться с написанием по образцу. Получается, он работать умеет только по подробной спецификации?
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... Какая разница, как это называть. Вы не сможете нормально пользоваться нейросетями при разработке, пока не научитесь проверять код не читая его.
sYB-Tyumen
05.06.2026 07:39А технически вообще возможно "проверять код не читая его"? Понятно, что есть всякие линтеры, анализаторы и прочие инструменты.
Но есть же ещё "насмотренность", когда опытный глаз видит в коде что-то не то. И иногда можно долго копать, прежде чем сознание поймёт, что именно "не то" угляделось и к каким конкретным ошибкам может приводить.
А если вместо органических нейросетей применять электронные, то не получится ли так, что описание логики работы и контрактов, достаточное для адекватной работы LLM, будет практически не отличимо по потраченному времени и ресурсам от написанного вручную кода?
Dhwtj
05.06.2026 07:39возможно "проверять код не читая его"?
Только когда бизнес требований и ограничений значительно меньше чем общих знаний, которые уже кто-то прочитал, выверил и доказал, но не в этом проекте.
Либо кто-то путает код и данные
mahmud90
05.06.2026 07:39Стандартная выработка вайбкодера - шестьдесят тысяч строк в неделю
"Стандартная" как бы намекает, что есть какая-то статистика по вайбкодингу. Или судите больше по себе? Кто имеется в виду под вайбкодером - опытный программист, начинающий или не-программист? И что можно сказать о "стандартном" качестве такого кода?
netricks
05.06.2026 07:39Да. Статистика есть. Она, конечна, взята по полутора калекам, но вряд ли мы с коллегами сильно отличаемся от общечеловеческой массы. Число в 60 тысяч плюс минус трамвайная остановка упорно повторяется. Я бы сказал, что моя рабочая оценка.
Нет, не новички. Вообще ни разу не новички. Качество разное. Тут надо понимать, что большая часть этих шестидесяти тысяч уходит не на написание нового кода, а на переписывание старого. По мере переписывания качество подтягивается.
Ну, а в целом, моя статья по вайбкодерским практикам уже почти вот-вот.
devoln
05.06.2026 07:39У меня две $20-подписки Codex, у которых использую все лимиты под ноль для двух backend+frontend проектов на TypeScript. Получается до 15к строк в неделю кода, включая тесты и доки. Все доки читаю, код читаю по диагонали и интересные части. Обычно трачу всю недельную квоту за 2 дня, а в остальное время изучаю, тестирую более внимательно и делаю огромный коммит, где всё понамешано. Пока это не прод и проекты полностью мои.
Код наверное в 2 раза более многословный, но при этом есть возможность оптимизировать горячие места типа размера собранного бандла, кеширования в браузере и т.п., где руками пришлось бы долго экспериментировать и анализировать, а тут агент всё за меня сделал.
Также могу легко вылизывать UX, делая всяких плюшки, до которых руки бы вообще не дошли: индикация прогресса, кастомные компоненты и т.п..
А на работе C++, там пока до активного ИИ не созрел кроме как сгенерировать класс и потом детально его изучить и отредактировать руками. Ну и баги агенты помогают искать. В текущих задачах слишком много нюансов качества кода, производительности и управления памяти, которые я не готов доверить агентам. Но после этих задач может и буду использовать ИИ-код активнее в задачах попроще.
Gorthauer87
05.06.2026 07:39Я вот активнее всего использую ИИ для анализа кода, анализа текстов, анализа логов, и ещё для саммаризации изменений во время ревью пул реквестов. И ещё для поиска и разборов информации.
И вот это жизнь куда больше упрощает, чем вайбкодинг. В плане написания кода я ИИ доверяю лишь рефакторинг и то очень понятный и дописание тестов по примеру.
Ну и документацию, потому что лучше такая дока чем вообще никакая.
aabzel
05.06.2026 07:39читаю
Я вот активнее всего использую ИИ для анализа кода, анализа текстов, анализа логов, и ещё для саммаризации изменений во время ревью пул реквестов.
понимаю
Я вот активнее всего использую ИИ для слива компанейского кода в сеть, слива в интернет внутренней документации , расскрытия коммерческой тайны .
Gorthauer87
05.06.2026 07:39Вообще не к месту. На работе у нас свой ИИ, дома опенсорс. Это полностью изолированные контура.
Не надо читать того, что нет в тексте
radim_tcar
05.06.2026 07:39Сейчас они реально полезны только как инструмент для ускорения рутинных задач. Но в задачах со строгими архитектурными ограничениями они часто увеличивают общий объём работы, генерируют избыточный, нестандартный или потенциально некорректный код, который потом нужно тщательно вычищать и перепроверять. По факту происходит не снижение когнитивной нагрузки, а её перераспределение, с написания кода на его ревью и контроль качества, причём часто с ростом затрат. Поэтому твой вывод корректный, сегодня ИИ это не замена разработчика, а инструмент с высоким риском и неоднородной выгодой, эффективность которого сильно зависит от типа задачи и зрелости процесса разработки.
sWitched0ff
05.06.2026 07:39Странное заявление про детерминированный результат от человека. Неужели вот прям действительно каждый раз реализацию делаете одними и теми же методами? Никакого развития и повых методов, копипаста одного и того же? У меня часто бывает пока какой-то незначительный баг копаю находится повод поразмыслить а не переписать ли ещё половину системы чтобы лучше работало.
Dhwtj
05.06.2026 07:39Статистика говорит, что розгами и плетью от джунов можно добиться больше дисциплины, чем от LLM
Arseny88 Автор
05.06.2026 07:39Возможно, я не до конца раскрыл мысль про более детерминированный результат от человека.
Когда я пишу/изучаю код, пытаюсь поймать и пофиксить баг, делаю рефакторинг и проч., я произвожу действия частично или полностью с осмыслением того, что я делаю, т.е. с учётом архитектуры проекта, технических и бизнесовых ограничений и ньюансов, здравого смысла, последствий от одного, казалось бы, маленького изменения, и так далее. В случае генерации кода агентом, у меня сложилось впечатление, что ЛЛМ ничем подобным не руководствуется или руководствуется частично, упуская те или иные ньюансы, из-за чего даже валидное на первый взгляд решение на самом деле может таковым не являться.
i86com
05.06.2026 07:39Не пробовал Opencode, но звучит так, что вы кодите "в режиме чата", вручную скармливая LLM крохи контекста. Особенно с учетом фразы "Но чаще всего не работающего, особенно с первого раза".
Так даже топовые модели ерунду пишут (и настаивают на своей правоте) и так никто сейчас не делает. Попробуйте Cursor или любую другую современную AI IDE. Он сам находит нужный контекст, анализирует, где на проекте уже что-то подобное делалось и почему именно так. Он грепает по файлам со скоростью света - вы ещё не успеете прочитать, что он ищет, а он уже нашёл, прочитал, сделал выводы и пошёл искать следующее.Озвученных проблем уже несколько лет не встречал, пока не решил однажды на пробу в режиме чата с одной из свежих Sonnet написать простенький скрипт по текстовому описанию. Написало криво, с ошибками в коде и логике, как какой-нибудь ГигаЧат, ей богу, разница очень значительная.
Persik1
05.06.2026 07:39Детерминированность тут означает, что человек понимает, что и зачем он пишет. Он может обосновать каждое архитектурное решение. А сетка просто подставляет статистически наиболее вероятный токен
janvarev
05.06.2026 07:39Интересно, что да - вот я хоть и занимаюсь сетками профессионально, а на практике скорее склонен кинуть конкретную задачу в чат по конкретному куску кода, нежели использовать агентов (агенты как-то пока не прижились).
По конкретному куску кода отвечает и переписывает хорошо.
jetnet
05.06.2026 07:39Но непредсказуемость сама по себе создаёт дополнительную когнитивную нагрузку,
А кому щас легко?
Persik1
05.06.2026 07:39Автор прав в главном - когнитивная нагрузка при чтении чужого кода всегда выше, чем при написании своего. И неважно кто его писал, ИИ или коллега из соседнего отдела
SabMakc
05.06.2026 07:39От ИИ нагрузка выше. Мало того, что кода ИИ генерит больше, так еще и подвох может быть в очень неожиданных местах, из-за чего надо быть очень внимательным.
codecity
05.06.2026 07:39Проблема в том, что доведение сгенерированного кода до качества, соответствующего уровню продуктивного контура, занимает ничуть не меньше, а иногда и намного больше времени, чем если бы код писался руками.
Есть выход - отделить архитектуру от реализации. Чел. отвечает за контракты, за архитектуру - и даже не заглядывает что там за страх оно нагенерило. Начнешь заглядывать и делать правильно - весь буст так называемый сойдет на нет.
Arseny88 Автор
05.06.2026 07:39При таком подходе использование ИИ допустимо только в MVP-решениях и относительно простых проектах, не претендующих на что-то значимое. В "серьёзных" продуктах, такой код просто не пройдёт по критериям безопасности, производительности, uptime, стабильности, поддерживаемости и расширяемости и т.д.
codecity
05.06.2026 07:39допустимо только в MVP-решениях и относительно простых проектах, не претендующих на что-то значимое
Ваша правда. Для внутренних утилит или скриптов, с легко проверяемым поведением, для MVP-проектов (проверка идеи). Т.е. когда есть четкий API (задан человеком) и критерии приемки, полное прокрытие поведения тестами (тесты дергают API и происходит то что задумано).
Когда нужно качество (быть лучше других, а не просто работать), поддерживаемый код - то надежнее и быстрее руками.
Но! Многие пока об этом не знают, LLM-ки начали активно использовать сравнительно недавно, а некоторые даже не начинали. Пока есть вера в чудо...
SabMakc
05.06.2026 07:39К сожалению, LLM - это именно что “T9 на стероидах”. Они обучаются буквально в виде “продолжи текст”. Это практически чудо, что они просто в состоянии поддерживать беседу. Причем неплохо поддерживать.
То, что LLM “знает” как правильно писать код, может объяснить код - ни разу не значит, что она эти знания применяет при написании кода. Это просто разные навыки у LLM. Размышления помогают, но размышления, зачастую, это просто “набросать в контекст по теме”. Да, это дает значительный буст. Но мыслить модель от этого не стала.
Но LLM пришли, показали неплохие результаты, в том числе и в кодинге. Причем даже локальные модели. И они с нами надолго - если не на всегда, то точно до момента, когда изобретут что-нибудь более продвинутое.
Diamon33
05.06.2026 07:39меня бесит их фундаментальное качество - недетерменированность результата.
В смысле, Вы ожидали от недетерменированного механизма детерминированного поведения?
Spec-Driven-Development + Skills = ok
Архитектура теперь критически важна, и ее нужно знать, а часы написания кода можно свалить на LLM.
LLM и не может пока с полуслова понимать, что Вы хотите, иначе Вас бы давно уволили. Было бы это лучше или нет?
Lecron
05.06.2026 07:39Можно ли осознать и впитать нюансы верхнего уровня, не проведя кучу часов на нижнем?
Вы смотрите с позиции того, кто этот нижний уровень исходил вдоль и поперек. Тогда можно свалить на LLM. Но, кмк, невозможно развиваться в архитектуре, изначально сваливая написание.
Groramar
05.06.2026 07:39Думается, что все претензии из-за неумения ставить задачу нейронкам. Не нравятся полотна кода? Просите сети делать максимально компактный код. Получается неоптимально по скорости? Просите делать оптимально. Это не 'высосано из пальца'. Это реальные рекомендации по сотням чат-сессий.
Ну и да, актуальные LLM'ки фундаментально недетерминированные. Ожидать от них противного не стоит.
В любом случае буквально всегда есть вариант: не нравится - не используйте.
vvbob
05.06.2026 07:39Есть один знакомый. На волне хайпа IT пытался вайтивайти, донимал разными вопросами с чего начать и как получать 400К денег в секунду, желательно ничего не изучая. ЯП с их дурацким синтаксисом у него вызывали головную боль и депрессию. Не вкатился, естественно.. Недавно звонил и спрашивал что делать если ИИ как-то не так прикрутило оплату к сайту заказчика, он ему уже и так и эдак давал задание, но тот что-то криво прикручивает.. Чувак вайбкодит вообще не отдупляя что там под капотом. Я знатно охренел.. но видимо это и есть оно, наше будущее, неизвестно что нагенерированное по требованию
макакивайбкодера, как-то там вроде работающее..
devoln
05.06.2026 07:39Мне наоборот кажется, что ИИ разгрузил мне мозг и помог искоренить прокрастинацию. Раньше было сложно сесть за работу и решение задач, а теперь легко, можно начать с вопроса или дачи задачи агенту. Разгребать то, что он написал, тоже проще, чем своё придумывать, если не пытаться понять всё досконально и сразу как он сгенерировал, а только после тестирований и исправлений проверять важные моменты. Их тоже можно у агента спрашивать.
В итоге я за компом 10 часов в сутки 7 дней в неделю что-то разрабатываю, потому что процесс затягивает. Руками я в 5 раз медленнее бы двигался и не мог бы проводить столько времени за разработкой.
cdriper
05.06.2026 07:39надо просто понимать ограничения технологии и просчитывать, что можно делегировать и выиграть в итоге по времени, а что будет пустой тратой сил и токенов. всегда есть куча рутины, с которой агенты вполне себе справляются.
Lecron
05.06.2026 07:39Недавно иначе взглянул на тезис "Достаточно подробная спецификация — это код". Не как повод похоливарить, а представить код работающего проекта, в качестве этой спецификации. Вместо ее описания на естественном языке. Куда уж подробнее.
Сетка должна уметь написать код на целевом языке, с учетом его практик и концепций. Показать свой действительный уровень. И это не просто показатель уровня, а полезность в рефакторинге и переносе прототипов в другую среду.
VVizard
05.06.2026 07:39Вот только что бы написать такую спецификацию нужно быть самому в контексте.
Приведу цитату:
Отдельно Хайтауэр предупреждает об опасности бездумной генерации. Он вспоминает старую формулу "писать — значит думать": когда инженер пишет код сам и медленно, он спотыкается о собственные ошибки, понимает, что выбрал не ту структуру данных или что архитектура трещит по швам. ИИ выдает тонны готового кода за секунды, разработчик радостно отправляет его в прод, пропуская этап мысленной валидации, — и так плодится высокоскоростной технический долг".
Как правило разработка ведётся в контексте какой то предметной области. Причем ТЗ/ФТ пишут обычные люди. Я 25 лет занимаюсь разработкой и ещё не встречал "идеальной спецификации".
Как правило в процессе разработки все документы корректируются, уточняются. Часто приходит понимание что лучше сейчас изменить архитектуру чем спустя 3 релиза.
У всех по разному но я например активно участвую в встречах аналитиками где обсуждается спецификация. Но если я перестану писать код то я быстро потеряю контекст.
Проблема даже хороших инструментов (моделей) в том что они дают то что ты просишь а не то что тебе нужно.
Банально, потому что до разработки ты знаешь чего ты хочешь, но ещё не знаешь что тебе нужно.
Даже казалось бы элементарные задачи опасно делегировать. Недавно была задача загрузить файл в систему, идеальный кандидат на работу ИИ, но закончились лимиты и делал сам, в итоге обратил внимание что в задаче описан поиск договора, но при этом пропущена часть о доп. соглашении и в тестовых данных нет так как этот функционал только что вошёл в релиз.
На вайбкоде я бы это пропустил и потом бы пришлось править ошибки. Так как я делал сам то я обратил внимание на это, сообщил аналитику и они доработали требование.
Хотя конечно я часто использую ИИ но как правило для review когда уже MVP написан, задачу я понял, и дальше просто скучная рутина (потому и месячная подписка улетает за неделю).
Ещё классно писать модульные тесты, это как новый фреймворк который может изучить код и предложить варианты тестовых данных.
Но именно режим вайбкодинга это 100% смерть продукта и проекта. Это как обосраться в мороз, первое время тепло.
Lecron
05.06.2026 07:39Вы кажется не поняли смысл моего поста. Он не про вайб, а как раз наоборот. Есть проект/модуль или нечто высокого уровня, написанный на каком-то из языков программирования — C/C++, Java, Python. Работающий, функциональный, (достаточно) качественный. Это идеальный промт. Перепиши, например, на Rust.
peacemakerv
05.06.2026 07:39Абсолютно соглашусь с тем, что нервная нагрузка и усталость от вайбкодинга - сильно повышенная.
Я провел эксперимент над собой - смогу ли я полностью бесплатными нейросетями навайбкодить себе замену Asana, а точнее - по сути свой чат, замену Телеграму (но мессенджер с привязкой в неким задачам).
При том, что знаний в этих web-технологиях всех, наверное не больше 10%.
Столкнулся с тем, что плохо спал все эти три недели эксперимента - гонка за получением правильного результата от нейросетки и бесит и приносит удовлетворение от победы одновременно.
Но устаешь неимоверно, и матерится стал впятеро чаще. Больше такой опыт повторять не хочется.
Хотя результата я достиг, за три недели наваял в одного полностью бесплатно систему, в которой уже 37+ тысяч (!) строк (PHP + MariaDB + Javascript (который я уже возненавидел)).
Если кому-то интересен такой личный таск-мессенджер - обращайтесь.
https://pmaker.ru/задачат_функционал/
aabzel
05.06.2026 07:39старался описывать задачи подробно, добавлял контекст, объяснял не только что нужно сделать, но и как.
Замечу, что на формулирование и написание детализированного промпта для получения мало-мальски приемлемого результата уходило немало времени - иногда сопоставимо с тем, чтобы написать код самому.Да, есть такое..
aabzel
05.06.2026 07:39код работает, то он почти никогда не следует каким-либо best-practice. Он многословен, избыточен, а порой и неэффективен по использованию ресурсов.
Да. Так и есть.
anonym0use
05.06.2026 07:39У меня на проекте есть коллеги которые полностью расслабились и отпустили эту жизнь, льют в репо 100% генерированный с 1 промта код, видно что даже без редактирования, CtrlC + CtrlV, проект постепенно превращается в кашу.
Соглашусь с автором в том что ИИ генерит многословный код, использует редкие, сложные конструкции языка, код в некоторых местах выглядит инопланетно, тяжелее читается, если в таком коде ошибка, то самому дебажить это очень больно.Также отдельная боль это мержить правки с этой кашей, ИИ любит переписывать весь или почти весь файл целиком, меняя отступы и т.д., в итоге вместо нескольких блоков/строчек конфликта - весь файл один большой конфликт.
Но зато быстро, менеджмент в восторге, фичи релизятся одна за другой, на рост техдолга пока закрываются глаза.
isumix
05.06.2026 07:39Потому что язык программирования намного более компактный и точный в описании задачи чем человечий язык. Человечьим языком проще описывать шаблонные и широко известные вещи, но чуть уходишь в сторону кастомизации, как понимаешь что ЯП с этим справтся лучше, для этого он и был создан.
MShevchenko
05.06.2026 07:39Я, слава Богу, не пишу для веба уже лет 25.
Для своего проекта использую C/C++. Claude очень не плохо справляется при постановке мелких задач. По сути я его воспринимаю как Near-Middle.
Можно сказать что ограничение промта можно определить как "то что ты сам можешь сделать за день-два".
Очень хорошо справляется с задачами типа "перенести этот алгоритм из Mallab в OpenCL/CUDA". Такие задачи сложны для имплементации в лоб. Очень высока трудоемкость и вероятность ошибки.
blurman
05.06.2026 07:39Недетерминизм вывода опознали верно — это и правда корень, и убрать его нельзя, это природа модели. Но вывод из этого не «инструмент плохой», а «надо строить контур, который ловит мусор без чтения глазами». Про тесты соглашусь — сгенерённые заодно с кодом часто ничего не проверяют. Но жёсткие типы и контракты (про что выше Dhwtj), статические анализаторы, линтеры, плюс тесты, написанные до кода под инвариант, — всё это ворота, а не ещё один артефакт на ревью. Контур ловит локальный мусор. Архитектурный дрейф, мёртвый код, тихо переписанные «заодно» классы он не поймает — это остаётся на человеке. Но именно это и есть нормальная граница: машина пишет по контракту, границы держишь ты.
Registan
05.06.2026 07:39Замечаю, что очень многое мы прощаем агентам по сравнению с людьми. Допускать в коде архитектурные ошибки, которые описаны даже в любой книге «для чайников» - неуместно для любого профессионала, а особенно для того, кто пытается захватить весь мир разработки.
Использую чат для генерации небольших кусков кода и проверки существующего, здесь бесценный инструмент.
gun_dose
05.06.2026 07:39Не верю, что нормальный программист не сумеет заставить ИИ писать такой же код, как пишет он сам. Полгода назад даже бесплатный Copilot с Haiku 4.6 отлично с этим справлялся. Добавляешь нормальный контекст, в котором видно стиль кода проекта, и ставишь маленькую задачу на пару сотен строк кода. Потом эти пару сотен строк ревьювишь за пару минут и исправляешь пару ошибок. Всяко быстрее, чем набирать самому. И это даже с бесплатным инструментом с моделью для бичей.
А если у тебя полчаса уходит, чтобы сформулировать мысль, а потом ещё полчаса на ревью 200-300 строк, значит такой ты программист. И нечего на инструменты пенять.
Roma_habr
Пожалуй, соглашусь, но с оговоркой.
По моему субъективному опыту, выбор модели сильно влияет на результат. Использование последних выпусков Opus сократило бы необходимое количество дебагов по сравнению с Sonnet.
Но полностью не исключило бы ошибки 100%.