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

14 октября 2025

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

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

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

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

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

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

TL;DR:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как?

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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