Технический долг от AI-кода: почему быстрый запуск веб-сервиса оборачивается ростом расходов на поддержку

Разговор с клиентом в 2026 году часто начинается так: «Мы уже сделали прототип с нейросетью за две недели, осталось доделать». Мы открываем репозиторий — и доделывать нечего. Нужно переписывать.

Код при этом выглядит прилично: отформатирован, с комментариями, работает. Проблема не в синтаксисе. Скорость написания кода и скорость его поддержки — разные вещи. AI ускоряет первое и почти не влияет на второе. Пока проекту две недели, разницы не видно. Она проявляется на третьем месяце, когда нужно добавить функцию, а встроить её некуда: архитектуры нет, есть набор рабочих кусков, соединённых как получилось.

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

Сам по себе долг не зло. Осознанно срезать угол ради срока — нормальная инженерная практика. Но при одном условии: вы знаете, где именно срезали и когда вернётесь.

AI ломает это условие. Раньше костыли писали руками, и автор помнил о них. Теперь код появляется быстрее, чем человек успевает его прочитать. В проект попадают решения, которых никто не принимал. Через полгода спросить «почему здесь так» не у кого: автор — модель, и на повторный запрос она выдаст другой ответ.

Мы называем это долгом понимания. Он опаснее кривого кода. Обычный долг видно: дубли, старые библиотеки, отсутствие тестов — всё это находит анализатор. Долг понимания не находит ничто. Формально порядок, фактически в команде нет человека, который держит систему в голове целиком.

Дальше начинается арифметика. Каждая правка превращается в расследование: разработчик тратит день не на новую функцию, а на попытку понять старую. На проектах, куда мы заходили после AI-прототипов, соотношение примерно такое: час пишем, три-четыре разбираемся. При обычной разработке — наоборот.

AI-код опасен не везде. Разметка и типовые компоненты — безопасная зона: кнопка либо выглядит правильно, либо нет, переписать её дёшево. Проблемы начинаются дальше.

Данные. Модель пишет запрос, который отлично работает на десяти записях и роняет базу на ста тысячах. Она не знает объёма ваших данных и не видит плана выполнения. Отсутствующий индекс на тестовой выборке не проявляется никак. Он выстрелит в проде — ровно тогда, когда сервисом начнут пользоваться.

Права доступа. Сгенерированный код почти всегда проверяет, что пользователь вошёл. И почти никогда — что этот пользователь имеет право видеть именно этот заказ. Подставил чужой номер в адресе, увидел чужие данные: в AI-коде эта дыра встречается системно. Для модели требование неочевидно — в запросе про «личный кабинет» никто не написал, что Иванов не должен видеть заказы Петрова.

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

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

Разговоры о качестве кода не убеждают никого, поэтому считаем.

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

Дальше вторая часть, которую на старте не считают. Поддержка обычного проекта стоит 15–20% от разработки в год. Поддержка проекта с AI-долгом — 40–50%. Разница набегает из трёх источников: время на разбор кода перед каждой правкой, повторные исправления одного и того же места, аварии, которых не должно было быть.

Отдельная строка — вход нового разработчика. Там, где есть архитектура и документация, человек начинает приносить пользу через неделю. В проекте с долгом понимания — через месяц. И весь этот месяц вы платите двоим: новичку и тому, кто ему объясняет.

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

Сразу оговорюсь: AI ни в чём из перечисленного не виноват. Мы пользуемся им каждый день и отказываться не собираемся. Виновата подмена понятий — скорость появления кода приняли за скорость создания продукта.

Внутреннее правило звучит так: сгенерировал — отвечаешь как за написанное руками. Фразу «так предложила модель» в обсуждении кода мы не принимаем. Именно после неё ответственность растворяется.

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

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

Ревью проходит каждый сгенерированный фрагмент. Условие жёсткое: проверяющий объясняет своими словами, что этот код делает. Не объяснил — фрагмент не принят, даже если работает.

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

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

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

И заложите в бюджет обслуживание долга: 15–20% времени команды. Если этой строки нет, рефакторинг не случится никогда — его всегда вытеснят новые функции.

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

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

Попросите включить в договор ревью сгенерированного кода и тесты на критичные сценарии: оплату, регистрацию, права доступа. Формулировка простая — подрядчик отвечает за код независимо от того, кто его написал.

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

Дальше сервис живёт нормально и развивается обычными спринтами. Разбор занял три недели против пяти месяцев, которые ушли бы на переписывание с нуля.

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

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

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

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

Заказчик не читает код, и это нормально. Проверить состояние проекта можно без технических знаний — по пяти признакам.

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

Тревожные признаки зеркальны. На любой вопрос о сроках отвечают «надо посмотреть». Правки в одном месте ломают другое. Никто не берётся оценить работу без предварительного исследования. Звучит фраза «это сгенерировано, мы не разбирались». Появляется человек-ключ, без которого не двигается ничего.

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

Значит, AI использовать не стоит?

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

Как понять, что нам достался проект с AI-долгом, если мы не программисты?

Попросите объяснить три вещи: как устроена авторизация, что произойдёт при сбое платёжного шлюза и почему выбрана такая структура данных. Внятные ответы — решения принимались осознанно. «Так сгенерировалось, работает же» — повод для аудита.

Сколько стоит разгрести накопленный долг?

Аудит с планом — одна-две недели. Приведение критичных зон в порядок — от трёх недель до двух месяцев. Всегда дешевле переписывания и почти всегда дешевле ещё одного года поддержки в текущем виде.

Можно ли договориться заранее, чтобы долг не копился?

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

AI ускоряет написание кода, но не создание продукта. Самый дорогой долг — не кривой код, а отсутствие человека, понимающего систему целиком. Поддержка сервиса без архитектурных решений стоит не 20% от разработки, а вдвое больше. Лечится это не отказом от инструмента, а процессом, где за каждый фрагмент отвечает человек.

Мы разрабатываем веб-сервисы и беремся за проекты, которые нужно привести в порядок после быстрого прототипа. Начинаем с аудита и технического задания на доработку, дальше ведём развитие с поддержкой. Как это выглядит на длинной дистанции, видно в кейсе «Регро Вахта»: сервис живёт и обновляется ежемесячно не первый год.