Представьте команду разработки, которая внедрила ИИ-генерацию кода. Первые недели — эйфория. Velocity вырос на 40%. Задачи закрываются быстро, бизнес доволен, менеджеры смотрят на дашборд и улыбаются. Потом приходит момент, когда нужно изменить один из модулей, написанных ИИ.
И вот тут выясняется, что никто в команде не может этого сделать. Не потому что сложно, а потому что непонятно вообще, что там происходит. Единственный путь вперёд — переписать всё с нуля.
Меня зовут Артём Герасимов, я владелец продукта SimpleOne SDLC. Мы уже писали про технический долг и про то, как ИИ меняет жизнь разработчиков — и не всегда в лучшую сторону.
Сегодня хочу поговорить о том, что из этого выросло: о новом виде долга, который мы пока толком не научились называть, зато уже научились на нём обжигаться.
Отдельную благодарность за помощь в написании статьи выражаю автору SimpleOne Панфиловой Яне.
Это не технический долг. Хотя похоже
Техдолг появляется, когда команда гонится за результатом и не вкладывает время в то, чтобы сделать нормальное решение. Всё понятно, все виноватые известны.
С ИИ-долгом история формально та же: торопимся, выпускаем, не думаем. Только виноватый другой. Точнее — его нет :)
Потому что технически команда сделала всё правильно: взяла инструмент, получила результат, сдала задачу. Просто никто не проверил, что именно этот инструмент написал.
Вот в чём принципиальная разница между человеческим техдолгом и ИИ-долгом. Когда разработчик делает что-то наспех, он всё равно понимает, что делает. Он держит контекст в голове, видит риски, хотя бы немного стесняется оставить совсем уж плохое решение. Джун, которому сказали «сделай быстро» — он сделает криво, но более-менее рабочее. Потому что ему неловко сдавать совсем плохое.
ИИ не стесняется. Если сказать ему «сделай быстро» — он сделает быстро. Но плохо. Ровно настолько плохо, насколько ему позволили.
Почему это не видно сразу
Главная ловушка ИИ-долга — он долго не проявляется. Задачи закрываются, метрики зелёные, velocity растёт. Никаких тревожных сигналов. Момент истины наступает позже, когда вдруг нужно модифицировать то, что ИИ написал три месяца назад.
Я как-то проверил это на практике, просто из любопытства. Попросил ИИ реализовать фичу. Он реализовал и сообщил, что всё готово. Я спросил: «А что бы ты ещё сделал?» Он нашёл что улучшить. Я спросил ещё раз — нашёл ещё. И так пять-шесть итераций подряд, пока наконец не ответил что-то вроде «ладно, кажется, теперь всё».
Ключевое слово — «кажется»
Это значит, что код, который вам сдали как «готовый», в момент сдачи содержал баги, которые сам же ИИ потом и нашёл — просто потому что его спросили. А если бы не спросили, так бы и ушло в прод. Именно так и копится ИИ-долг: незаметно, задача за задачей, спринт за спринтом, а потом разработчик превращается в уборщика этих косяков — об этом писали на Хабре тоже.
При этом ИИ очень плохо адаптирует то, что уже написал. Есть исследование, что большинство моделей с трудом поддерживают собственный код — именно поддерживают, а не генерируют заново.
Примерно полгода назад я написал модуль в Gemini и в какой-то момент попросил исправить баг. Gemini исправил — удалил половину кода молча, без вопросов и, без предупреждений. По сути, проблема была решена, правда ценой половины функциональности.
Второй пример из общемировой практики, уже масштабнее. Сервис OpenClaw — форум, полностью написанный с помощью ИИ-генерации кода. В какой-то момент обнаружилось, что слить всю базу данных сервиса — вообще не проблема, потому что безопасность нормально не настроена. Всё выглядело нормально, всё работало, а глубже никто не проверил. ИИ написал, человек запустил, база оказалась открытой.
Вот почему установка «я написал за пять минут, значит, и перепишу за десять» — это самообман. Перепишете. Только не за десять минут, и не вы.
Это старая история, просто на другой скорости
Есть паттерн, который повторяется в истории разработки раз за разом — и понимание этого помогает не паниковать, но и не расслабляться.
Когда-то код писали на перфокартах. Медленно, мучительно, зато ошибок было мало. Не потому что разработчики были умнее, просто физически невозможно написать много плохого кода, когда каждая строчка — это физический труд.
Потом появились языки высокого уровня: писать стало быстрее и удобнее, но вместе с удобством пришли абстракции — и новый класс ошибок, которых раньше не существовало. Чем выше уровень языка, тем меньше ты контролируешь то, что происходит под капотом — и тем больше ошибок, которых ты просто не видишь.
ИИ — следующий уровень этой же логики. Раньше нужно было думать и писать код, теперь можно не думать вообще — просто описать задачу словами. Риски не исчезли, они просто стали больше, менее видимыми и более сложными в отладке.
ИИ-долг — не новая проблема. Это та же проблема, что всегда, просто темп её накопления вырос на порядок.
Что же делать?
Запрещать ИИ — не выход, это очевидно. Игнорировать проблему — тоже. Мы рассматривали три реальных варианта, и у каждого есть своя логика.
Первый вариант — использовать ИИ только как справочную систему
Не для написания кода, а для навигации по документации, ускорения онбординга, поиска ответов в сложных технических материалах. Здесь ИИ работает хорошо и не создаёт долга.
У нас был конкретный кейс: мы проводили исследование графовых баз данных и выбирали, какую внедрять. Одна из кандидатур — Memgraph. У них документация была подключена к ИИ-ассистенту ещё три года назад, и настроена она действительно хорошо. Мы разобрались с Memgraph, написали тестовый подход и провели нагрузочное тестирование за один день. Аналогичную по сложности базу данных без такой поддержки мы разбирали больше пяти дней — документация была непонятной, структурированной поддержки не было, вопросы некуда задать.
Разница колоссальная и очень наглядная.
В эту же логику вписываются MCP-серверы — это протокол, который позволяет ИИ обращаться к актуальной документации в реальном времени, а не опираться на то, что было в обучающей выборке год назад. Мы работали с PowerSync, решением для синхронизации локальных баз данных в браузере, это достаточно нишевый продукт. Документация обновляется редко, поэтому ИИ не знал, как работать с последней версией, и генерировал код на основе устаревших данных. Команда PowerSync решила это просто: написала собственный MCP-сервер, к которому ИИ обращается напрямую и получает актуальную информацию.
Результат — рабочий код без галлюцинаций.
Второй вариант — внедрить ИИ на полный цикл разработки, но делать это осознанно
Здесь два пути: либо выстроить нормальное ревью каждой строчки, которую написал ИИ — и нанять людей, которые будут это делать, либо осознанно выпускать на свой страх и риск. Второй путь звучит безрассудно, но он реален — при условии, что вы понимаете риски. Просить ИИ проверить самого себя — это 50 на 50, и история с OpenClaw это подтверждает. Иногда он найдёт что-то важное, чаще скажет «всё отлично» и окажется неправ.
Третий вариант — использовать ИИ как ассистента при разработке, а не как замену разработчику
Он помогает думать над сложной функциональностью, предлагает подходы, ускоряет мозговой штурм. Но финальное решение — за человеком, и человек понимает каждую строчку, которая идёт в прод.
Где мы оказались
Мы пришли к третьему варианту с элементами первого. ИИ помогает нам разбираться в документации и думать над сложными кейсами. Заменять разработчика мы не стали — и дело не в консерватизме.
Мы делаем коробочные решения, которыми компании пользуются в проде. Нельзя выпустить криво и надеяться, что никто не заметит — заметят. И скажут. Поэтому для нас ИИ-генерация кода без нормального ревью просто обходится дороже, чем написать самим. Мы это проверили.
Меня в этой ситуации больше всего удивляет вот что: всё, о чём я написал, давно очевидно тем, кто пишет код. Но на уровне принятия решений эту проблему почти никто не называет своим именем. Velocity растёт — значит, всё хорошо. Сколько ИИ-долга накопилось за этим velocity — никто не считает. И не считает ровно до того момента, когда трогает модуль, написанный три месяца назад.
***
Как у вас устроена работа с ИИ в команде? И приходилось ли вам сталкиваться с тем, что разобраться в ИИ-коде или исправить его оказывалось дороже, чем написать заново?
