Гендиректор Port описал бесконтрольный vibe coding тремя словами: vibe coding slop. Формулировка резкая, но для команд, которые уже подсели на генерацию кода, она звучит слишком знакомо: без правил, проверок и внятной ответственности AI легко ускоряет не разработку, а накопление хаоса.
В публикации об AI-разработке и governance, сообщает The New Stack, глава Port сводит проблему к неприятой, но практичной мысли: сам по себе AI-кодинг не катастрофа, катастрофа начинается там, где его встраивают в инженерный процесс по принципу «пусть ребята пробуют». Когда вокруг модели нет ограничений, ролей, стандартов и нормальной проверки, компания получает не магию продуктивности, а смесь из случайных решений, неочевидных зависимостей и кода, за который потом никто не хочет отвечать.
Сам термин vibe coding за последние месяцы окончательно вышел из статуса шутки для X и Hacker News. Он описывает режим, в котором разработчик или вовсе не разработчик задает модели намерение на человеческом языке, получает рабочий на вид результат и двигается дальше, часто не особо вникая, что именно сгенерировалось внутри. В простых демо это выглядит убедительно: экран мигает, фича появляется, менеджер доволен, в презентации можно смело писать про ускорение. Проблема в том, что продакшен не обязан уважать красивое демо. В реальной системе важны не только скорость первого коммита, но и то, как код живет через месяц, кто его дебажит, как он проходит аудит, насколько он совместим с внутренними стандартами и что произойдет после третьей итерации изменений.
Именно здесь тезис Port попадает в нерв рынка. AI-инструменты снизили стоимость старта почти для всех: джуны быстрее собирают прототипы, продакты чаще лезут в код, фаундеры охотнее тестируют идеи без отдельной команды, а корпоративные разработчики все активнее делегируют рутину агентам и ассистентам. Но снижение порога входа не отменяет инженерную дисциплину, а делает ее еще важнее. Если раньше слабая архитектура хотя бы требовала часов ручной сборки, то теперь ее можно масштабировать с пугающей скоростью. Непродуманный сервис, плохая схема доступа, дублирующаяся бизнес-логика и дырявая интеграция теперь появляются не медленнее, а быстрее. AI не изобрел техдолг, он просто научился разгонять его в режиме xN.
Для платформенных команд и DevEx-подразделений это отдельный вызов. Когда в компании десятки или сотни инженеров используют разные модели, разные IDE-ассистенты и разные внутренние инструменты, вопрос уже не в том, «разрешать ли AI». Вопрос в другом: кто задает границы, где проходит обязательная проверка, какие шаблоны считаются допустимыми, что можно генерировать автоматически, а что нет, где нужен human review, как отслеживается происхождение изменений и чем подтверждается их безопасность. По сути, Port говорит о том, что AI-кодинг перестал быть частной привычкой разработчика и стал предметом внутренней политики. А это уже зона platform engineering, security и техруководства, а не только личной продуктивности.
Для русскоязычной IT-аудитории здесь особенно полезен один трезвый вывод. Обсуждение AI в разработке часто застревает между двумя карикатурами: либо «всех заменят агенты», либо «ничего не работает, можно расходиться». Реальность скучнее, а значит важнее. Работает многое, но хорошо работает в тех командах, где есть контекст, ограничения и взрослый процесс. Там, где моделью закрывают узкие задачи, где есть понятный owner, тесты, ревью, аудит изменений и договоренность о том, что сгенерированный код не считается автоматически хорошим кодом, выигрыш действительно может быть заметным. Там же, где AI выдали как корпоративную игрушку без изменения процессов, он начинает производить ложное ощущение скорости. На доске задач движение есть, в репозитории коммиты есть, а в системе растет количество мест, которые потом страшно трогать.
Бизнесу эта история тоже должна быть понятна без лишней философии. Бесконтрольный AI dev редко взрывается в день запуска. Он обычно маскируется под успех, пока не начинается серия обычных для любого продукта событий: новая интеграция, смена команды, аудит безопасности, рост нагрузки, инцидент или попытка масштабировать прототип в стабильный сервис. Тогда и выясняется, что код писался быстро, но знание о нем не закрепилось; что решение выглядит рабочим, но не соответствует внутренним требованиям; что агент удобно создавал изменения, но никто не продумал, как ими управлять. Издержки появляются не в виде красивой строчки в P&L, а в виде замедления релизов, лишних ревью, повышенного риска и зависимости от нескольких людей, которые еще помнят, почему эта конструкция вообще не падает.
На этом фоне спор о том, полезен ли vibe coding, выглядит все менее содержательным. Он уже есть, и откатить индустрию обратно к эпохе «только руками и только через боль» никто не сможет. Более интересный вопрос звучит иначе: кто первым построит для AI-разработки не витрину с автокомплитом, а нормальную систему управления, где скорость не съедает надежность. Если в ближайший год рынок начнет массово вкладываться именно в governance-слой вокруг генерации кода, это будет куда более важный сигнал, чем очередная демонстрация того, как модель за 30 секунд пишет CRUD. Подробности исходной публикации можно посмотреть в .