Когнитивная капитуляция: когда ИИ-агенты пишут код, который вы не понимаете

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

Этот сценарий — центральная тема недавней статьи на Manager.dev, где исследуется, что происходит, когда разработчики передают ИИ-ассистентам вроде Claude не только генерацию кода, но и принятие решений. Автор, описывая ответ «Я не знаю, это написал Claude», подчёркивает растущую проблему: когнитивную капитуляцию.

Что такое когнитивная капитуляция?

В статье различаются два термина:

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

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

Как это происходит

В статье описывается типичный сценарий:

1. У вас есть задача, которая не маленькая, поэтому вы начинаете сессию планирования с Claude, используя знаменитый навык мозгового штурма superpowers.
2. Вы внимательно читаете план, исправляете пару проблем и отправляете его на выполнение.
3. Вы проверяете код, он выглядит хорошо, исправляете мелкие проблемы парой промптов и отправляете на ревью.
4. Дальше идёт более крупная задача. Она неоднозначная. В до-ИИ мире вы бы разбили её на более мелкие части, но вы торопитесь.
5. Claude создаёт план, который звучит разумно, поэтому вы сразу переходите к выполнению. Результат работает. Вы просматриваете код, открываете PR и идёте дальше.
6. Вы только что пропустили часть, где нужно было реально понять, что происходит.

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

Почему трудно сопротивляться

Автор делится личным опытом: проводя 2-3 часа в сессии планирования с Claude над амбициозной задачей. На середине выполнения они почувствовали, что потерялись — слишком много движущихся частей и решений, принятых Claude. В итоге они набрали /clear и сбросили всё. Было две проблемы:

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

Когда ваш план расплывчат и вы недостаточно знаете, чтобы принимать решения самостоятельно, вы в конечном итоге делегируете решения Claude. Как написал Эдди Османи, директор по инженерии в Google, грань между использованием Claude и тем, чтобы позволить ему управлять, очень размыта, и требуется много усилий, чтобы сопротивляться искушению.

Один из подходов: просматривайте каждую строку

В статье предлагается альтернативный подход. Для меньшей задачи — добавление отслеживания событий через Segment в инфраструктуру внутренних ИИ-агентов — автор планировал с Claude, затем просматривал каждое изменение в IDE перед коммитом. Для файлов, которые они не понимали, они просили Claude объяснить. Когда ответ не имел смысла, они меняли код и просматривали его снова. К тому времени, как они поняли каждое изменение в файлах, они поняли всё решение.

Автор открыл PR и получил отличные комментарии от старших инженеров — и мог на них ответить, а не прятаться, как рыба за камнем.

Главный вывод

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