Двое инженеров, которые стояли у истоков нынешнего бума AI-кодинга, уже говорят не о прорыве, а о побочном эффекте. Главная проблема, как пишет The New Stack, не в самом vibe slop — так называют сырой и небрежный код от ИИ, — а в том, что команды накапливают context debt: долг по пониманию системы, ее ограничений и причин, почему она вообще работает.
Для русскоязычной IT-аудитории это важный сдвиг в оптике. Если раньше разговор шел в основном о скорости генерации фич и экономии часов разработки, то теперь все чаще обсуждают цену такого ускорения: кто будет сопровождать этот код через полгода, как его дебажить, и что произойдет, когда из команды уйдет человек, который еще помнил исходный замысел.
Симптом виден сразу, болезнь всплывает позже
Поводом для дискуссии стала волна критики вокруг vibe coding — подхода, при котором разработчик или даже не-разработчик описывает задачу на естественном языке и получает рабочий результат от модели. В этой модели разработки внешне все выглядит неплохо: прототип собирается быстро, интерфейс кликается, демо показывает нужный сценарий. Но именно здесь и появляется ловушка. Плохой код, лишние зависимости, странная структура файлов и случайные архитектурные решения — это еще не корень проблемы, а лишь ее внешнее проявление.
Термин vibe slop как раз описывает такой результат: код есть, а инженерной дисциплины в нем не наблюдается. The New Stack предлагает смотреть глубже и называть настоящую причину context debt. Речь о ситуации, когда команда все меньше понимает контекст, в котором был сгенерирован код: какие были допущения, где границы ответственности модулей, почему выбрана именно эта библиотека, какие риски уже были замечены и какие компромиссы были приняты по дороге. Пока продукт маленький, это терпимо. Когда система обрастает интеграциями, правами доступа, биллингом и легаси, такой долг начинает есть скорость уже с другой стороны.
В этом и состоит неприятная ирония всей истории. ИИ-инструменты обещали убрать рутину и снизить входной порог в разработку. На практике они действительно хорошо справляются с шаблонными задачами, черновой сборкой интерфейсов, glue-code и быстрыми экспериментами. Но вместе с ускорением они часто выносят за скобки именно то, что в зрелой инженерии ценится больше всего: понимание причинно-следственных связей внутри системы. Код можно сгенерировать быстро. Понять, почему он устроен именно так и что сломается при следующем рефакторинге, уже заметно труднее.
Что меняется для команд и бизнеса
На этом фоне критика звучит уже не только от скептиков со стороны, но и от людей, которые помогали делать AI-кодинг массовым. В связанных публикациях западных медиа фигурируют инженеры Армин Ронахер и Марио Цехнер, предупреждающие о риске превращения разработки в поток визуально правдоподобных, но плохо поддерживаемых решений. Их тезис неприятен именно потому, что он бьет не по хайпу, а по операционной реальности: компании могут довольно долго не замечать проблему, пока продукт еще растет и все заняты доставкой фич. Но потом оказывается, что скорость была взята в кредит.
Для CTO, техлидов и продактов это означает довольно приземленную вещь: метрика «мы выпустили быстрее» больше не работает без второй метрики — «мы сохранили управляемость системы». Если генеративный ИИ помогает сделать MVP за неделю, но через два месяца никто в команде не может уверенно объяснить логику авторизации, схему данных или условия, при которых безопасно обновлять зависимости, значит бизнес не сэкономил, а просто перенес расходы вперед. Причем с процентами.
Разработчикам эта история тоже хорошо знакома, просто теперь у нее новое имя. Раньше технический долг накапливался из-за спешки, копипаста, неудачных абстракций и компромиссов ради релиза. Теперь к этому добавляется context debt, когда код еще можно прочитать, но уже трудно восстановить исходный смысл его появления. Модель не несет ответственности за сопровождение, не дежурит по инцидентам и не приходит на архитектурный разбор. А вот команда потом приходит.
Отсюда и практический вывод, который просматривается за всей дискуссией: AI-кодинг работает заметно лучше там, где у команды уже есть сильный инженерный каркас. Нужны ревью, тесты, понятные архитектурные ограничения, документация по ключевым решениям и дисциплина в работе с контекстом. ИИ неплохо ускоряет набор текста и сборку типовых частей системы, но плохо заменяет коллективную память команды. Если этот разрыв игнорировать, то компания получает не «разработку будущего», а очень дорогую форму организационной амнезии.
Поэтому спор вокруг vibe coding постепенно уходит от вопроса «может ли ИИ писать код» к более жесткому вопросу: кто в команде владеет смыслом этого кода после генерации. Пока отрасль отвечает на него неуверенно, разговор о context debt будет звучать все громче — и, похоже, именно он станет главным фильтром между быстрыми AI-демо и продуктами, которые переживают не только запуск, но и нормальную эксплуатацию.