Привет, Хабр! Меня зовут Анатолий Овчинников, я продакт-менеджер PRO-сервисов платформы Insight (ИТ-холдинг LANSOFT). Отвечаю за архитектуру продуктов, которые живут в проде годами и переживают не один состав команды. ИИ мы используем каждый день — поэтому его эффекты я вижу не на демо, а на дистанции в месяцы, когда к коду возвращаются. Три месяца назад я заметил неприятную закономерность в бэклоге: все чаще туда попадали мелкие фиксы вокруг кода, который до этого писал ИИ. Не аварии, не падения прода, не критичные инциденты — обычные доработки, которые на первый взгляд не выглядели тревожно. Сам код тоже не был плохим: аккуратная структура, нормальные имена, тесты, местами удачные абстракции. Такой PR сложно развернуть на ревью просто потому, что «что-то не нравится»: формально он выглядит как результат нормальной инженерной работы.

Проблема проявлялась позже, когда нужно было не поправить строку, а объяснить, почему решение устроено именно так. Почему появился этот слой абстракции, почему состояние хранится здесь, почему один сценарий обработан явно, а другой спрятан в побочный эффект. Код работал, но его смысл уже не принадлежал команде полностью.

Что такое comprehension debt

В марте 2026 года Addy Osmani описал эту проблему как comprehension debt — долг понимания. Это разрыв между кодом, который уже живет в системе, и кодом, который команда действительно понимает: почему решение устроено именно так, какие компромиссы в него заложены, какие сценарии оно покрывает и где проходят его границы. Важно не то, видел ли кто-то этот файл на ревью, а сможет ли команда безопасно изменить его через месяц или год.

От обычного технического долга comprehension debt отличается тем, что он хуже заметен. Технический долг часто выдает себя сам: запутанными зависимостями, дублированием, хрупкими тестами, медленной сборкой или модулем, к которому никто не хочет прикасаться. Долг понимания может прятаться в аккуратном коде: структура есть, тесты зеленые, ревью пройдено, но команда умеет воспроизвести поведение лучше, чем объяснить его причины. В AI-assisted разработке это особенно опасно: в репозиторий попадает не просто код, а решение, которое команда еще не успела присвоить инженерно.

Почему ИИ-код быстрее создает долг понимания

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

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

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

Данные: это не личная паранойя, а системный эффект

Можно было бы списать это на локальный опыт: конкретная команда, конкретный стек, конкретный способ работы с ИИ. Но похожие сигналы уже видны в больших выборках. Они не сводятся к простому выводу «ИИ пишет плохой код». Картина интереснее: ИИ-инструменты действительно ускоряют производство кода, но вместе с этим растет нагрузка на сопровождение, ревью и последующее исправление.

GitClear в отчете по качеству AI-assisted кода анализировал 211 млн измененных строк за 2020–2024 годы. В выборке заметен сдвиг в сторону менее поддерживаемых изменений: доля строк, связанных с рефакторингом (в терминологии GitClear — «перемещенный» код), снизилась с 25% в 2021 году до менее 10% в 2024-м, а доля copy/paste-кода выросла с 8,3% до 12,3%. В более раннем отчете GitClear по 153 млн измененных строк за 2020–2023 годы отдельно фиксировался рост code churn — строк, которые откатывают или существенно меняют в течение двух недель после появления.

Это важный сигнал именно для темы comprehension debt. Проблема не только в том, что в проект попадает больше кода. Проблема в том, что больше кода начинает вести себя как временный: его быстрее добавляют, быстрее переписывают, чаще дублируют и реже перерабатывают в устойчивую структуру. Для команды это означает не просто рост объема репозитория, а рост объема решений, которые нужно потом заново читать, объяснять и приводить к общей архитектурной картине.

Есть и более прямые исследования ИИ-коммитов в реальных репозиториях. В работе Debt Behind the AI Boom авторы собрали 304 362 подтвержденных AI-authored коммита из 6 275 GitHub-репозиториев и отслеживали, какие проблемы вносят такие изменения: code smells, correctness issues и security issues. По их данным, более 15% коммитов от каждого из пяти рассмотренных ИИ-инструментов вносили хотя бы одну проблему, а 24,2% отслеженных AI-introduced issues доживали до последней ревизии репозитория. То есть часть долга не рассасывается сразу после merge, а остается жить в кодовой базе.

Отдельно стоит посмотреть на то, кто платит за этот долг. Исследование влияния GitHub Copilot на OSS-проекты показывает неприятный перекос: общий рост продуктивности в основном возникает за счет менее опытных или периферийных разработчиков, но дополнительная нагрузка по ревью и переделке ложится на core-разработчиков. После внедрения Copilot они ревьюят на 6,5% больше кода, при этом их собственная продуктивность по написанию оригинального кода падает на 19%.

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

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

Кейс с игрой: когда все части правильные, а система все равно ведет себя неправильно

Особенно наглядно эта проблема проявилась не в рабочем проекте, а в игре, которую мы делали вместе с ребенком. Я показывал сыну, как формулировать задачи для ИИ в рамках школьного проекта. Он придумал зомби, 13 этажей, Короля-скелета, королевский рубин и золотой сундук, а я помог превратить все это в более-менее связное описание задачи. После того как мы передали его ИИ, получили вполне внятную архитектуру: с отдельными системами, генерацией уровней, логикой врагов, предметами и тестами.

GameScene.js, метод _buildFloor, строки 116–122:

} else {

// Физическое тело только у стен вплотную к проходимым тайлам.

// Стены внутри массивов стен игрок никогда не достигнет — тела не нужны.

if (this._isBorderWall(x, y, walkable)) {

this.wallGroup.create(px, py, 'wall'); // Коллайдер есть

} else {

this.add.image(px, py, 'wall'); // Коллайдера нет, только изображение

}

}

Zombie.js, метод _scheduleMove, строки 30–45:

const tx = Math.round(this.sprite.x / TILE_SIZE);

const ty = Math.round(this.sprite.y / TILE_SIZE);

const openDirs = DIRS.filter(

d => walkable.has(${tx + d.x},${ty + d.y})

);

// Выбор направления движения

const d = pool[Math.floor(Math.random() * pool.length)];

this.sprite.setVelocity(

d.x * ZOMBIE_SPEED,

d.y * ZOMBIE_SPEED

);
// Следующие 600–1200 мс никто не проверяет,
// где зомби находится на самом деле

Почему ревью не всегда спасает

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

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

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

На ревью AI-generated и AI-assisted изменений стоит отдельно спросить

• Почему выбран именно этот подход?

• Какие альтернативы рассматривались и почему не подошли?

• Какие предположения в коде не зафиксированы явно?

• Где проходят границы применимости решения?

• Что произойдет при частичном отказе соседней системы?

• Как изменится поведение при росте нагрузки или объема данных?

• Тесты проверяют контракт поведения или только текущую реализацию?

• Сможет ли другой разработчик изменить этот код через полгода, не восстанавливая всю историю с нуля?

Практики: как работать с AI-кодом и не терять контроль

Из этого опыта у меня сложилось главное правило: нетривиальную задачу нельзя начинать с просьбы «напиши код». Сначала нужно разобрать решение: какие есть архитектурные варианты, какие ограничения важны, какие части системы затрагиваются, где возможны edge cases, что будет при росте нагрузки и частичных отказах. На этом этапе модель полезна не как исполнитель, а как собеседник: она может предложить альтернативы, подсветить риски и задать вопросы, которые команда могла пропустить. Хороший первый запрос звучит не «сгенерируй сервис», а «разбери подходы, покажи плюсы, риски и ситуации, где каждый вариант лучше не использовать; код пока не пиши».

Вторая практика — фиксировать требования до генерации. Это не обязательно должна быть тяжелая спецификация, но в задаче или PR стоит явно указать цель изменения, ограничения текущей архитектуры, сценарии, которые нельзя сломать, известные edge cases, требования к производительности и безопасности, а также части системы, которые нельзя менять без отдельного обсуждения. Иначе модель все равно заполнит пустоты сама: достроит недостающий контекст из похожих задач и вернет правдоподобное решение. Иногда удачное, иногда нет. Но в обоих случаях команда может не заметить, где заканчивается исходное требование и начинается догадка ИИ.

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

Для AI-assisted изменений у нас есть жесткое правило: если автор PR не может словами объяснить сгенерированный код, его нельзя мержить. Речь не о том, чтобы помнить каждую строку, а о понимании решения: какую задачу оно закрывает, почему выбран именно этот подход, какие предположения заложены внутрь, что покрыто тестами, и где поведение может сломаться. Если на эти вопросы нет ответа, код уже может быть в репозитории, но еще не стал частью инженерной картины проекта.

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

Отдельно нужно проверять не только компоненты, но и стыки между ними. История с игрой показала именно это: коллайдер был, проверка тайлов была, но ошибка возникла на границе двух подсистем. В продуктовой разработке такие границы встречаются постоянно: кэш и источник данных, очередь и обработчик, API и ретраи, новая логика и старые клиенты. Хороший тест проверяет не то, вызывает ли функция нужный метод, а сохраняется ли обещанное поведение, когда соседняя часть системы ведет себя неидеально.

Как понять, что у команды накапливается долг понимания

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

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

Когда обсуждаете код:

• На вопрос «Почему решение устроено именно так?» автор отвечает не причиной, а историей генерации: «так предложила модель» или «так получилось».

• Чтобы объяснить решение, приходится открывать историю чата с ИИ, а не код или документацию. Объяснение существует вне репозитория.

• На вопрос «Почему?» отвечают пересказом того, что делает код. Именно разницу между «что» и «почему» важно отслеживать.

Когда меняете код:

• Оценка «здесь работы на полчаса» регулярно превращается в целый день — особенно вокруг одних и тех же модулей.

• Некоторые участки никто не решается менять «по-быстрому»: любое изменение начинается с полного восстановления контекста.

• Все чаще звучит фраза «проще переписать, чем разобраться» — хотя коду всего несколько недель или месяцев.

Когда что-то ломается:

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

• Исправление устраняет симптом, но никто в команде не может объяснить, почему проблема вообще возникла.

Самые тихие сигналы:

• Тесты проходят, но команда не может ответить, какое поведение они гарантируют. Они фиксируют текущую реализацию, а не контракт.

• Новый разработчик долго погружается в модуль не потому, что тот сложный, а потому что понимание осталось в чате с моделью, а не в проекте.

• Комментарии объясняют, что делает код, но нигде не зафиксировано, почему решение принято именно таким.

• Код читается легко, но ощущения владения им не возникает. Глаз чешется, а показать пальцем не на что.

Именно так чаще всего и ощущается долг понимания — задолго до того, как он проявится в серьезном инциденте.

Важно не превращать это в охоту на ведьм*перечеркнуто ИИ-код: ручной код тоже может быть непонятым. Разница в скорости. ИИ позволяет быстрее добавлять решения в репозиторий, поэтому команде нужны более явные способы проверять, что вместе с кодом в проект попало и понимание.

Вывод

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

Поэтому AI-код опасен не тогда, когда сразу ломается. Сломанный код быстро показывает, что с ним нужно разобраться. Гораздо опаснее код, который выглядит достаточно хорошо, чтобы попасть в прод, но остается недостаточно понятым, чтобы команда могла спокойно его менять. Главный вопрос уже не в том, может ли модель написать рабочую реализацию. Может. Вопрос в том, успеваем ли мы превратить эту реализацию в часть инженерной картины проекта: понять ее границы, зафиксировать причины решений и взять ответственность за то, что теперь живет в системе.

В проде живет не промпт, не чат с моделью и не красивая генерация. В проде живет решение. И отвечать за него все равно будет команда.