Я не хочу возвращаться к ручному кодингу.

Но чем больше кода пишут агенты, тем яснее: главная проблема AI-first разработки - и это не качество AI-кода.

Проблема в том, что из профессии исчезает фаза, в которой мы восстанавливались.

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

Я понимаю этот тезис, но не согласен с тем, что это и есть главная проблема AI first разработки. Более того, я вообще не уверен, что в хорошо настроенных процессах работы с агентами разработчик должен глубоко лезть в код агента так же, как раньше лез в чужой legacy-код без документации. Это кардинально разные ситуации.

Когда ты получаешь доступ в чужой «legacy» код, часто автор кода недоступен. Некого спросить, почему решение было именно таким, какие были альтернативы, где слабые места, что было допущением, а что — сознательным trade-off. Ты имеешь дело с конечным артефактом, и при этом теряешь весь контекст, который привел к этому результату.

В случае с агентом это уже не так. У тебя всегда есть тот, кого можно спросить:

• что ты изменил?

• почему сделал именно так?

• какие инварианты затронул?

• что могло пойти не так?

• где наиболее вероятный источник ошибки?

А если поверх этого накладывается еще и строгая архитектура - понятные слои, модульные границы, ограниченная зона изменений, контракты и acceptance criteria, то ситуация вообще перестает иметь что-то общее с дебагом чужого спагетти-кода. Ты работаешь не с бесформенной массой generated output, а с локализованным изменением, про которое можно получить вменяемый explanation, summary и проверяемый diff.

Поэтому я смотрю на проблемы с vibe debugging скорее как на переходную стадию, а не как на фундаментальную проблему работы с AI. Если агент умеет писать код, он рано или поздно научится и объяснять его, локализовать собственные ошибки, и закрывать всё большую часть debugging loop сам.

И когда это произойдёт, окажется, что вопрос “насколько тяжело человеку чинить AI-код” был не главным. Реальная проблема лежит глубже.

Как была устроена работа раньше?

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

И вот именно это - “просто писать код” никогда не было пустой механикой.

Это был особый режим присутствия в задаче.

Режим, в котором ты не переставал быть инженером, но переставал жить в состоянии когнитивного напряжения.

Ты двигался шаг за шагом.

Функция за функцией.

Компонент за компонентом.

Экран за экраном.

Мысль приобретала форму, а нагрузка становилась последовательной и переносимой.

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

Что меняет AI?

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

• формулировать intent,

• дробить проблему,

• принимать архитектурные решения,

• проверять результат,

• сомневаться,

• уточнять,

• снова проверять,

• снова решать.

На бумаге это выглядит как повышение уровня абстракции. Как будто разработчика освобождают для более важной работы.

Но человек — не машина для непрерывного high-level reasoning. Ты больше не строишь систему шаг за шагом. Ты всё время координируешь стройку сверху.

И вот здесь становится видно, что главная проблема — это не debugging burden как таковой.

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

Раньше у разработчика были волны нагрузки. Сейчас всё чаще остаётся почти сплошной supervisory mode. И это особенно хорошо видно в том, как сегодня говорят о продуктивности.

Вокруг AI полно восторженной риторики:

“я за день собрал пять стартапов”,

“у меня одновременно работает десять агентов”,

“пока я сплю, система продолжает делать продукт”.

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

Но за кадром остаётся цена этой продуктивности.

И это не только финансовый вопрос.

Не только цена качества.

А цена формы внимания и погруженности, которую такая модель начинает требовать от человека.

Ведь если у тебя всё время что-то крутится, очень трудно по-настоящему выйти из процесса.

Простой начинает ощущаться как потеря.

Мы же платим за инструмент — значит, он не должен стоять.

Если агент ждёт — значит, ему нужно дать следующий шаг.

Если где-то завершилась итерация — надо посмотреть результат сейчас, а не потом.

И вот так незаметно возникает новая норма: быть с системой на связи всегда.

С компьютера.

С планшета.

С телефона.

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

• проверить,

• ответить,

• скорректировать,

• перезапустить,

• не потерять темп,

• не дать агенту простаивать.

То есть мы вроде бы покупаем автоматизацию, а на деле покупаем себе новую форму постоянной доступности.

Именно это, и есть скрытая цена AI-продуктивности.

Чем больше агентов “работают на тебя”, тем выше риск, что ты сам начинаешь работать на их непрерывность.

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

Именно поэтому я считаю, что разговоры про проблемы с AI в разработке идёт немного не туда.

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

Мы боимся, что AI отнимет навыки. Но, возможно, раньше он отнимет "выносимость" профессии.

Не способность написать функцию.

Не умение собрать сервис.

А возможность проживать инженерную работу в человеческом темпе.

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

Что с этим делать?

Я не хочу возвращаться к ручному кодингу.

Но если AI забирает механическую фазу работы, её нужно чем-то заменить.

Это шаг назад, и я его не хочу.

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

Для меня здесь важны три вещи:

• Energy-aware workflow: День с агентом не должен быть бесконечным диалогом. Это должны быть отдельные циклы дизайна, обсуждения, постановки задачи, лёгкого надзора и настоящей паузы.

• Summary-first review: Человек не должен нырять в сырой код по умолчанию. Агент должен сначала объяснять, что изменил, что затронул, что сломал, в чем не уверен, что предлагает дальше.

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

Зрелая AI-first разработка - это не мир, где человек бесконечно разбирает агентный output вручную, но и не мир, где он весь день только думает, проверяет и управляет. Это мир, где агент берёт на себя всё больше генерации, объяснения и self-debugging, а человек сохраняет не тотальный контроль над каждой строкой, а здоровую форму участия в процессе.

Следующий этап зрелости AI в разработке - это не просто лучшие агенты.

Это лучшие процессы вокруг них.

Если код становится автоматическим, то отдых должен стать систематическим.

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