Представьте команду разработки, которая внедрила ИИ-генерацию кода. Первые недели — эйфория. Velocity вырос на 40%. Задачи закрываются быстро, бизнес доволен, менеджеры смотрят на дашборд и улыбаются. Потом приходит момент, когда нужно изменить один из модулей, написанных ИИ.

И вот тут выясняется, что никто в команде не может этого сделать. Не потому что сложно, а потому что непонятно вообще, что там происходит. Единственный путь вперёд — переписать всё с нуля.

Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. Мы уже писали про технический долг и про то, как ИИ меняет жизнь разработчиков — и не всегда в лучшую сторону.

Сегодня хочу поговорить о том, что из этого выросло: о новом виде долга, который мы пока толком не научились называть, зато уже научились на нём обжигаться.

Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.

Это не технический долг. Хотя похоже

Техдолг появляется, когда команда гонится за результатом и не вкладывает время в то, чтобы сделать нормальное решение. Всё понятно, все виноватые известны.

С ИИ-долгом история формально та же: торопимся, выпускаем, не думаем. Только виноватый другой. Точнее — его нет :)

Потому что технически команда сделала всё правильно: взяла инструмент, получила результат, сдала задачу. Просто никто не проверил, что именно этот инструмент написал.

Вот в чём принципиальная разница между человеческим техдолгом и ИИ-долгом. Когда разработчик делает что-то наспех, он всё равно понимает, что делает. Он держит контекст в голове, видит риски, хотя бы немного стесняется оставить совсем уж плохое решение. Джун, которому сказали «сделай быстро» — он сделает криво, но более-менее рабочее. Потому что ему неловко сдавать совсем плохое.

ИИ не стесняется. Если сказать ему «сделай быстро» — он сделает быстро. Но плохо. Ровно настолько плохо, насколько ему позволили.

Почему это не видно сразу

Главная ловушка ИИ-долга — он долго не проявляется. Задачи закрываются, метрики зелёные, velocity растёт. Никаких тревожных сигналов. Момент истины наступает позже, когда вдруг нужно модифицировать то, что ИИ написал три месяца назад.

Я как-то проверил это на практике, просто из любопытства. Попросил ИИ реализовать фичу. Он реализовал и сообщил, что всё готово. Я спросил: «А что бы ты ещё сделал?» Он нашёл что улучшить. Я спросил ещё раз — нашёл ещё. И так пять-шесть итераций подряд, пока наконец не ответил что-то вроде «ладно, кажется, теперь всё».

Ключевое слово — «кажется»

Это значит, что код, который вам сдали как «готовый», в момент сдачи содержал баги, которые сам же ИИ потом и нашёл — просто потому что его спросили. А если бы не спросили, так бы и ушло в прод. Именно так и копится ИИ-долг: незаметно, задача за задачей, спринт за спринтом, а потом разработчик превращается в уборщика этих косяков — об этом писали на Хабре тоже.

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

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

Второй пример из общемировой практики, уже масштабнее. Сервис OpenClaw — форум, полностью написанный с помощью ИИ-генерации кода. В какой-то момент обнаружилось, что слить всю базу данных сервиса — вообще не проблема, потому что безопасность нормально не настроена. Всё выглядело нормально, всё работало, а глубже никто не проверил. ИИ написал, человек запустил, база оказалась открытой.

Вот почему установка «я написал за пять минут, значит, и перепишу за десять» — это самообман. Перепишете. Только не за десять минут, и не вы.

Это старая история, просто на другой скорости

Есть паттерн, который повторяется в истории разработки раз за разом — и понимание этого помогает не паниковать, но и не расслабляться.

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

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

ИИ — следующий уровень этой же логики. Раньше нужно было думать и писать код, теперь можно не думать вообще — просто описать задачу словами. Риски не исчезли, они просто стали больше, менее видимыми и более сложными в отладке.

ИИ-долг — не новая проблема. Это та же проблема, что всегда, просто темп её накопления вырос на порядок.

Что же делать?

Запрещать ИИ — не выход, это очевидно. Игнорировать проблему — тоже. Мы рассматривали три реальных варианта, и у каждого есть своя логика.

Первый вариант — использовать ИИ только как справочную систему

Не для написания кода, а для навигации по документации, ускорения онбординга, поиска ответов в сложных технических материалах. Здесь ИИ работает хорошо и не создаёт долга.

У нас был конкретный кейс: мы проводили исследование графовых баз данных и выбирали, какую внедрять. Одна из кандидатур — Memgraph. У них документация была подключена к ИИ-ассистенту ещё три года назад, и настроена она действительно хорошо. Мы разобрались с Memgraph, написали тестовый подход и провели нагрузочное тестирование за один день. Аналогичную по сложности базу данных без такой поддержки мы разбирали больше пяти дней — документация была непонятной, структурированной поддержки не было, вопросы некуда задать.

Разница колоссальная и очень наглядная.

В эту же логику вписываются MCP-серверы — это протокол, который позволяет ИИ обращаться к актуальной документации в реальном времени, а не опираться на то, что было в обучающей выборке год назад. Мы работали с PowerSync, решением для синхронизации локальных баз данных в браузере, это достаточно нишевый продукт. Документация обновляется редко, поэтому ИИ не знал, как работать с последней версией, и генерировал код на основе устаревших данных. Команда PowerSync решила это просто: написала собственный MCP-сервер, к которому ИИ обращается напрямую и получает актуальную информацию.

Результат — рабочий код без галлюцинаций.

Второй вариант — внедрить ИИ на полный цикл разработки, но делать это осознанно

Здесь два пути: либо выстроить нормальное ревью каждой строчки, которую написал ИИ — и нанять людей, которые будут это делать, либо осознанно выпускать на свой страх и риск. Второй путь звучит безрассудно, но он реален — при условии, что вы понимаете риски. Просить ИИ проверить самого себя — это 50 на 50, и история с OpenClaw это подтверждает. Иногда он найдёт что-то важное, чаще скажет «всё отлично» и окажется неправ.

Третий вариант — использовать ИИ как ассистента при разработке, а не как замену разработчику

Он помогает думать над сложной функциональностью, предлагает подходы, ускоряет мозговой штурм. Но финальное решение — за человеком, и человек понимает каждую строчку, которая идёт в прод.

Где мы оказались

Мы пришли к третьему варианту с элементами первого. ИИ помогает нам разбираться в документации и думать над сложными кейсами. Заменять разработчика мы не стали — и дело не в консерватизме.

Мы делаем коробочные решения, которыми компании пользуются в проде. Нельзя выпустить криво и надеяться, что никто не заметит — заметят. И скажут. Поэтому для нас ИИ-генерация кода без нормального ревью просто обходится дороже, чем написать самим. Мы это проверили.

Меня в этой ситуации больше всего удивляет вот что: всё, о чём я написал, давно очевидно тем, кто пишет код. Но на уровне принятия решений эту проблему почти никто не называет своим именем. Velocity растёт — значит, всё хорошо. Сколько ИИ-долга накопилось за этим velocity — никто не считает. И не считает ровно до того момента, когда трогает модуль, написанный три месяца назад.

***

Как у вас устроена работа с ИИ в команде? И приходилось ли вам сталкиваться с тем, что разобраться в ИИ-коде или исправить его оказывалось дороже, чем написать заново?