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

Команда работает быстрее, чем когда-либо. Метрики скорости бьют рекорды. Код-ревью проходят гладко, тесты зелёные, PR-ы сливаются один за другим. Но за этим блеском скрывается расход, который ни одна метрика не фиксирует: разрыв между тем, сколько кода существует в системе, и тем, сколько из него хоть кто-то по-настоящему понимает. Адди Османи — инженерный лидер Google Chrome, автор книги Learning JavaScript Design Patterns — называет этот расход долгом понимания (comprehension debt). И предупреждает: проценты по нему растут быстрее, чем по техническому долгу.

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

Маргарет-Энн Стори описывает студенческую команду, которая наткнулась на стену на седьмой неделе: они больше не могли вносить простые изменения, не ломая что-нибудь неожиданное. Проблемой был не грязный код. Проблемой было то, что никто в команде не мог объяснить, почему были приняты те или иные проектные решения и как разные части системы должны работать вместе. Теория системы испарилась.

Недавнее исследование Anthropic подтверждает это количественно. В рандомизированном контролируемом эксперименте с 52 инженерами участники, использовавшие ИИ-ассистента, завершали задачу за то же время, что и контрольная группа, — но на последующем тесте на понимание кода набрали на 17% меньше баллов (50% против 67%). Наибольшее падение — в навыках отладки. Пассивное делегирование («просто сделай это») разрушает формирование навыков значительно сильнее, чем активное использование ИИ для вопросов и изучения компромиссов.

Ключевые выводы

- Долг понимания — это не технический долг. Технический долг виден; долг понимания порождает ложную уверенность.
- ИИ генерирует код быстрее, чем человек способен его проверить. Прежний фильтр качества стал узким местом пропускной способности.
- Тесты необходимы, но недостаточны: нельзя написать тест на поведение, о котором никто не подумал.
- Спецификации тоже не спасают: между спецификацией и работающим кодом лежат сотни неявных решений.
- Ни одна текущая метрика не отражает этот долг. Velocity, DORA, покрытие кода — всё зелёное, пока понимание тихо выгорает.
- Удешевление генерации кода не удешевляет понимание. Работа по пониманию — это и есть работа инженера.

Асимметрия скорости — ИИ генерирует быстрее, чем человек проверяет

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

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

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

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

Тесты — необходимы, но недостаточны

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

Это помогает. Но у этого подхода есть жёсткий потолок.

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

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

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

Данные это подтверждают. Разработчики, делегирующие ИИ генерацию кода, набирают менее 40% на тестах понимания. Разработчики, использующие ИИ для концептуальных вопросов — исследования компромиссов, выяснения «почему» — набирают выше 65%. Инструмент не разрушает понимание. Его разрушает то, как вы этот инструмент используете.

Спецификации — тоже не спасут

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

Это привлекательно ровно так же, как когда-то был привлекателен Waterfall. Строго определите проблему, затем исполните. Чистое разделение ответственности.

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

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

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

Учитесь у истории

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

Что меняется с ИИ: стоимость (резко ниже), скорость (резко выше), управленческие накладные расходы на межличностное взаимодействие (практически ноль). Что не меняется: потребность в человеке с глубоким контекстом системы, который поддерживает связное понимание того, что кодовая база действительно делает и почему.

Это некомфортное перераспределение, к которому вынуждает долг понимания.

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

Проблема измерения — метрики не видят этот долг

Долг понимания так опасен именно потому, что ничто в текущей системе измерений его не отражает.

Метрики скорости (velocity) выглядят безупречно. DORA-метрики держатся стабильно. Количество PR растёт. Покрытие кода тестами — зелёное.

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

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

Организационное допущение «отревьюенный код = понятый код» больше не работает. Инженеры утверждали код, который они не до конца понимали, — и этот код теперь несёт неявное одобрение. Ответственность распределилась, а заметить это не успел никто.

Регуляторы придут быстрее, чем вы думаете

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

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

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

Что на самом деле требует долг понимания

Правильный вопрос сейчас — не «как генерировать больше кода?», а «как понимать больше из того, что мы отгружаем?» — чтобы пользователи получали стабильно качественный продукт.

Этот сдвиг фокуса имеет практические следствия:

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

Удешевление генерации кода не удешевляет понимание. Работа по пониманию — это и есть работа инженера.

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

Вы заплатите за понимание рано или поздно. Проценты по этому долгу растут быстро.

Частые вопросы

Чем долг понимания отличается от технического долга?

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

Значит ли это, что ИИ-инструменты для кодинга вредны?

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

Как измерить долг понимания в команде?

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

Что делать прямо сейчас?

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

Выводы

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

Оригинал статьи: Comprehension Debt — the hidden cost of AI generated code (Addy Osmani, март 2026).