Понимание кода, новое узкое место в эпоху ИИ-агентов

Материал, переработанный в текст доклад, который автор читает на конференции AI Engineer в июле 2026 года и параллельно публикует как тред в Twitter. Автор работает в Notion и сам оговаривает: возможна предвзятость в пользу продуктов компании. Центральный тезис: ИИ-агенты пишут всё больше кода за людей, но понимать этот код по-прежнему важно, изменилась только причина. Раньше понимание было нужно, чтобы проверить работу агента: соответствует ли она техническому заданию, хорошо ли спроектирована, по сути бинарный вопрос «годится / не годится». Но агенты сами всё лучше проверяют собственный код, и эта функция человека отмирает. Настоящая причина понимать, по мнению автора, другая, не проверка, а участие: проект, это не одна правка, а множество циклов подряд с агентом, и предложить, куда двинуть систему на следующем шаге, может только тот, кто её понимает; без этой беглости способность полноценно участвовать в проекте заметно сужается. Автор сравнивает непонимание кода, написанного агентом, с техническим долгом, только это «когнитивный долг», термин, который автор связывает с именами Маргарет Стори и Саймона Уиллисона: экономить на понимании можно какое-то время, но расплата придёт.

Первая техника, объяснения изменений. Автор создаёт навык (skill) /explain-diff, который использует каждый день и который, по словам автора, пригождается и коллегам. Вместо привычного диффа, списка изменённых файлов по алфавиту без единого пояснения, навык собирает то, что автор называет «литературным диффом»: связный текст, который сначала подводит контекст (что уже было в системе до изменения, например, как устроен игровой движок), затем формулирует цель на человеческом языке (например: «сделать сад визуально трёхмерным приёмами 2D-отрисовки») и поясняет нужные понятия (что такое изометрическая проекция), и только потом показывает сам код, по разумному порядку смысловых кусков, а не файл за файлом. К объяснению прилагаются интерактивные иллюстрации, незадолго до этого Notion добавляет возможность встраивать интерактивный HTML прямо в страницы, например, можно двигать мышью камни в саду и смотреть, как меняются их координаты. Готовый документ выводится как HTML или как страница Notion, это два варианта на выходе. Но чтение, само по себе тяжёлая работа, и легко обмануть себя: кажется, что текст прочитан и понят, а на деле ничего не удержалось в памяти; автор напоминает слова Энди Матушака: «книги не работают». Поэтому в конце каждого объяснения, интерактивный квиз из пяти вопросов по сути изменения; саму идею вставлять квизы в текст автор перенимает у Матушака и Майкла Нильсена, которые встраивали такие квизы в свои эссе по методу интервальных повторений. Личное правило автора: код коллегам не отправляется, пока сам автор не пройдёт этот квиз, и то же правило применяется при ревью чужого кода. По формулировке автора, квиз работает как «регулятор скорости»: при работе с ИИ агентский цикл легко обгоняет скорость человеческого понимания, а вопрос «правда ли я понимаю?», механическая проверка, которая держит человека полноценным участником процесса.

Вторая техника, «микромиры»: термин автор берёт у педагога-провидца Сеймура Пейперта. Пейперт называл эту идею «жизнью в стране математики» (в оригинале, Mathland): хочешь выучить математику, живи в «стране математики», как для французского языка едут жить во Францию. Автор переносит идею на код: можно ли построить среду, в которой человек естественно, через любопытство, понимает, как система устроена и как она меняется? Первый пример: за год до доклада автор пишет собственный интерпретатор Prolog и с трудом понимает, что происходит внутри, вместе с ИИ-агентом автор строит отладчик, который позволяет пошагово проигрывать выполнение программы, перематывать время вперёд и назад, смотреть стек и то, какие правила применяются на каждом шаге, и даже оставлять себе комментарии по ходу («вот тут мы верно применили правило»). Второй пример: при переносе личного сайта на новый фреймворк скрипт миграции пишет Claude, но проверить его почти невозможно: новый фреймворк незнаком, и единственное, что можно сказать: «наверное, выглядит примерно правильно». Тогда по просьбе автора Claude собирает что-то вроде видеоигры, «командный центр», в котором перенос выполняется шаг за шагом по нажатию кнопки, старый и новый сайт показаны рядом, а дерево файлов меняется на глазах. В итоге у автора складывается такое же понимание переноса, как если бы перенос делался вручную, но гораздо быстрее, потому что весь процесс разложен по шагам. Вывод автора: агенты умеют писать код, который помогает людям понимать другой код, и это «большое дело».

Третья техника, общие пространства для команды: понимание нужно не только в одиночку, но и сообща, чтобы у команды была общая ментальная модель системы и общий словарь для творческого обсуждения. Здесь автор снова упоминает своего работодателя: Notion, где работает автор, в последнее время добавляет инструменты для совместной работы людей и агентов, например, теперь в Notion можно запускать агентов Claude и Cursor, а составленный ими технический план по умолчанию попадает на совместную страницу, которую сразу может комментировать вся команда. Завершается доклад отсылкой к Алану Кэю: 50 лет назад он представлял компьютер как новую, лучшую, чем книга, среду для того, чтобы учить людей, особенно детей, думать о мире. Вывод автора: смысл всех этих инструментов всегда был не в том, чтобы просто автоматизировать работу, а в том, чтобы усиливать человеческое понимание. При правильных инструментах, по формулировке доклада, человек не обязан выходить из цикла с ИИ, можно, наоборот, погружаться в него глубже.

Ключевые факты

• Автор доклада, сотрудник Notion, возражает против позиции «агенты сами всё проверят»: раз агенты всё лучше верифицируют собственный код, единственная причина по-прежнему разбираться в нём, оставаться творческим участником проекта, а не разовым контролёром.
• Техника 1, навык /explain-diff: превращает дифф в связный «литературный дифф» с контекстом, целью на человеческом языке и интерактивными иллюстрациями, а в конце, квиз из пяти вопросов; личное правило автора, код не уходит дальше, пока сам автор не пройдёт квиз.
• Техника 2, «микромиры»: интерактивные тренажёры вместо чтения диффа, отладчик для собственного интерпретатора Prolog с перемоткой выполнения и отдельно «видеоигра»-командный центр от Claude для пошагового переноса личного сайта на новый фреймворк, который иначе было не проверить.
• Техника 3, общие пространства: в Notion теперь можно запускать агентов Claude и Cursor, а их технический план по умолчанию ложится на совместную страницу, которую сразу комментирует вся команда.
• Мысль связывается с 50-летней историей: Алан Кэй видел в компьютере среду для обучения мышлению, а не просто инструмент автоматизации, по формулировке доклада, цель всегда была усиливать человека, а не заменять.

Почему это важно

Тезис идёт наперекор расхожему «агенты станут настолько хороши, что человеку скоро не нужно будет вникать». Агенты действительно всё лучше умеют сами проверять свою работу, так что классическая роль человека-контролёра («годится» / «не годится») теряет смысл. Но у понимания, по мнению автора, есть вторая, более фундаментальная функция: без него не получится придумать, куда двигать проект дальше. Работа с агентом, это не разовая правка, а цепочка из множества циклов, и каждый следующий шаг рождается из того, насколько хорошо человек держит систему в голове. Автор называет это «когнитивным долгом» (по аналогии с техническим долгом; популяризацию термина автор связывает с именами Маргарет Стори и Саймона Уиллисона), экономия на понимании работает в моменте, но копится и рано или поздно останавливает прогресс.

Кому это важно

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

Как это применить

Автор описывает не одну практику, а три, которые можно внедрять по отдельности. Первая, просить агента (или отдельный навык вроде /explain-diff) не просто выдавать дифф, а собирать связное объяснение: сначала контекст и цель, потом код по смысловым кускам, в конце, короткий квиз на понимание, который нужно пройти самому, прежде чем отправлять код дальше. Вторая, вместо чтения кода просить агента построить интерактивный тренажёр для конкретной задачи: отладчик с перемоткой выполнения, пошаговый интерфейс для миграции, то, что превращает пассивное чтение в активное действие. Третья, выносить работу агента в общее, комментируемое пространство команды (в примере доклада, страницы Notion), а не в приватный чат один на один с агентом, чтобы понимание строилось сразу у всей команды, а не только у того, кто запустил агента.

Можно ли доверять

Материал, личное эссе по мотивам доклада на конференции, а не исследование с измеренным результатом: ни для объяснений, ни для квизов, ни для микромиров в тексте нет цифр, ни сэкономленного времени, ни числа пойманных ошибок, ни замера понимания до и после, только личные примеры из практики автора. Сам автор прямо оговаривает предвзятость: работа в Notion, а обе иллюстрации разных техник по сути демонстрируют функции продукта этого же работодателя (интерактивный HTML в страницах, агенты Claude и Cursor внутри Notion). Опорные идеи при этом восходят к узнаваемым и давно проверенным именам в теме обучения и инструментов мышления, Пейперт, Кэй, Матушак, Нильсен, но это подтверждает достоверность самих первоисточников, а не эмпирику доклада.

Риски и подводные камни

Главный риск, принять личную практику одного разработчика за проверенный метод: без данных неясно, окупают ли квизы и интерактивные объяснения потраченное на них время, особенно в командах с другим масштабом кода и скоростью изменений. Второй риск, конфликт интересов: доклад параллельно рекламирует конкретные функции Notion, и грань между «универсальной техникой понимания» и «примером использования продукта работодателя» в тексте не всегда разделена. Третий риск, сама идея квиза как «регулятора скорости» подразумевает, что человек намеренно тормозит агента ради понимания; в командах, где важнее скорость поставки, а не глубина понимания каждого участника, это может восприниматься как лишний шаг, а не как страховка.

«Книги не работают»

— Энди Матушак