Почему разработка с ИИ-агентами стала тяжелее, а не легче
Генерация кода перестала быть узким местом. Агенты выдают реализацию за минуты и почти бесплатно, но продуктовые и архитектурные решения за разработчика не принимают. Основное время уходит именно на них, а проверка результата оказывается сложнее и дороже самого написания кода.
Так описывает свой опыт автор материала «Я больше не пишу код руками. Работать стало тяжелее»: проект «на выходные» занял два месяца, и на код из них не ушло почти ничего. Это наблюдения одного разработчика на одном проекте, а не исследование рынка, поэтому читать их стоит как рабочие заметки, а не как статистику.
Сместилась структура работы. Вместо набора кода основной режим - переключение между несколькими агентами, удержание их контекстов и принятие решений. Ввод текста стал бесплатным, зато голова занята пятью задачами сразу.
Код перестал быть узким местом
Автор перестал писать код руками и не читает сгенерированный: если код делает то, что должен, устройство внутри его не интересует. Реализация для него расходник, который можно выбросить и заменить.
Позицию легко принять за лень, и это ошибка. Расходником код становится только при наличии проверок и спецификаций. Без них «мне всё равно, как написано» превращается в систему, которую нечем развивать: непонятно, что именно нельзя ломать, какие обещания она даёт пользователю и почему решение принято так, а не иначе.
Ускорение генерации не сокращает проект целиком, потому что узкое место переехало. Пока код стоил дорого, время уходило на него. Когда код подешевел, время стало уходить на решения вокруг него: кому и что система обещает, как она ведёт себя при сбое, сколько стоит пользователь и при какой цене подписки сходится экономика.
Что заняло два месяца вместо выходных
Пример автора: приложение, где человек каждый день получает короткую практику осознанности, собранную под него. Контент пишет модель, озвучивает синтез речи, доступ открывается по подписке. Задумано как проект «на выходные», заняло два месяца.
Агент не ответил ни на один вопрос, который определял продукт:
- сколько уровней контроля поставить над генерацией;
- что делать, когда модель всё-таки выдала брак;
- сколько это стоит на пользователя в месяц и при какой цене подписки сходится;
- что происходит с уже оплаченной подпиской, если генерация в этот день не удалась;
- как звучит голос, какой длины практика, в какое время суток её открывают.
Ни один из этих вопросов не про код. Агент молчит не из-за неспособности, а потому что отвечать на них приходится самому автору. И только после ответов имеет смысл что-то генерировать: иначе агент быстро и аккуратно соберёт не тот продукт.
Проект автора в итоге никуда не полетел по скучной причине: он не стал заниматься продвижением. Как замер эти два месяца получились unusually чистыми: видно, что именно ускорилось, а что осталось прежним.
Что подешевело, а что осталось дорогим
Экономика разработки с агентами распадается на две части. Производство реализации подешевело на порядок. Знание о том, что система обязана сохранять при замене компонентов, не подешевело вообще.
Производство реализации: почему код стал расходником
Генерация кода превратилась в быструю и дешёвую операцию. Оценки ускорения по циклу разработки с AI-агентами, которые разбирались в материале «AI в цикле разработки: где агенты реально ускоряют работу, а где создают иллюзию продуктивности», выглядят так: типовые задачи вроде CRUD, интеграций, миграций и тестов ускоряются примерно в 2,5-4 раза, а новая бизнес-логика и архитектура - лишь в 1,3-1,8 раза, иногда с замедлением вместо выигрыша.
Отсюда и отношение к коду как к расходнику. Если реализацию можно перегенерировать за минуты, держаться за конкретные строки смысла нет. Ограничение у подхода одно, но серьёзное: расходником код становится только тогда, когда известно, что он обязан сохранять.
Знание о том, что система обязана сохранять
Дорого не написать код, а знать, что система обязана сохранять при замене компонентов. Замена платёжного провайдера, смена модели генерации, обновление внешнего API: каждое такое изменение не должно ломать то, что система обещала пользователю.
Это знание не генерируется вместе с кодом. Агент не подскажет, что при смене биллинга нельзя потерять историю оплат, что после замены модели текст практики обязан сохранить длину и тон, что обновление API не должно рвать путь пользователя на середине. Пока требования не записаны, замена компонента превращается в лотерею: формально всё работает, а обещание пользователю уже нарушено.
Фиксируется такое знание в спецификациях, а проверяется через evaluations и тесты. Спецификации и есть тот артефакт, который переживает любую замену библиотеки, модели или поставщика услуг.
Ограничения вайб-кодинга: почему быстрая сборка имеет срок годности
Вайб-кодинг позволяет быстро собрать работающий SaaS: готовый биллинг, готовая авторизация, несколько чужих API, склеенные за вечер. У такой сборки есть срок годности.
Когда вайб-кодинг работает
Быстрая сборка оправдана там, где система не будет жить долго. Прототип для проверки гипотезы, внутренний инструмент на пару месяцев, одноразовый скрипт под конкретную задачу: если решение выбрасывается после проверки идеи, отсутствие границ почти не мешает.
Второй сценарий, где подход держится: система состоит из стандартных блоков и не обрастает собственной логикой. Готовый биллинг, готовая авторизация и чужие API закрывают потребность целиком, пока требования совпадают с тем, что эти сервисы умеют.
Когда он перестаёт работать
Признаки того, что проект вышел за рамки быстрой сборки:
- компонент нужно менять, не ломая путь пользователя;
- появляются требования к поведению при сбое;
- нужно объяснить, почему решение принято именно так;
- к работе подключается второй разработчик или второй агент, которому нужен контекст.
Главная проблема такой сборки не в зависимости от чужих сервисов, от неё всё равно никуда не уйти. Хуже другое: в системе нет границ, нет проверок и нигде не записано, почему что сделано именно так. Развивать её нечем.
Автор описывает этот сценарий прямо: через месяц понадобилось поменять логику оплаты, а в проекте ни границ, ни тестов, ни объяснений. Агент в такой ситуации не спасает: он не знает, что было важно для пользователя, и уверенно перепишет то, что ломать нельзя.
Spec-driven development: спецификации и evaluations вместо надежды на агента
Подход обратный вайб-кодингу: сначала фиксируются обещания системы и её границы, затем генерируется код, затем проверяется соответствие результата обещаниям. Между этапами стоят спецификации и evaluations.
Похожий процесс разбирался в материале «Harness для ИИ-разработки: как два агента заменили команду и почему SDD стал новым стандартом», где описаны спек-контракты, чистый контекст ревью и гейты качества.
Что фиксировать в спецификации
- для кого продукт;
- что он обещает;
- что делать, когда обещание не выполнено;
- какие границы у системы;
- что нельзя ломать при замене компонентов;
- сколько уровней контроля над генерацией;
- как система ведёт себя при браке модели.
Это те же вопросы, на которые агент за разработчика не отвечает. Спецификация - место, где ответы записаны и доступны агенту, а не хранятся в голове автора до следующей сессии.
Evaluations и тесты: почему проверка дороже написания кода
Автор формулирует прямо: написать тест оказалось сложнее, чем написать код, который он проверяет. А зелёные тесты говорят только о том, что вы догадались проверить.
Evaluations проверяют поведение системы в сценариях, важных для пользователя. Тест на генерацию текста не поймает, что голос не тот или практика слишком длинная: это проверяется отдельно, на другом уровне. Пока сценарий не описан, он остаётся непроверенным, даже когда весь набор тестов зелёный.
CLAUDE.md и память агента: как удерживать контекст
Контекст между сессиями помогает удерживать файловая память. В Claude Code память живёт в файлах CLAUDE.md и обеспечивает постоянный контекст, который переносится между сессиями и разговорами (Memory Guide: как устроена память в Claude Code).
Система памяти работает на нескольких уровнях: от глобальных личных предпочтений до конкретных подкаталогов, что даёт тонкий контроль над тем, что агент помнит и как применяет эти знания. Файлы памяти можно версионировать как часть проекта, делиться стандартами проекта с командой и хранить личные предпочтения разработки.
Когнитивная нагрузка: почему голова занята пятью задачами сразу
Ввод текста теперь бесплатный, зато голова занята пятью задачами сразу. Это не жалоба, а описание механики: стоимость сместилась с набора символов на удержание контекста.
Переключение между агентами как основной режим работы
Один агент пишет код, второй проверяет, третий генерирует тесты, четвёртый - документацию. Человек переключается между ними, держит в голове чужие контексты и принимает решения по каждому результату. Код при этом почти не набирается руками.
Этот режим разбирался в статье «LLM-агенты: ускорение разработки или когнитивная ловушка»: скорость набора строк становится фиктивным KPI, а лавина сгенерированного кода разрушает понимание кодовой базы. Чем больше агентов запущено параллельно, тем выше цена переключения между ними.
Почему иллюзия освободившихся вечеров не сбывается
Агенты ускоряют производство реализации, но не ускоряют принятие решений. Решения занимают основное время. Проверка результата при этом стала сложнее и дороже самого написания кода, а её нельзя делегировать тому же агенту, который код написал.
Иллюзию, что агенты освободят вечера, автор советует отбросить сразу. Освобождается не время, а меняется его структура: меньше набора, больше разбора, выбора и фиксации договорённостей. Вечера уходят на то же самое, просто в другой пропорции.
Типичные промахи генерации: интерфейс и путь пользователя
Агент делает работающий интерфейс, но не обязательно тот, который нужен пользователю. Разница в том, что часть решений не про код.
Интерфейс: что агент делает не так
Типовые промахи выглядят безобидно и стоят дорого:
- кнопка есть, но стоит не там, где пользователь её ищет;
- состояние загрузки не предусмотрено, экран просто молчит несколько секунд;
- ошибка показана техническим текстом без объяснения, что делать дальше;
- после неудачной операции пользователь остаётся на экране без понятного следующего шага.
Это не баги кода, а пропущенные продуктовые решения. Агент собрал экран, который технически корректен, и не задал вопрос, зачем пользователь сюда пришёл.
Путь пользователя: почему его нужно проектировать до генерации
Путь пользователя - последовательность обещаний, которые система даёт и выполняет. Агент не знает, какие обещания важны, пока их не записали.
Пример из проекта автора: что происходит с уже оплаченной подпиской, если генерация в этот день не удалась. Ответ определяет текст в интерфейсе, логику повторной попытки и обращение в поддержку. Пока решения нет, агент придумает своё, и оно вряд ли совпадёт с вашим. То же касается длины практики и времени суток, когда её открывают: это продуктовые решения, а не настройки по умолчанию.
Продуктовый инженер: за что отвечает разработчик, когда код пишут агенты
Роль меняется одним сдвигом: разработчик отвечает за обещания системы, а не за сегодняшний способ их выполнения.
Обещания системы важнее способа их выполнения
Если система обещает пользователю результат, за обещание отвечает человек, а не конкретный API, модель или библиотека. Замена компонента не должна ломать обещание, поэтому критерий приёмки формулируется на уровне поведения, а не реализации.
Здесь же проходит граница с теми, кто не хочет отдавать код агентам. В материале «Почему часть разработчиков не хочет отдавать код ИИ-агентам» разбирается, что сопротивление связано с авторством и инженерной ответственностью. Ответственность за обещания никуда не девается, она переезжает с уровня строк на уровень поведения системы.
Автор формулирует это как роль продуктового инженера и честно оговаривает, что замер сделан на одном проекте, а не на потоке задач.
Граница окупаемости заменяемости: честное признание
Граница окупаемости заменяемости пока определяется на глаз. Нет формулы, которая скажет, когда замена компонента окупится, а когда проще оставить как есть.
Решение принимается по контексту: сколько пользователей затронуто, насколько жёстко компонент связан с путём пользователя, сколько времени уйдёт на проверку обещаний после замены. Менять биллинг ради архитектурной красоты при десяти платящих пользователях бессмысленно. Держать привязку к одному поставщику при жёстких требованиях к доступности - рискованно.
Что делать на практике: с чего начать разработку с ИИ-агентами
Порядок обратный привычному: сначала спецификация, потом код, потом проверка соответствия. Код в этой схеме занимает меньше всего времени.
Спецификация до кода: минимальный набор
- для кого продукт;
- что он обещает;
- что делать при сбое;
- какие границы у системы;
- что нельзя ломать при замене компонентов.
Этого достаточно, чтобы агент не ушёл в сторону. Готовый шаблон не нужен, важнее, чтобы ответы были записаны и доступны агенту между сессиями, а не восстанавливались по памяти каждый раз.
Evaluations и тесты: как не утонуть в проверках
Проверка дороже написания кода, поэтому её имеет смысл планировать. Начать с evaluations на ключевые обещания системы, а не на всё подряд: сначала сценарии, где ошибка ломает обещание пользователю, потом остальное.
Помнить, что зелёные тесты говорят только о том, что вы догадались проверить. Пропущенный сценарий остаётся незамеченным независимо от покрытия, поэтому список проверок стоит пересматривать после каждой замены компонента или изменения поведения.
Инструменты: CLAUDE.md и Claude Code
Файлы памяти CLAUDE.md дают постоянный контекст между сессиями, работают на нескольких уровнях, версионируются вместе с проектом и позволяют делиться стандартами с командой (руководство по памяти Claude Code). Команда /memory открывает файлы памяти в системном редакторе для прямого редактирования, а команда /init создаёт CLAUDE.md с базовой документацией проекта и конвенциями.
Дополнительный ориентир по дистанции: сайт vibecoding.ru описывается как стройка машины агентов, где за 63 дня набралось 4 642 коммита без строчки, написанной руками. Это не эталон процесса, но полезная иллюстрация масштаба, на котором агенты работают автономно.
Подход не универсален. Если система живёт неделю и выбрасывается, спецификации и evaluations съедят больше, чем сэкономят. Если система обещает пользователю результат и должна переживать замену компонентов, без них проект быстро упирается в потолок: код генерируется легко, а удерживать обещания становится нечем.