Коротко
Старший фронтенд-разработчик Mindbox Игорь Уваров описывает плагин, который исследует код, документацию и архитектурные решения до начала реализации. Агент выявил несколько скрытых ограничений и помог предотвратить ошибки, но статья также показывает, что проверка человеком остается необходимой: часть UX- и граничных дефектов не была замечена, а один регресс попал в прод.
Контекст
Игорь Уваров — старший фронтенд-разработчик Mindbox, отвечающий за интерфейс аналитических отчетов. В январе 2026 года, когда, по его словам, агент уже пишет около 90% кода, он решил делегировать ему предварительный анализ задач: в компании нет системных аналитиков, поэтому разработчики сами собирают требования и контекст. Поводом стала неудачная попытка реализовать изменение отчетов через чат-агента без понимания архитектуры: бизнес-логику распределили по 30 функциям, и MR отклонили.
Главное
- Игорь Уваров — старший фронтенд-разработчик Mindbox; он сообщает, что с января 2026 года агент пишет около 90% его кода.
- Задача по отчетам Mindbox: разделить «Все клиенты» на «Все», «Идентифицированные» и «Анонимные», добавить «Долю выручки» и «Долю заказов».
- Попытка реализовать фронтенд через чат-агента без исследования кода привела к распределению бизнес-логики по 30 функциям и отклонению MR.
- Агент сверяет требования с ADR, изучает связанные репозитории, документацию и историю изменений; для этого используются MCP, Sourcebot MCP или Glab CLI.
- Для интерактивного ревью спецификации автор использует Plannotator; спецификация сохраняется как
.devflow/<branch>/spec.md. - Чек-лист подготовки охватывает права, edge cases, сбои, конкурентный доступ, целостность, ввод, необратимые действия и ограничения объема данных.
- Субагент-критик проверяет пропуски и противоречия, в том числе состояния до и после
remove/delete/clear/overwrite/reset, скрытые предположения и blast radius. - Агент выявил недопустимое значение
all, забытое правило передачи ID целей, несоответствие ADR и разную передачу сегмента «Все» для таблицы и графика. - После ручной приемки обнаружили неясную принадлежность метрик к сегменту и отображение «−0%»; другой пропущенный фильтр привел к потере части данных в проде.
- После экспериментов с одним скиллом, девятью скиллами и полным оркестратором автор оставил набор скиллов, а оркестратор ограничил генерацией кода с чистым контекстом субагентов.
Как сделано
Автор не стал внедрять полный Spec-Driven Development, а сосредоточился на исследовании задачи и подготовке спецификации. Сначала это был скилл примерно на 30 строк, затем к нему добавили чек-лист: права и роли, граничные случаи, сбои, конкурентный доступ, целостность данных, некорректный ввод, необратимые действия и объем данных. Агент задает до 2–3 вопросов за раз, готовит черновик spec.md в .devflow/<branch>/spec.md и ждет подтверждения перед сохранением.
Для поиска контекста агенту дали доступ к ADR, внутренним бизнес-требованиям, архитектурным описаниям, Gherkin-сценариям и словарю терминов. Он использует MCP, Sourcebot MCP или Glab CLI для работы с кодом и историей изменений, а Plannotator — для браузерного ревью спецификации. Отдельный субагент-критик ищет пропущенные edge cases, риски деструктивных операций, неверные предположения, архитектурные несоответствия и возможный радиус воздействия.
Плагин развивался через несколько вариантов: от одного скилла — к девяти скиллам, затем к оркестратору полного цикла. Из-за неудобства повторного запуска предыдущих этапов автор вернулся к набору скиллов. В четвертой версии оркестратор используется только для генерации кода: он берет задачи из плана и запускает для каждой субагента с чистым контекстом. Человек по-прежнему проверяет понятность интерфейса и принимает результат.
Результаты
В задаче о сегментах отчетов требовалось заменить «Все клиенты» на «Все», «Идентифицированные» и «Анонимные», а также добавить показатели «Доля выручки» и «Доля заказов». Агент нашел четыре существенных «слепых пятна»: забытое архитектурное решение в ADR; недопустимое значение all в запросе к бэкенду, способное вызвать ошибку при сохранении настроек; код, который при рефакторинге удалял правило передачи идентификаторов целей для целевых метрик; и разное кодирование сегмента «Все» для таблицы и графика, из-за которого таблица осталась бы пустой. В другом случае агент обнаружил, что предположение о группировке сегментов «с заказами/без заказов» не соответствует фактическому использованию интерфейса.
При этом приемка выявила не замеченные ранее проблемы: на карточках новых метрик не было понятно, к какому сегменту относится значение, а округление малого отрицательного прироста показывало «−0%». Еще один исключительный фильтр был потерян при рефакторинге и попал в прод; клиент сообщил о пропавших данных через две недели, после чего на следующий день выпустили исправление и тест. Численных измерений экономии времени или общего снижения дефектов автор не приводит.
Ограничения
Это практический рассказ одного разработчика, а не контролируемая оценка эффективности: нет статистики по числу задач, предотвращенных дефектов, времени или стоимости разработки. Агент зависит от доступности и полноты документации, кода и контекста; он не может надежно оценить, понятен ли интерфейс пользователю. Даже после подготовки спецификации и тестирования человек пропустил UX- и граничные проблемы, а один регресс обнаружили уже в проде. Автор не приводит точные названия и версии используемых моделей, а также стоимость инструментов.
Что взять себе
- Перед генерацией кода полезно дать агенту доступ не только к задаче, но и к архитектурным решениям, связанным модулям и истории изменений.
- Чек-лист и отдельная критическая проверка помогают систематически искать пропуски, но не гарантируют полноту требований.
- Оркестрация полного цикла может усложнить возврат к предыдущим этапам; разделение процесса на управляемые скиллы иногда практичнее.
- Оставляйте ручную UX-приемку и проверку исключений: агент может не заметить неочевидное поведение интерфейса, а тестирование не исключает продакшен-регрессии.
Читать оригинал, если…
Откройте оригинал, если нужны полные тексты инструкций для скилла и субагента-критика, подробности эволюции плагина или примеры его интеграции с внутренними инструментами Mindbox.