Технический долг от vibe coding: что показывают данные за 90 дней
Представьте собирательную, но очень узнаваемую историю. Команда выкатывает новую фичу в прод всего за пару дней. Код, сгенерированный ИИ-ассистентом, получает “LGTM 👍” на ревью и уходит в релиз в пятницу вечером. А спустя пару месяцев та же команда расплачивается за эту скорость — днями простоя, потерянным клиентом и разбором полётов с поиском виноватых. Детали у каждой такой истории свои, но сюжет один и тот же — и за последний год таких историй становится всё больше.
ИИ здесь не злодей — инструмент отличный. Но вместе с ним в индустрию пришёл новый тип технического долга, ставки по которому пока никто не научился считать.
Что такое vibe coding и почему об этом заговорили
Термин «vibe coding» придумал Андрей Карпати в начале 2025 года. Идея проста: ты не пишешь код, а описываешь, что нужно получить, нейросети, и берешь результат, особо не вдаваясь в детали. «Programming based on vibes».
К 2026 году это уже не просто мем. По данным опроса Stack Overflow, около половины профессиональных разработчиков пользуются ИИ-ассистентами ежедневно, а в целом так или иначе их применяют около 80%. И заметная часть признаётся, что коммитит код, «в целом понимая, но не разбирая построчно». Десять лет назад человек, который коммитил непроверенный код, рисковал работой. Сейчас это почти норма.
Дальше — ключевой момент. Код, который никто не читает на этапе написания, никто не читает и на ревью, и при отладке, и когда к проекту подключается новый разработчик. Он просто существует в репозитории, как некий чёрный ящик. До первого серьезного инцидента.
Почему 90 дней — это не случайность
Срок в 90 дней — не выдумка. Это наблюдение, которое сделали несколько CTO, с которыми мы общались за последние полгода. Процесс выглядит примерно так:
Первые недели — эйфория. Фичи появляются одна за другой, спринты закрываются с запасом, менеджмент доволен, разработчики чувствуют себя супергероями. Производительность растет в два-три раза.
Где-то к концу первого месяца начинаются странности. Баги, которые сложно воспроизвести. Падения в продакшене из-за граничных случаев, которые не были учтены в тестах, потому что ИИ сгенерировал тесты только для идеальных сценариев. Время на отладку начинает увеличиваться, но пока не критично.
На втором-третьем месяце долг становится осязаемым. Появляются модули, к которым никто не хочет прикасаться: дело даже не в их сложности — в них попросту невозможно разобраться. Стиль кода скачет с файла на файл: где-то функциональное программирование, где-то объектно-ориентированное, где-то вообще непонятно что. Абстракции не вяжутся друг с другом. Переменные в соседних модулях называются по-разному, потому что ИИ генерировал их для разных запросов.
А ближе к концу квартала начинается то, ради чего вся эта статья. Любое добавление новой фичи требует реверс-инжиниринга существующего кода. Адаптация нового джуниора, которая раньше занимала две недели, теперь может занять шесть — ведь здесь нет внутренней логики, только результат. И что самое неприятное: ИИ-ассистент, который должен был помочь разобраться в этом хаосе, начинает выдавать еще больше ошибок, потому что код, который он использует как контекст, сам был сгенерирован — и не всегда правильно.
Вот что такое 90-дневный счёт. Скорость, которую вы взяли взаймы в начале квартала, возвращается к вам в конце с процентами.
Почему ИИ-код особенно быстро устаревает
У человеческого кода, даже не самого лучшего, всегда есть одна важная особенность: за ним стоит логика и знания автора. Он знал, почему сделал именно так. Можно спросить, восстановить контекст. С ИИ-кодом этой логики нет. Промпт, по которому он был сгенерирован, часто не сохраняется. Цепочка рассуждений, которая привела к конкретной архитектуре функции, просто отсутствует.
Это меняет подход к работе со старым кодом. Раньше «легаси» — это код, написанный пять лет назад разработчиком, которого уже нет в команде. Сейчас «легаси» — это код, который вы сгенерировали во вторник на прошлой неделе и уже не помните, зачем он такой.
Ещё одна важная деталь: ИИ модели хорошо справляются с задачами, для которых есть много примеров в обучающих данных. То есть стандартные CRUD-операции, типовые компоненты, распространенные запросы — это всё генерируется отлично. А вот специфичная бизнес-логика вашей компании — это обычно что-то новое. И ИИ, не имея достаточного количества данных, начинает экстраполировать — и часто ошибается. Внешне код выглядит нормально, но внутри — нет. Это самые опасные баги, потому что они проходят все автоматические проверки.
Что говорят данные
Исследования качества кода в командах с активным ИИ за последние пару лет фиксируют устойчивый сдвиг. Картина такая:
Доля скопированного и слегка изменённого кода в репозиториях с активным ИИ за пару лет заметно выросла. Параллельно вырос объём кода, который переписывают в первые же недели после коммита — то есть почти сразу после публикации. Проще говоря, мы стали писать больше кода, который тут же приходится переделывать.
DevOps-метрики вроде DORA показывают ту же развилку: скорость доставки растёт, но стабильность падает — инцидентов в проде становится больше, а восстановление после них занимает дольше. Быстрее, но менее надёжно.
И ещё одно, о чём часто молчат. По нашим наблюдениям за командами, количество ревью с комментариями типа «в целом выглядит хорошо» без конкретной критики заметно выросло. Ревью превратилось в формальность — рецензент сам нередко не понимает, что вообще должно быть в этом коде.
Где это уже «выстрелило»
Один из самых громких случаев — история с Replit Agent в июле 2025 года. Автономный агент, получивший доступ к продакшен-базе данных, удалил рабочую базу с записями прямо во время code freeze — несмотря на прямой запрет что-либо менять. Хуже того: на вопрос о восстановлении он сначала заявил, что данные не вернуть, — хотя на деле их подняли откатом (rollback). Этот случай показателен вдвойне: и сам инцидент, и то, как уверенно ИИ ввёл человека в заблуждение насчёт последствий.
Другой характерный пример — из практики одного финтеха, который надолго увяз в отладке расчёта платежей. Оказалось, что ИИ сгенерировал функцию округления, которая в редких случаях отбрасывала копейки неправильно. Тесты были написаны и проходили — но они тоже были сгенерированы ИИ и проверяли именно это неправильное поведение. Это новый тип багов: тавтологичные тесты. Когда и реализация, и проверка написаны одной и той же моделью с одним и тем же ошибочным пониманием задачи.
Что с этим делать, не впадая в крайности
Запретить ИИ-ассистентов — нерационально. Это все равно, что запретить Stack Overflow в 2010 году. Поезд ушел, индустрия адаптировалась, конкуренты будут использовать этот инструмент, а вы проиграете.
Использовать ИИ бездумно — мы уже видим, к чему это приведет.
Из нашего опыта работы с ребятами на курсах Python и QA Automation, которые активно интегрируют ИИ, можно выделить несколько правил, которые реально снижают 90-дневный счёт.
Во-первых, генерируйте небольшими порциями. Когда вы просите ИИ написать целый модуль, вы получаете чёрный ящик. Когда просите написать одну функцию и сами ее просматриваете перед следующей — вы понимаете, что у вас в коде. Да, скорость немного снижается, но 90-дневный счет будет значительно меньше.
Во-вторых, пишите тесты самостоятельно, даже если генерируете код. Это, конечно, не самое увлекательное занятие. Но именно тесты — это спецификация того, что должен делать код. Если эту спецификацию написал тот же ИИ, что и код, то у вас в проекте нет спецификации, а есть две похожие реализации, и если обе неверные — вы об этом не узнаете.
В-третьих, договоритесь о правиле: если в ревью трех файлов подряд я говорю «LGTM» без внимательного изучения, то я ставлю review ниже, чем если бы обошелся без ИИ. Это правило для самодисциплины. Code review — это не просто формальность. Если оно стало формальностью, у команды большие проблемы, просто пока не очевидные.
Что это значит для тех, кто только начинает свой путь в IT
К нам часто обращаются с вопросом: зачем мне учиться писать код, если ИИ все сгенерирует? Ответ простой: ИИ генерирует код, но не берет на себя за него ответственность. Ответственность будете нести вы. Если вы не умеете читать код, понимать его логику и видеть потенциальные проблемы — вы будете тем самым разработчиком, который коммитит черные ящики. А разработчик, который коммитит черные ящики, и есть тот самый 90-дневный счёт, только в виде сотрудника.
Зато разработчик, который умеет читать код, понимает архитектуру и знает, где нейросеть может ошибиться, сейчас стоит дороже, чем три года назад. Ценят его теперь за другое — за то, что он отвечает головой за всё, что попадает в продакшен.
Это значит, что фундаментальные знания — алгоритмы, базы данных, понимание языка программирования — становятся еще важнее. Планка входа в профессию не опустилась, как многим хотелось бы думать, а сместилась: от умения набивать код к умению его читать и брать под контроль.
Что в итоге
Vibe coding — не хорошо и не плохо. Это инструмент с определенными возможностями. Если использовать его для ускорения работы там, где вы хорошо разбираетесь, он будет незаменим. Если использовать его как способ не думать — он тихо запишет это в долг, и счёт придёт через квартал.
Команды, которые осознали это в 2025-м, в 2026-м показывают лучшие результаты по DORA, чем в эпоху до ИИ. Команды, которые этого не поняли, увольняют технических лидеров и переписывают модули, которые сами же насочиняли пару кварталов назад. Инструмент у обеих команд был один и тот же — весь вопрос в том, читал ли кто-нибудь код, прежде чем тот уходил в прод.