Addy Osmani advirtió sobre la deuda de comprensión en la generación de código con AI a escala

Addy Osmani описал новую проблему эпохи AI-кодинга: команды могут выпускать больше кода, чем успевают по-настоящему понять. Внешне всё выглядит нормально — тесты зелёные, pull request закрываются быстро, — но внутри копится долг понимания, который позже бьёт по качеству и скорости изменений.

Откуда берётся долг Под этим термином Osmani понимает скрытую цену зависимости от генераторов кода.

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

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

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

Скорость против понимания

Эту мысль частично подтверждает исследование Anthropic, на которое ссылается Osmani. В эксперименте 52 разработчика изучали новую библиотеку: группа с AI-помощником справилась примерно за то же время, что и контрольная, но показала более слабое понимание материала на последующем тесте — 50% против 67%. Самое заметное проседание обнаружилось в задачах на отладку.

Вывод не в том, что AI вреден сам по себе, а в том, что пассивный режим использования заметно ухудшает усвоение. В реальной команде это проявляется сразу в нескольких местах: junior-разработчик может сгенерировать больше кода, чем senior успеет критически проверить pull request растут быстрее, чем команда успевает восстановить архитектурный контекст одобрение изменений превращается из анализа в формальную процедуру метрики скорости улучшаются, даже если реальное понимание системы падает ## Почему тестов мало Osmani отдельно спорит с популярной идеей, что проблему можно закрыть тестами и подробными спецификациями. Да, автоматическая проверка нужна, особенно когда код генерируют агенты.

Но тесты отвечают только на те вопросы, которые кто-то заранее догадался сформулировать. Они не ловят неожиданное поведение, не объясняют скрытые компромиссы и не показывают, действительно ли изменение соответствует замыслу системы. Если AI меняет реализацию и заодно переписывает сотни тестов, зелёный pipeline ещё не означает, что всё в порядке.

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

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

За понимание всё равно придётся заплатить, и проценты по этому долгу

растут быстро.

Что это значит

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