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

Я хочу рассказать о том, как я использую потерю понимания как сигнал обратной связи. Так я решаю, когда можно делегировать ИИ больше, а когда нужно замедлиться и разобраться.

Два подхода к работе с ИИ

Рассмотрим два противоположных подхода к написанию кода с ИИ:

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

• Vibe coding — разработчик формулирует желаемый результат, а ИИ реализует его самостоятельно. Код оценивается по тому, работает ли он, без попытки разобраться в его устройстве.

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

Но на практике между этими двумя крайностями есть множество подходов. Мы можем условно изобразить этот спектр следующим образом:

Это лишь приблизительная модель. Соотношение автономности, экономии времени и понимания зависит от проекта, возможностей ИИ-моделей и опыта разработчика. Кроме того, здесь не учтены другие факторы, например качество и стоимость результата.

При движении от парного программирования с ИИ к vibe coding мы тратим меньше времени, но вместе с тем теряем понимание проекта. Нам хочется найти здесь оптимальный баланс, чтобы быть наиболее эффективными в долгосрочной перспективе. Чтобы найти этот баланс, сначала нужно понять, зачем вообще нужно разбираться в проекте.

Необходимый уровень понимания

Я считаю, что людям необходимо понимать код — по крайней мере на сегодняшний день.

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

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

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

Граница понимания

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

Даже внутри одного проекта граница проходит по-разному. Как модели могут использовать разные уровни reasoning для разных задач, так и мне нужна разная глубина понимания разных участков кода.

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

Когда я начинаю терять понимание, я замедляюсь, разбираюсь в конкретном участке и только потом двигаюсь дальше. Так складывается Understanding Loop: я делегирую ИИ работу, пока не замечаю, что моя ментальная модель стала разваливаться, затем восстанавливаю контекст и продолжаю. Этот цикл позволяет оставаться в зоне, где ИИ экономит время, а необходимый контроль сохраняется.

Программирование на грани

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

• Я понимаю поток данных в системе.

• Я могу предсказать, где нужно внести следующую правку.

• Я понимаю последствия изменения для других частей проекта.

• Я не теряюсь при навигации по проекту.

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

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

Я считаю понимание восстановленным, когда снова могу своими словами объяснить, как работает этот участок, и предсказать, на какие части проекта повлияет изменение. После этого можно снова ускориться и делегировать ИИ больше.

Обучение

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

При работе на границе агент может привести меня в незнакомую область, а understanding loop помогает встроить новое знание в общую картину проекта. Этот процесс напоминает тренировки до отказа: по мере роста возможностей нагрузку постепенно увеличивают, каждый раз немного отодвигая предел возможностей.

Со временем моя ментальная модель становится точнее, и я могу осознанно делегировать агенту больше работы, сохраняя тот же уровень контроля. Граница постепенно сдвигается вправо, а затраты времени снижаются.

Заключение

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

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