“Долг понимания” (comprehension debt) — это скрытая цена, которую человеческий интеллект и память платят в результате чрезмерной зависимости от ИИ и автоматизации. Для инженеров это особенно актуально в сфере разработки агентных систем.
Когда команды активно используют инструменты для генерации кода с помощью ИИ, возникают определенные издержки, которые не отражаются в показателях производительности. Особенно это касается случаев, когда проверка всего кода, генерируемого ИИ, становится утомительной. Эти издержки накапливаются постепенно, и в конечном итоге их приходится оплачивать — с процентами. Это называется “долг понимания” или “когнитивный долг”.
В отличие от технического долга, который проявляется в явных проблемах — медленная сборка, запутанные зависимости, нарастающее чувство тревоги каждый раз, когда вы прикасаетесь к тому или иному модулю, — долг понимания порождает ложную уверенность. Код выглядит чистым. Тесты проходят успешно. Расплата наступает незаметно, обычно в самый неподходящий момент.
Маргарет-Энн Стори описывает студенческую команду, которая столкнулась с этой проблемой на седьмой неделе: они больше не могли вносить простые изменения, не ломая что-то неожиданное. Настоящая проблема заключалась не в неряшливом коде. Проблема была в том, что никто в команде не мог объяснить, почему были приняты те или иные проектные решения или как различные части системы должны взаимодействовать между собой. Теоретическая основа системы растворилась в коде.
Это накопление “долга понимания” в реальном времени.
Я читал обсуждения на Hacker News, где инженеры пытались решить структурную версию этой проблемы. Речь шла не о привычной дихотомии оптимизма и скептицизма, а о понимание того, как должен выглядеть строгий подход, когда узкое место разработки ПО изменилось.
В недавнем исследовании Anthropic под названием “Как ИИ влияет на формирование навыков” были освещены потенциальные недостатки чрезмерной зависимости от помощников в программировании на основе ИИ. В рандомизированном контролируемом исследовании с участием 52 инженеров-программистов, изучавших новую библиотеку, участники, использовавшие помощь ИИ, выполнили задание примерно за то же время, что и контрольная группа, но набрали на 17% меньше баллов в последующем тесте на понимание (50% против 67%). Наибольшее снижение наблюдалось при отладке кода. Также были отмечены меньшие, но все же значительные потери в понимании концепций и чтении кода. Исследователи подчеркивают, что пассивное делегирование (“просто сделай это работающим”) значительно ухудшает развитие навыков по сравнению с активным, основанным на вопросах использованием ИИ. Полная версия статьи доступна на arXiv: https://arxiv.org/abs/2601.20245.
Проблема асимметрии скорости
ИИ генерирует код гораздо быстрее, чем люди могут его обработать. Это звучит очевидно, но последствия легко недооценить.
Когда разработчик вашей команды пишет код, процесс проверки человеком всегда был узким местом, но при этом продуктивным и познавательным. Чтение их запросов на слияние заставляет понимать суть. Оно выявляет скрытые предположения, обнаруживает проектные решения, противоречащие архитектуре системы, разработанной полгода назад, и распространяет знания о том, что на самом деле делает код, среди людей, ответственных за ее поддержку.
Сгенерированный ИИ код разрывает этот замкнутый круг обратной связи. Объем слишком велик. Выходные данные синтаксически чисты, часто хорошо отформатированы, внешне корректны — именно те сигналы, которые исторически вызывали уверенность в допустимости слияния. Но поверхностная корректность — это не системная корректность. Кодовая база выглядит “здоровой”, в то время как понимание кода незаметно разрушается под ее поверхностью.
Я читал, как один инженер говорил, что узким местом разработки ПО всегда был компетентный разработчик, понимающий суть проекта. ИИ не снимает это ограничение. Он создает иллюзию, что мы его преодолели.
Обратная ситуация еще хуже. Когда разработка кода была дорогостоящей, опытные инженеры могли проверять его быстрее, чем младшие – писать. ИИ меняет правила игры: теперь младший инженер может генерировать код быстрее, чем старший – критически его оценивать. Фактор, ограничивавший скорость разработки и делавший проверку кода значимой, устранен. То, что раньше было критерием качества, теперь стало проблемой производительности.
Тесты не панацея
Стремление сильно полагаться на детерминированную верификацию — модульные тесты, интеграционные тесты, статический анализ, линтеры, форматеры — вполне понятно. Я часто так делаю в проектах, где активно используются агенты ИИ для программирования. Автоматизируйте процесс проверки кода. Пусть машины проверяют машины.
Это помогает. Там жесткие правила.
Набор тестов, способный охватить все наблюдаемые варианты поведения, во многих случаях будет сложнее, чем код, который он проверяет. Однако сложность, которую нельзя объяснить логически, не гарантирует безопасности. И за этим скрывается более фундаментальная проблема: невозможно написать тест для поведения, которое не было предусмотрено.
Кто-то пишет тесты, проверяющие, что элементы не становятся полностью прозрачными при перетаскивании? Конечно, никто не пишет. Такое обычно даже в голову не приходит. Именно такие ошибки и ускользают от внимания, не потому что набор тестов плохо написан, а потому что никто не догадался их проверить.
Существует также специфический режим отказа (failure mode), который стоит упомянуть. Когда ИИ меняет поведение реализации и обновляет сотни тестов в соответствии с новым поведением, вопрос смещается с “правилен ли этот код?” на “были ли все эти изменения в тестах необходимы, и достаточно ли у меня покрытия, чтобы обнаружить то, о чем я не подумал?”. Тесты не могут ответить на этот вопрос. Ответить может только понимание.
Данные начинают это подтверждать. Исследования показывают, что разработчики, использующие ИИ для “слепой” генерации кода, набирают менее 40% баллов в тестах на понимание, в то время как разработчики, использующие ИИ для концептуального анализа — задавания вопросов, изучения компромиссов — набирают более 65%. Сам инструмент не разрушает понимание. Понимание разрушает то, как инструмент используется.
Тесты необходимы. Но их недостаточно.
Спецификации не отражают всей картины
Распространенное предлагаемое решение: сначала написать подробную спецификацию на естественном языке. Включить ее в запрос на слияние. Проверять спецификацию, а не код. Предполагать, что ИИ точно перевел намерение в реализацию.
Это привлекательно так же, как когда-то была привлекательна каскадная методология. Сначала четко определите проблему, а затем приступайте к ее решению. Четкое разделение задач.
Проблема в том, что перевод спецификации в работающий код включает в себя огромное количество неявных решений — граничные случаи, структуры данных, обработка ошибок, компромиссы в производительности, шаблоны взаимодействия — которые ни одна спецификация никогда не сможет полностью охватить. Два инженера, реализующие одну и ту же спецификацию, создадут системы со множеством наблюдаемых различий в поведении. Ни одна из реализаций не является неправильной. Они просто разные. И многие из этих различий в конечном итоге будут иметь значение для пользователей так, как никто не предполагал.
Стоит отметить еще один нюанс, связанный с подробными спецификациями: спецификация, достаточно подробная, чтобы полностью описать программу, по сути, и есть эта программа, просто написанная на неисполняемом языке. Организационные затраты на написание спецификаций, достаточно подробных, чтобы заменить проверку, вполне могут превысить прирост производительности от использования ИИ для их реализации. И это еще без проверки того, что было фактически создано.
Более глубокая проблема заключается в том, что зачастую правильной спецификации просто не существует. Требования возникают в процессе разработки. Крайние случаи обнаруживаются в процессе использования. Предположение о том, что можно полностью описать нетривиальную систему до ее создания, неоднократно проверялось и оказывалось несостоятельным. ИИ этого не меняет. Он просто добавляет новый уровень неявных решений, принимаемых без участия человека.
Учитесь на ошибках истории
Десятилетия управления качеством ПО в распределенных командах с различными условиями и уровнем межличностной коммуникации позволили выработать реальные, проверенные методы. Эти методы не исчезают только потому, что членом команды стала модель.
С появлением ИИ меняются лишь стоимость (значительно ниже), скорость (значительно выше) и затраты на межличностное управление (практически равны нулю). Неизменной остается необходимость в специалисте, обладающем глубокими знаниями о системе, для поддержания целостного понимания того, что на самом деле делает код и почему.
Это неприятное перераспределение, которое навязывает нам недостаточная осмысленность информации.
По мере роста объемов ИИ, инженер, который действительно понимает систему, становится все более ценным, а не менее. Важно уметь, взглянув на различия в коде, сразу определить, какие модели поведения являются наиболее проблемными. Важно помнить, почему это архитектурное решение было вынужденно принято восемь месяцев назад.
Важно уметь отличать безопасный рефакторинг от незаметного изменения того, от чего зависят пользователи. Этот навык становится дефицитным ресурсом, от которого зависит вся система.
Пробел в измерениях
Опасность долга понимания заключается в том, что наша нынешняя система измерения его не учитывает.
Показатели скорости выполнения задач выглядят безупречно. Показатели DORA остаются стабильными. Количество запросов на слияние увеличилось. Покрытие кода — зеленое.
Контроллеры производительности видят улучшение скорости. Они не могут увидеть недостатки в понимании, потому что ни один из способов измерения результатов деятельности организаций не отражает этот аспект. Система стимулирования правильно оптимизируется для того, что она измеряет. То, что она измеряет, больше не отражает того, что действительно важно.
Именно поэтому долг понимания более коварен, чем технический. Технический долг обычно представляет собой осознанный компромисс — мы выбираем короткий путь, примерно знаем, в чем он заключается, и можем запланировать решение. Долг понимания накапливается незаметно, часто без какого-либо сознательного решения о его возникновении. Это совокупность сотен проверок, когда код выглядел нормально, тесты проходили, и в очереди был еще один запрос на слияние.
Предположение, что проверенный код понятен, больше не актуально. Одобрение инженерами кода, который они не до конца понимают, означает неявное одобрение плохого кода. Ответственность распределена незаметно для всех.
Горизонт регулирования ближе, чем кажется
Любая отрасль, развивающаяся слишком быстро, в конечном итоге оказывалась под регулированием. Технологическая отрасль оказалась необычайно защищенной от этой динамики, отчасти потому, что сбои в ПО часто можно исправить, а отчасти потому, что отрасль развивалась быстрее, чем регулирующие органы успевали за ней следить.
Это окно возможностей закрывается. Когда сгенерированный ИИ код работает в системах здравоохранения, финансовой инфраструктуре и государственных службах, утверждение “это написал ИИ, а мы не провели полную проверку” не выдержит критики в отчете об инциденте, когда на кону стоят жизни или ценные активы.
Команды, которые сейчас развивают дисциплину понимания — рассматривая подлинное понимание, а не просто прохождение тестов, как нечто само собой разумеющееся, — будут в лучшем положении, когда наступит решающий момент, чем команды, которые оптимизировали свою деятельность исключительно ради скорости разработки.
Суть проблемы
В настоящий момент правильный вопрос не в том, “как нам генерировать больше кода?”, а в том, “как нам лучше понимать то, что мы создаем?”, чтобы гарантировать нашим пользователям неизменно высококачественный опыт.
Такой подход имеет практические последствия. Он означает предельно четкое определение того, к чему должно привести изменение, прежде чем оно будет реализовано. Он означает, что проверка должна рассматриваться не как второстепенный вопрос, а как структурное ограничение. Он означает поддержание системной ментальной модели, которая позволяет выявлять ошибки ИИ на уровне архитектуры, а не построчно. И он означает честное определение разницы между “тесты пройдены” и “я понимаю, что это делает и почему”.
Сделать генерацию кода дешевой не означает, что понимание кода можно легко пропустить. Работа по пониманию — это и есть главная задача.
Перевод выполняется ИИ. Но кто-то все равно должен понять, что было создано, почему это было создано именно так и были ли эти неявные решения правильными — или же вы просто откладываете оплату счета, который в конечном итоге все равно придется оплатить в полном объеме.
Рано или поздно вам придется заплатить за понимание. На этот долг быстро начисляются проценты.
Дополнительные материалы:
Автор: aio350
