Я не хочу возвращаться к ручному кодингу. Но чем больше кода генерируют агенты, тем яснее: главная проблема AI-first разработки — не в качестве кода и даже не в сложности его отладки.
Проблема не в дебаге
Проблемы начинаются тогда, когда заканчивается вайб-кодинг и начинается вайб-дебаггинг
Так звучит один из популярных тезисов: AI быстро пишет код, а разработчик потом тратит время на разбор странностей, побочные эффекты и исправление ошибок.
Я понимаю это беспокойство, но не считаю его главной проблемой. В хорошо организованных процессах разработчику не нужно глубоко погружаться в сгенерированный код — как раньше приходилось разбирать чужой legacy без документации.
С чужим legacy ты сталкиваешься с конечным артефактом, лишённым контекста: никто не объяснит, почему выбрано именно такое решение, какие были компромиссы, где слабые места.
С агентом — иначе. У тебя всегда есть собеседник:
- что ты изменил?
- почему сделал именно так?
- какие инварианты затронул?
- что могло пойти не так?
- где наиболее вероятен источник ошибки?
А если поверх этого настроена строгая архитектура — с чёткими слоями, модульными границами, контрактами и acceptance criteria — то ситуация перестаёт напоминать дебаг спагетти-кода. Ты работаешь не с бесформенным output, а с локализованным изменением, для которого можно получить осмысленный explanation, summary и проверяемый diff.
Поэтому трудности с vibe debugging — скорее переходная стадия. Если агент умеет писать код, он рано или поздно научится объяснять его, находить ошибки и закрывать большую часть debugging loop самостоятельно.
Когда это произойдёт, вопрос «насколько тяжело человеку чинить AI-код» перестанет быть главным. Реальная проблема лежит глубже.
Как была устроена работа раньше?
В программировании всегда существовал естественный ритм. Сначала — напряжённая фаза: проектирование, выбор подхода, удержание системы в голове. Это была самая сложная часть.
Затем наступала другая фаза — спокойнее, тише. Основные решения уже приняты. Остаётся «просто писать код».
Но это никогда не было механической рутиной. Это был особый режим присутствия в задаче.
Режим, в котором ты не переставал быть инженером, но выходил из состояния когнитивного напряжения. Ты двигался шаг за шагом: функция за функцией, компонент за компонентом, экран за экраном.
Мысль приобретала форму. Нагрузка становилась последовательной и переносимой.
Именно в этой фазе многие из нас восстанавливались — не вне работы, а внутри неё. Профессия держалась не только на сложности, но и на чередовании напряжения и передышки.
Что меняет AI?
Когда код пишет агент, кажется, что у разработчика отнимают только рутину. Но вместе с ней исчезает и когнитивный буфер — тот слой, который раньше распределял нагрузку по-человечески.
Остаётся в основном верхний регистр:
- формулировать intent,
- дробить проблему,
- принимать архитектурные решения,
- проверять результат,
- сомневаться,
- уточнять,
- снова проверять,
- снова решать.
На бумаге это выглядит как повышение уровня абстракции. Как будто разработчика освобождают для более важной работы.
Но человек — не машина для непрерывного high-level reasoning. Ты больше не строишь систему шаг за шагом. Ты всё время координируешь стройку сверху.
И вот здесь становится ясно: главная проблема — не debugging burden как таковой.
Даже если агент будет сам чинить больше своих ошибок, у человека останется другая, более фундаментальная проблема — работа становится когнитивно однородной. Из неё исчезает смена плотности.
Раньше у разработчика были волны нагрузки. Сейчас — почти сплошной supervisory mode. И это особенно заметно в том, как сегодня говорят о продуктивности.
“Я за день собрал пять стартапов”, “У меня одновременно работает десять агентов”, “Пока я сплю, система продолжает делать продукт”.
Нам продают образ человека, который будто масштабировал себя без усилий — просто подключил цифровую армию и получает бесконечный output.
Но за кадром — цена этой продуктивности. Не только финансовая или в терминах качества. А цена формы внимания и погруженности, которую такая модель требует от человека.
Если у тебя всё время что-то крутится, очень трудно по-настоящему выйти из процесса. Простой начинает ощущаться как потеря.
Мы платим за инструмент — значит, он не должен стоять. Если агент ждёт — нужно дать следующий шаг. Если завершилась итерация — надо проверить результат сразу.
Так незаметно возникает новая норма: быть с системой на связи всегда — с компьютера, с планшета, с телефона.
На поверхности это свобода и расширение масштабов. На деле — постоянная когнитивная сцепка с процессом:
- проверить,
- ответить,
- скорректировать,
- перезапустить,
- не потерять темп,
- не дать агенту простаивать.
Мы будто покупаем автоматизацию, а на деле — новую форму постоянной доступности.
Именно это и есть скрытая цена AI-продуктивности. Чем больше агентов «работают на тебя», тем выше риск, что ты сам начинаешь работать на их непрерывность.
Это не из-за плохой системы. Её логика постепенно размывает границу между рабочим циклом и постоянной подсознательной готовностью вмешаться.
Именно поэтому разговоры о проблемах AI в разработке идут не туда. Мы слишком спорим о качестве AI-кода и слишком мало задумываемся о том, какой режим работы он создаёт для человека.
Мы боимся, что AI отнимет навыки. Но, возможно, сначала он отнимет «выносимость» профессии.
Не способность написать функцию. Не умение собрать сервис. А возможность проживать инженерную работу в человеческом темпе.
Если так продолжится, мы получим странную форму прогресса: машины будут писать всё быстрее, а люди — выгорать всё раньше. Мы автоматизируем не только реализацию. Мы автоматизируем последние островки передышки внутри самой работы. Работа становится быстрее, но перестаёт давать дышать.
Что с этим делать?
Я не хочу возвращаться к ручному кодингу. Это шаг назад.
Но если AI забирает механическую фазу работы, её нужно чем-то заменить. Отдых нельзя оставлять на волю случая. Его придётся проектировать так же, как архитектуру.
Для меня важны три вещи:
- Energy-aware workflow: День с агентом не должен быть бесконечным диалогом. Это должны быть отдельные циклы — дизайна, обсуждения, постановки задачи, лёгкого надзора и настоящей паузы.
- Summary-first review: Человек не должен нырять в сырой код по умолчанию. Агент должен сначала объяснять, что изменил, что затронул, что сломал, в чём не уверен, что предлагает дальше.
- Строгая архитектурная рамка: Чем чётче границы модулей, слоёв и контрактов, тем меньше AI-разработка похожа на хаотичный дебаг монолита и тем больше — на управляемую работу с локализованными изменениями.
Зрелая AI-first разработка — это не мир, где человек бесконечно разбирает агентный output. И не мир, где он весь день только думает, проверяет и управляет.
Это мир, где агент берёт на себя генерацию, объяснения и self-debugging, а человек сохраняет не тотальный контроль, а здоровую форму участия.
Следующий этап зрелости AI в разработке — не просто лучшие агенты. Это лучшие процессы вокруг них.
Если код становится автоматическим, то отдых должен стать систематическим. Иначе мы не освобождаем разработчика. Мы просто выжигаем из профессии ту часть, которая делала её человечной.