Когда я показывал этот сервис коллегам, почти все первым делом спрашивали, сколько кода пришлось переписывать за агентом. Руками я не переписывал ничего. За месяц мы собрали и запустили внутренний сервис для партнерской программы агентства, с двумя ролями, спорными случаями, уведомлениями и фоновыми процессами. Весь его код, от схемы базы данных до форм в интерфейсе, написал Codex.
Ну и что, разработчики, получается, больше не нужны? Не думаю. Скорее есть смысл говорить о том, сколько разработчиков теперь нужно команде и чем они будут заняты. Мой опыт подсказывает, что заняты они будут не меньше. Чем быстрее агент выдает код, тем больше времени уходит на все, что его окружает: постановку задач, правила, проверку и решение о том, когда работу можно считать законченной. Работы меньше не стало, но изменилось то, из чего она состоит.
Я не называю это вайб-кодингом, и ниже объясню почему. Расскажу, как был устроен процесс, в котором агент писал код, а я отвечал за результат, где агент ошибался, какие правила из этого появились и что такой способ работы меняет в представлении о том, какая команда нужна продукту.
Что за сервис и зачем он понадобился
У нас есть партнерская программа. Агентства, фрилансеры и консультанты рекомендуют нас компаниям, которым нужна разработка, и если компания становится нашим клиентом, партнер получает вознаграждение. Долгое время все это велось в общей таблице и переписке с менеджером программы, и чем больше становилось партнеров, тем чаще возникали вопросы. Двое партнеров приводили одну и ту же компанию, и нужно было решить, кто пришел первым. Переговоры с клиентом затягивались, и было непонятки с тем, сохраняется ли за партнером право на вознаграждение. Правила существовали, но часть из них жила только в головах, а история решений терялась в чатах.
Новый сервис перенес этот процесс в систему. Партнер закрепляет компанию за собой по ИНН, и это значит, что если в течение срока закрепления компания станет нашим клиентом, вознаграждение получит он. Пока закрепление действует, другой партнер ту же компанию закрепить не может, но может подать спор, если считает, что клиента привел он. Если переговоры идут дольше срока, партнер запрашивает продление, чтобы не потерять право на вознаграждение. При закреплении партнер указывает, какое направление интересует компанию, например проектирование, разработка или поддержка, чтобы менеджер сразу понимал, кому передать запрос. Когда компания подписывает договор, закрепление отмечается как сделка.
В системе две роли. Менеджер партнерской программы видит все закрепления, разбирает споры и продления, управляет партнёрами и списком направлений. Партнер в системе представлен компанией с одним или несколькими сотрудниками, и они видят только закрепления своей компании. Вокруг этого работают история действий, уведомления в интерфейсе и на почту, выгрузка в Excel и ночная фоновая задача, которая пересчитывает статусы и отмечает истекшие закрепления.
Вайб-кодинг и агентная разработка
Если код написала нейросеть, получается, что я проект навайбкодил? Есть общепринятые различия между вайб-кодингом и агентной разработкой. То есть эти подходы могут пересекаться, но не являются синонимами. В первом случае человек описывает в чате, что хочет получить, агент выдает результат, и, если он запускается и выглядит рабочим, его принимают. Что внутри и почему оно устроено именно так, никто не проверяет, код остается для человека как бы слепой зоной. Для прототипа или скрипта на один раз такой подход вполне годится.
Для сервиса, от которого зависит, кто из партнеров получит вознаграждение, мне нужен был другой способ работы. Как раз агентная разработка. Код пишет агент, но генерация — один этап из нескольких. Перед ней есть задача с описанным результатом и ограничениями, после нее идут автоматические проверки, ревью и мое решение, принимать изменения или отправить на доработку. Большую часть изменений я просматривал сам.
Codex я выбрал по привычке, без специального сравнения. Claude Code, по-моему, справился бы с этим объемом так же, и все, о чём пойдет речь дальше, от конкретного инструмента почти не зависит. Начать стоит с того, что оказалось самым трудным.
Бизнес-контекст и границы очевидного
Технически в сервисе нет ничего необычного. Таблицы, формы, роли, фоновые задачи агент пишет уверенно и быстро. Сложность была в бизнес-правилах, и особенно в тех местах, где один экран ведет себя по-разному в зависимости от состояния данных.
Например, форма закрепления. Внешне в ней одно главное поле, ИНН, но за ним стоит несколько сценариев. Сначала система проверяет, что ИНН корректен. Если компания свободна, партнер может ее закрепить. Если она уже закреплена за другим партнером, вместо закрепления открывается форма спора. Если ее закрепил коллега из той же компании-партнера, партнер видит сообщение, что клиент уже за ними.
Такие экраны выглядят готовыми раньше, чем по-настоящему приобретают релизную форму. Основной сценарий работает, интерфейс аккуратный, и легко принять результат целиком, не проверив остальные ветки. Чем убедительнее выглядит работа агента, тем проще пропустить в ней ошибку. Поэтому каждую ветку я либо закрывал тестами, либо проходил руками.
В одной задаче я не прописал отдельно требования к валидации и ошибкам. На бэкенде агент валидацию добавил, а вывод ошибок на фронтенде не сделал. Бэкенд возвращал правильную ошибку, форма не отправлялась, и пользователь не понимал почему. В другой форме email проверялся корректно, а телефон никак. Технически это объяснимо: номер телефона проверить сложнее, для этого нужны дополнительные инструменты. Пользователю эта разница не важна, для него оба поля должны вести себя одинаково.
Универсального правила о том, какой глубины должно быть описание, у меня нет. Ее определяет экспертиза: чем лучше постановщик задачи знает предметную область и чем менее типична задача, тем точнее он понимает, что нужно проговорить явно. Агент выполнит почти любую задачу, и от человека зависит, насколько полно она поставлена. Поэтому основной единицей моей работы стала задача.
Задача с проверяемым результатом
Промпт описывает, что нужно сделать прямо сейчас. Задача фиксирует больше: зачем изменение нужно, как понять, что оно готово, и что получилось в итоге. Для работы с агентом второе оказалось намного полезнее, поэтому все задачи я оформлял по одному шаблону:
- номер и название: номер потом попадал в коммит;
- цель: зачем изменение нужно пользователю и какой сценарий должен работать;
- техническая реализация: что меняется в интерфейсе, API и данных;
- ограничения: что при этом нельзя нарушить;
- верификация: как проверить результат;
- результат: что фактически получилось, этот раздел заполнялся после выполнения.
# 0012 — Авторизация в партнерском сервисе
## Цель
Сотрудник партнера входит в сервис и видит закрепления своей компании. Менеджер получает доступ ко всем закреплениям.
## Техническая реализация
Форма входа по почте и паролю, серверная проверка данных, создание сессии и выход из аккаунта.
## Ограничения
Права проверяются на сервере. Сотрудник партнера не может получить данные другой компании или выполнить действия менеджера.
## Верификация
Проверить вход с верными и неверными данными, сохранение сессии, выход и разграничение доступа между компаниями и ролями.
## Результат
Реализованы вход по почте и паролю и выход из аккаунта. Сессия сохраняется после обновления страницы. Сотрудники партнера видят только закрепления своей компании, менеджер — все закрепления. E2e-проверки входа, выхода и разграничения доступа прошли.
Самым важным пунктом я считаю верификацию. Агент должен заранее знать, как он будет проверять свою работу: какие тесты запустить, какой сценарий пройти, какого поведения ожидать. Если это описано, задача считается завершенной, когда результат подтвержден, а момент, когда код просто написан, промежуточный. Раздел с результатом нужен для обратной связи с планом. По нему видно, где реализация разошлась с тем, что задумывалось, и почему.
Таск-трекера на проекте не было, поэтому задачи хранились прямо в репозитории, в папках активных и завершенных. Номер задачи попадал в сообщение коммита, и по истории коммитов можно было найти задачу, ради которой появилось изменение. Это оказалось удобно и мне, и агенту: он мог сам открыть связанную задачу и восстановить контекст. В проекте с трекером того же можно добиться, если подключить к нему агента. Важно, чтобы у агента был доступ к задачам и их истории.
Такой шаблон может и покажется кому‑то слишком мудреным, но не торопитесь с выводами. Это ощущение проходит после первого случая, когда агент уверенно делает не то, что требовалось, и выясняется, что нужное нигде не было записано. Дальше расскажу, как задача проходила путь от описания до коммита.
Путь задачи от описания до коммита
Каждая задача проходила один и тот же цикл. Я вел роадмап проекта, чтобы расставить приоритеты, и по нему нарезал задачи по шаблону. Готовые задачи попадали в папку активных, а дальше шли по шагам:
- Проработка. Задачу я отдавал агенту в режиме планирования со скиллом grill-me. Агент задает уточняющие вопросы, пока требования не станут достаточно ясными, и на выходе получается план.
- Выполнение. Агент реализует задачу по согласованному плану.
- Автоматическая верификация. Линтеры, проверка типов, тесты.
- Ручной просмотр. Я смотрел изменения сам, иногда до агентного ревью, чтобы сразу понять, в ту ли сторону пошло решение.
- Ревью другим агентом. Код проверял новый агент в отдельном чате.
- Правки. Если ревью находило проблемы, агент их исправлял, и ревью повторялось.
- Закрытие. Когда я считал задачу готовой, агент заполнял раздел с результатом и делал коммит по правилам проекта.
Ревью в отдельном чате понадобилось потому, что агент, который писал код, хуже замечает собственные ошибки и почти никогда не ставит под сомнение свои решения. Новый агент видит изменения без контекста их создания и задает вопросы, которые автору уже не приходят в голову.
Сложнее всего было решить, когда остановиться. Ревью всегда что-нибудь находит: можно переименовать переменную, вынести функцию, добавить еще одну проверку.
Формального критерия здесь нет, и решение принимает человек, который понимает, какие замечания влияют на результат, а какие можно оставить.
Следующую задачу я начинал в новом чате. Так агент не тащит за собой контекст предыдущей работы, который к новой задаче уже не относится, и бонусом экономятся токены.
Весь цикл я выдерживал не всегда, порядок шагов тоже иногда менялся. Но именно в таком виде процесс давал самый предсказуемый результат, и к нему я возвращался каждый раз, когда что‑то шло не так.
Задача измеряется результатом для пользователя
Размер задачи влияет на результат работы агента не меньше, чем подробность описания. Я пришёл к простому принципу: планировать широко, выполнять узко. На этапе планирования полезно охватить функцию целиком, проработать все сценарии и увидеть, как она будет выглядеть в итоге. Выполнять же лучше по частям, и каждая часть должна относиться к одной области.
При этом узкая задача может затрагивать весь стек. Чтобы добавить, например, оспаривание закрепления, агент за один проход меняет схему базы, пишет миграцию, дорабатывает бэкенд и контракт API, обновляет клиент, форму и сценарий сквозного теста. Все это части одной функции, поэтому задача остается цельной, хотя изменений в ней много.
Этот принцип появился не сразу. В первые недели процесс порождал отдельные задачи на документацию, тесты и технический долг. Работа как бы двигалась, но роадмап постепенно превратился в перечень того, чем занят разработчик, и по нему стало трудно понять, как развивается сам продукт. Тогда я поменял правило: каждая задача должна заканчиваться функцией или исправлением, которые можно увидеть и проверить. Миграции, документация и инфраструктурные изменения входят в ту же задачу, если без них функция не готова.
Изменились и формулировки. Вместо последовательности «добавь таблицу», потом «подключи API» агент получал описание сценария: менеджер открывает раздел споров, видит новые заявки, фильтрует их, принимает или отклоняет спор, и партнер получает уведомление о решении. Все техническое, что нужно для этого сценария, становится частью одного результата.
Такие задачи достаточно малы, чтобы их можно было внимательно отревьюить, и достаточно велики, чтобы за каждой стояла понятная пользователю ценность. Бурная активность без видимого результата при таком подходе сразу становится заметна.
Правила, которые хранятся рядом с кодом
Модель не помнит, о чем мы договорились в прошлом чате, поэтому важные ограничения нужно записывать туда, где агент их прочитает. Для этого в репозитории был AGENTS.md, инструкция, которую агент читает перед работой.
Почти каждое правило в нем появилось из повторившейся ошибки. Если часть интерфейса еще не была готова, агент вставлял пояснения вроде «отправка будет подключена позже». Разработчику такая пометка полезна, но на демонстрациях ее видели коллеги, а это уже было ни к чему. После нескольких таких случаев появилось правило: текст интерфейса описывает только доступные действия и реальное состояние системы. Также закрепились правила для форм, названий файлов, документации и жизненного цикла задач. К концу проекта файл занимал около 70 строк, и делить его на скиллы не понадобилось.
Если проект небольшой и правил немного, можно держать все правила в agents.md. Ориентировочно до 200 строк кода будет приемлемо.
### When implementation is complete
- Wait for the user's review.
- Do not create a git commit before the user's review.
- Do not move the task to archive until the user explicitly says that the task is ready.
Рядом лежал CONTEXT.md, словарь предметной области. Партнер и сотрудник партнера в речи легко смешиваются, а в системе у них разные права, и без словаря агент путал их в коде и интерфейсе. Остальная документация появлялась с первого дня: бриф, требования, описание процессов и открытые вопросы, позже архитектура и пользовательские сценарии. Чем полнее контекст лежит в репозитории, тем реже агенту приходится угадывать и тем меньше правок остается на ревью.
Стек знаком не целиком
С частью технологий в этом проекте я раньше в продакшене не работал. С агентом вход в них занял намного меньше времени. Он сразу предлагает рабочий вариант, а мне оставалось разобраться, почему решение устроено именно так и подходит ли оно проекту.
Условие здесь одно: отвечать за решения все равно человеку.
В незнакомом инструменте сложнее заметить, что агент выбрал неудачный путь, поэтому именно эти части проекта я проверял внимательнее всего. Агент позволяет быстро взяться за новую технологию, а общее понимание разработки помогает вовремя увидеть в ней ошибку.
Команда становится меньше, а требования к людям растут
Агент сильно сокращает механическую часть работы: написание кода, перенос одинаковых изменений между слоями, исправление мелких ошибок. Раньше на такой объем потребовалось бы несколько разработчиков, здесь его закрыл один человек с агентом. Потребность в большой команде действительно снижается, на мой взгляд.
Новые люди на проекте замедляют его. Растягиваются во времени онбординг и координация, а ключевые решения все равно принимаются по очереди. Агент меняет эту арифметику, потому что расширяет возможности одного человека, не требуя лишних созвонов и согласований. Последовательные решения при этом никуда не исчезают. Архитектура, модель данных, бизнес-правила и приемка результата по-прежнему требуют человека, и теперь именно на них уходит основное время.
Поэтому техническая экспертиза становится важнее. Если посадить за агента человека без опыта разработки, он получит, наверное, более-менее вменяемый результат, но не сможет оценить, где в нем ошибка, какая ветка сценария не проверена и что сломается под нагрузкой. Разработчик с опытом понимает, как лучше устроить работу с агентом, и отвечает за то, что уходит в продакшн.
Нужный для такой работы профиль мы подробно описывали в статье про суперспособности продуктового разработчика: человек понимает цель бизнеса, уточняет границы задачи, фиксирует договоренности и отвечает за результат. С агентом эти качества из желательных становятся обязательными, потому что писать код за такого разработчика теперь есть кому, а думать он должен все же сам.
Итог
Если вы собираетесь работать с кодинг-агентом на реальном продукте, вот минимальный набор правил:
- каждая задача описывает результат для пользователя и заканчивается тем, что можно увидеть и проверить;
- в каждой задаче прописано, как агент проверит свою работу;
- код, написанный одним агентом, ревьюит другой, в отдельном чате, а решение о приемке остается за человеком;
- правила, которые важны для следующих задач, записаны в репозитории рядом с кодом;
- у проекта есть словарь предметной области, чтобы человек и агент называли вещи одинаково.
За месяц работы я не написал руками ни строчки кода, и это был довольно насыщенный в целом проект. Агент взял на себя набор кода, а постановка задач, правила, проверка и ответственность за результат остались на мне. Кажется, именно из них теперь и состоит работа разработчика.
