Долг понимания. Почему AI-код опасен не тогда, когда ломается
Три месяца назад я заметил кое-что неприятное в нашем бэклоге. Стали появляться задачи на фикс — не критичные, мелочи, — но почти все они касались кода, который писал ИИ. Красивого кода, местами даже элегантного, с хорошей структурой и оптимизациями, которые я бы сам так не написал. Проблема была не в том, что код плохой, а в том, что я его не понимал. А также в том, что самому ИИ в новой сессии требовалось какое-то время, чтобы в нём снова разобраться.
Я живу во всех этих сессиях. ИИ — нет. Houston, we have a problem.
В марте этого года Addy Osmani назвал это comprehension debt — долг понимания. Определение очень точное: это разрыв между тем, сколько кода существует в вашей системе, и тем, сколько из него хоть кто-то по-настоящему понимает. Не «читал однажды», не «примерно знает что делает», а реально держит в голове логику и может объяснить, почему оно именно так устроено.
Обычный технический долг хотя бы виден — есть ощущение, что «здесь грязно, надо переписать». Comprehension debt не виден почти никак: система работает, метрики растут, инциденты не горят. А потом в два часа ночи дежурный инженер читает стектрейс, понимает где именно упало, но не может рассказать, почему логика вообще была устроена именно так. Потому что этот кусок писал ИИ три месяца назад, и с тех пор его никто не трогал.
Данные подтверждают, что это системная история, а не личные ощущения. GitClear на больших выборках изменённого кода (153 млн строк в отчёте 2024 и 211 млн строк в отчёте 2025) фиксирует значительный рост code churn — доли кода, который откатывают или переписывают в течение двух недель после написания, — на фоне распространения AI-инструментов, вместе с падением доли рефакторинга и ростом копипасты. Отдельное крупное исследование отследило более 300 тысяч AI-коммитов в 6 275 репозиториях и показало, что 24% внесённых ИИ проблем доживают до последней ревизии репозитория — то есть долг не рассасывается сам, а накапливается. А работа по проектам с GitHub Copilot обнаружила, что бремя проверки и переделки этого кода ложится на опытных разработчиков: они теряют около 19% собственной продуктивности, уходя в ревью чужого кода. Это не значит, что ИИ пишет плохой код — это значит, что код пишется быстрее, чем команды успевают его понять и взять за него ответственность.
Но лучше всего это объяснил не рабочий проект, а игра, которую мы делали с моим ребёнком.
Он сам придумал требования — зомби, 13 этажей, Король-скелет на последнем уровне, королевский рубин, который нужно найти в золотом сундуке, чтобы убить зомби. Всё это он надиктовал ИИ, я не вмешивался. ИИ выдал код с правильной архитектурой, отдельными системами, генерацией уровней и даже тестами. Честно говоря, я был впечатлён.
А потом мы полночи отлаживали то, что казалось тривиальным: зомби проходил сквозь стены. В коде был и физический коллайдер, и проверка проходимых тайлов — каждый механизм выглядел правильно. Баг жил именно в точке их пересечения - там, где непрерывная физика встречалась с тайловой логикой, и ни один из них не знал о другом достаточно.
Но потом я открыл файл с требованиями и увидел кое-что интересное. Там были разделы, нумерация, выделенные жирным количества — «Всего зомби: 30», «Золотых сундуков: 30». Дети так не пишут требования. Это я, пока «просто помогал набирать текст», неосознанно редактировал формулировки. Мой архитектурный рефлекс сработал раньше, чем я это заметил — и именно поэтому ИИ выдал нормальную структуру на выходе.
Качество результата определилось не инструментом, а тем, кто формулировал вход. Даже когда этот человек был уверен, что не участвует.
Мы используем ИИ в разработке серьёзно и давно, и именно из этого опыта выросло несколько правил, которые мы теперь держим жёстко.
Разбор до кода. Перед реализацией любой нетривиальной вещи мы садимся и обсуждаем — архитектурные развилки, edge cases, поведение под нагрузкой, потенциальные уязвимости. ИИ в этом разговоре думает вместе с нами, предлагает варианты, указывает на то, что мы могли не заметить — но не генерирует за нас решение, которое мы потом мёржим не читая.
Роадмэп как память системы. Это не список фичей с дедлайнами, а зафиксированные решения: почему выбрали именно этот подход, что рассматривали и отвергли, где есть осознанный компромисс и почему он допустим. ИИ между сессиями забывает всё. Документ — нет.
ИИ объясняет, а не только пишет. Любое нетривиальное решение должно быть объяснено человеческим языком — не ради формальной документации, а чтобы контекст реально передавался внутри команды и не умирал вместе с сессией.
Безопасность и масштаб — на этапе проектирования, не после. Security-исследования показывают, что около 40% AI-сгенерированного кода в сценариях, специально нацеленных на типовые классы уязвимостей, оказываются небезопасными. Поймать это в ревью — дорого. Поймать на инциденте — намного дороже.
Всё ли это решает? Честно — нет. Долг понимания всё равно копится, просто там, где мы сознательно пошли на компромисс и это зафиксировали. Это другое качество долга — он хотя бы управляемый.
Хорошая новость в том, что это поддаётся измерению, и ранние признаки заметны задолго до кризиса. Если растёт число задач на фикс AI-написанного кода, если онбординг нового разработчика занимает всё больше времени, если любой рефакторинг начинается с фазы «разобраться, что здесь вообще происходит» — это оно.
Есть один простой тест, который я теперь использую как ориентир: можно ли объяснить любой модуль продукта, не открывая код? Не пересказать, что он делает по названию, а именно объяснить — с логикой, с граничными случаями, со всеми "почему так". Если нет — долг понимания уже накоплен, и неважно, человек его писал или ИИ.
Сталкивались с этим? Как держите под контролем — пишите в комментарии.
