Про AI слоп в разработке и Vibe-Code карго-культ

14 октября 2025

Привет, я уже писал вкратце про ai-слоп в работе в Телеграм канале. В этот раз поговорим про вайб кодинг, красные флаги, и почему human-in-the-loop это не менее чем must-have в AI асситированной разработке.

Повторюсь снова – я не LLM-луддит и не против использования AI в разработке, скорее наоборот. Ведь с рассветом LLM ассистентов моя продуктивность (пусть и не сразу) и продуктивность некоторых знакомых мне инженеров сильно возросла.

Но блин, как же мне надоел этот питч про “10 PR в день! Не читаю код три месяца! 35k LOC за 7 часов!”.

И все это на фоне бурных обсуждений такой хорошей штуки, как context engineering.

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

TL;DR:

“10 PR в день” и “$12k на токены” - в ваккуме это красные флаги карго-культа, а не показатели продуктивности
Спецификации ≠ реальность. Код выражает инварианты системы, которые нужно понимать, а не просто генерировать
Мой эксперимент: переписывание 5k строк без просмотра кода заняло 3 дня вместо 1. На каждой задаче нужны были правки
Правильный подход: AI генерит → ты проверяешь. Human-in-the-loop это не опция а необходимость
Реальные метрики: не количество PR, а стабильность в проде, покрытие тестами и понимание кодовой базы командой

Недавно я наткнулся на очередную сейлс питч статью какого-то очередного продукта для вайбкодинга (ссылку кидать не буду), и там были все признаки именно карго культа. Давайте разберем их.

Красный флаг #1: “10 PR в день от интерна”

Цитирую: “Наш интерн в первый день работы принес 2 PR, а на восьмой день работы – 10 PR’ов!”

Это не достижение, а катастрофа в процессе.

Я верю в то, что нормальный PR требует:

Понимание контекста конкретных изменений
Написание/обновление тестов
Code review от команды (или хотя бы очень злобного и строгого LLM-агента)
Проверка что ничего не сломалось на самом деле (e2e) – ибо 100% coverage сам по себе не дает таких гарантий.
Холистический mental alignment о том что и зачем меняется в системе

Физически невозможно сделать это качественно 10 раз в день. Хорошо если все эти 10 изменений тривиальны, в противном случае это гарантированный будущий tech debt который придется расхлебывать месяцами.

Я боюсь что даже с хорошим LLM кодинг пайплайно, в котором мы будем детально от и до вести разработку, 10 PR в день все еще может быть redflag’ом. Я считаю что при работе в таком ритме ментальная картина проекта не будет обновляться даже у того разработчика который эти PR’ы генерировал.

Я предпочту команду из 3 человек которая доставляет 2-5 качественных PR в день, где все в курсе изменений хотя бы на верхнем уровне, чем команду которая генерит 30 PR вообще не понимая что происходит.

Красный флаг #2: “$12k в месяц на токены, но это норм!”

“Наша команда из трех человек тратит $12k на Opus в месяц”.

Двенадцать. Тысяч. Долларов. На API токены. Это приблизительно цена за 400 миллионов токенов. Давайте очень грубо, приблизительно посчитаем что это вообще может значить:

400 млн токенов Opus (~$30 за 1M)
Это примерно 300 млн слов или 600 тысяч страниц текста
А это где-то 2-3 миллиона строк сгенерированного кода в месяц
Но еще важнее – это зарплата мидл-разработчика в большинстве стран

ROI начинает иметь смысл только если эти токены реально заменяют работу 2-3 разработчиков. Но если процесс не отлажен и идет переделка за переделкой – это просто сжигание денег и времени.

Я не знаю как еще это комментировать, в таких статьях/питчах почти никогда нет даже высосанных из пальца расчетов ROI.

Красный флаг #3: “Я три месяца не смотрел в код”

Цитата: “Я могу по пальцам одной руки пересчитать сколько раз за последний месяц я открывал не-маркдаун файл”

Это либо очень сильное преувеличение, либо они делают настолько простую фигню, что AI ассистент реально хорошо справляется в соло.

В любом хотя бы немного сложном проекте придется рано или поздно залезть в код.

И лучше рано, нет – практически сразу. Потому что:

Давайте будем честны, ai-coding ассистенты стабильно периодически косячат в деталях или ленятся, игнорируя часть критериев выполнения из спецификации;
Утекают edge cases которые мы просто забыли указать в спеках. Читая код (если ты разрабочик) это можно отловить
Интеграция с legacy или проприетарными системами может быть очень сложна. Хорошо если мы долго и упорно готовились к разработке с ai, но… смотри предыдущий пункт;
Performance issues – без код-ревью агента или человека который проверяет каждое изменение, LLM может, например, засунуть блокирующую операцию в асинхронный код – как пить дать.

Буквально мой последний эксперимент – переписать довольно простую систему на ~5000 строк кода с Питона на Rust. Я провел детальное предварительное исследование и составил план – какие библиотеки использовать, перечислил требования к проекту и так далее.

Пайплайн был задизайнен на opencode достаточно просто:

1 агент планировщик, который создает из спецификации атомарные задачи с четким acceptance creteria в формате <NUM>_task.md и складывает в директорию.
Агент разработчик хватает эти задачки по очереди и пытается имплементировать. Каждый раз в конце своей работы он должен был проверить работу проекта сам (там cli обертка), и потом вызвать под-агента для code-review. А дальше – либо правки, либо… идем дальше.

Ничего особенного. Под капотом там был sonnet 4.5 и GLM-4.6

Эксперимент заключался именно в “не заглядывании в код”, не потому что я полный ноль в Rust (я его понимаю и могу писать программы средней сложности), но для того чтобы снова проверить карго культ пропаганду.

Ну вдруг я отсталый какой-то?

Важно еще упомянуть что тестирование изменеий я проводил мануально – в традициях карго культа :)

Итак, результат – до очень сырого, но “почти mvp” доделанного состояния удалось допинать это приключение за 3 дня асинхронной работы.

Конечно параллельно я читал статьи, книги, занимался чем-то еще, потому что циклы работы агентов над задачами были достаточно долгими. Ну, нам ведь это продают, в том же ролике про Jules или других агентов – “запустите нашего асинхронного агента и идите обедать.”

3 дня – это жесть как долго для такой довольно маленькой и прямой как палка кодовой базы.

Если бы проверял на каждом шаге изменения в коде, не важно – работал бы я в IDE с AI асситентом, или просматривал diff после каждой итерации работы этого пайплайна из cli агентов, я думаю что проект был бы переписал за ~1 день со всеми фичами, включая настройку сборки и публикации бинарей.

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

Опыт просто отвратительный :)

О чем молчат культисты

Карго культисты рассказывают только о результатах, пытаясь продать такой “твердолобый” вайб коддинг или еще чаще – свои продукты.

Но фактически всегда в своих питчах они умалчивают ответы на висящие в воздухе вопросы:

Сколько попыток было до успешного PR?
Сколько tech debt накопили? Измеряется ли он вообще как то?
Сколько не смерженных PR остается висеть?
Есть ли в вашем процессе хотя бы какой-то контроль качества?
Есть ли у вас вообще клиенты в продакшене?

AI кодинг – это все еще тема, и правильный подход существует

Context engineering – реально полезная штука. На самом деле в сути своей это онтологическая и системная инженерия.

Но говорить и применять прикладные решения, методы контекстной инженерии – это тоже хорошо. Например:

Компрессия контекста
research/plan/implement workflow
субагенты c ограниченной отвественностью для dirty work
Spec Driven Development, AgentOS
Применение баз знаний
Разделение контекстов, и так далее

Все это – хорошие практики, но экстраполяция “context engineering работает” → “можно вообще не читать код месяцами” это уже откровенный маркетинговый bullshit который не подтверждается эмпирически из раза в раз.

По крайней мере пока.

Но есть очень тонкий и важный нюанс который надо понимать. Об этом далее.

Любые спецификации и формализм – хорошая идея. Но спецификации ≠ реальность.

Спецификации – это модель, описание чего-то.

Код, программная система – это уже что-то из объективной физической реальности. Код выражает инварианты системы. Если ты не знаешь и не понимаешь эти инварианты – ты не понимаешь систему, не можешь о ней адекватно рассуждать.

Инвариант в программной инженерии — это правило или условие, которое всегда должно оставаться истинным в определённый момент работы программы (должно - не значит что всегда остается, отсюда берутся баги :)

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

Достаточно понять следующее – если какой то софт достиг состояния, когда он “делает что-то, чего бизнес от него хочет”, это значит что в этой программной системе есть инварианты, которые соблюдаются как минимум в некотором наборе условий.

Сильный, “настоящий” инвариант, да вообще инвариант – это то что соблюдается практически всегда. Это показатель надежной системы, и это то чего непрозрачно хочет от программной системы бизнес.

Выходит что не-важно в каком мире мы существуем – в мире software 1.0, 2.0, или 3.0. Важно понимать – у кого “в голове” есть надежная картина системы со всеми требованиями/инвариантами, и кто способен адекватно про эти инварианты рассуждать и проверять их.

Текущие LLM способы? Скорее нет, чем да.

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

Как?

Ну вот, прямо вами, вашими глазами и мозгами будут проверятсья. А помогут вам в этом тесты: юнит-тесты, интеграционные-тесты, e2e-тесты, eval-тесты, любые всевозможные тесты, как можно больше тестов реально проверяющих поведение системы, а не под-капотную реализацию.

Тесты помогут вам проверить и новые изменений, и регрессию старой базы.

Так что нормальный процесс разработки с AI ассистентами, процесс направленный на надежность целевой системы AI-assisted может выглядеть как-то так:

AI генерит research/plan – ты внимательно читаешь, правишь, уточняешь.
AI пишет код по плану – ты смотришь изменения, вникаешь в дизайн и решения, вносишь правки-требования если надо.
AI пишет тесты – ты проверяешь покрытие, edge cases, и то что тесты не отошли от правила “Проверяй поведение, а не реализацию”.

Важно про тесты от LLM: Модели отлично генерят бесполезные тесты. Классика – тест проверяет что метод calculate() вызывает _internal_calculate(). Много ли в этом смысла? Такой тест зелёный, покрытие формально есть, а реальное поведение системы не проверено вообще. Это главная причина почему ревью тестов критически важен.

И по итогу ты можешь объяснить любому коллеге в команде что изменилось и почему.

Это очень верхнеуровневые штуки которые могут менять порядок, например в духе TDD – сначала генерим тест-спецификацию, а потом код. Либо вообще переплетаться – план и прочая документация может (и даже будет!) уточняться и меняться по ходу разработки.

Все эти блоки можно декомпозировать, внедрять под-агентов, автоматизировать любыми способами, но к сожалению или счастью, одно должно оставаться неизменным – ты, human in the loop.

Так что в spec driven development маркдауны это по сути лишь кусочки контекста для LLM по которым она может начать пытаться реализовать требуемые инварианты, а понимать и доказывать эти спецификации должны тесты и отчасти (пока еще от большeй) – белковые мозги.

Когда AI реально ускоряет

Я совсем не хочу создать впечатление что AI бесполезен в разработке. Вот примеры кейсов где я лично получил 2-3x ускорение:

Миграция API v1 → v2 с четкими правилами трансформации
Написание boilerplate кода (CRUD endpoints, типовые тесты)
Рефакторинг с сохранением поведения когда есть очень хорошее покрытие тестами
Массовая факторизация кода, когда недостаточно просто переименования идентификатора средствами IDE
Онбординг в новые проекты компании
Подконтрольное портирование ограниченных кусков кода между языками
Быстрая разработка качественных MVP пет проектов, которые можно дальше развивать и поддерживать

Общее: задачи с четкими правилами, где достаточно легко проверить результат.

Заключение

AI coding – мощный инструмент. Но когда начинается питч “не читаю код, доставляю 10 PR в день, трачу $12k на токены” и прочее – это не про продуктивность, а про накопление техдолга с третьей космической скоростью. Ну или просто брехня.

Нормальная метрика продуктивности – не количество PR, а:

Сколько фич работает в продакшене без хотфиксов и переделок
Сколько времени тратится на переделки, которые все возникают
Сколько инцидентов возникает в продакшене и как часто
Насколько команда понимает кодовую базу (это может выражаться в наличии или отсутствии актуальной и адекватной документации, например)
Как часто тесты отлавливают ломающие изменения

И все старые добрые метрики программной разработки. Ничего нового.

Так что когда читаете очередной success story про AI coding – смотрите не только на красивые цифры. Смотрите на умалчивания и отсутствие или наличие конкретики. Хороший success story по этой теме - это понятный если не с примерами построенного пайплайна, то хотя бы минимальным его описанием, из которого можно оценить степень присутствия человека и надежности процесса.

А то получится ровно как с тем джуном из первого поста – сгенерил 12 страниц спеки, потом по ней слоп-код, тестов нет, начинаем по кругу тратить время всей команды на фиксы-переделки.

Смешного мало, потому что “Vibe Code Cleanup Specialist” это уже не шуточные должности.

Иван Закутний про AI slop в кодогенерации