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