Код — больше не первая стадия: эксперимент с агентами

На предыдущей работе был простой подход: используем любые ИИ‑инструменты — главное результат. Что приводило к тому, что разработчик не мог внятно объяснить, для чего это написано. Главное, что тесты проходят? А то, что находится в чёрном ящике — дело второстепенное.

На текущей работе к ИИ отношение осторожное. По моим наблюдениям многие используют как чат, а не как агент. Есть определенные модули, которые не должны утечь. Мне стало интересно разобраться насколько можно автоматизировать генерацию кода.

Я вижу четыре основных варианта использования ИИ в разработке:

• Чат — активно используем уже пару лет.

• Агент — пытаемся с помощью промптов объяснить чёрному ящику что нужно сделать.

• Рой агентов — параллельная работа нескольких агентов.

• Flow — о нём пойдёт речь в этой статье.

Что такое Flow

Задумка такая: что с помощью markdown — файлов описываем поведение, навыки, правила и архитектурные решения, а потом одной командой запускаем Flow. Процесс сильно напоминает CI/CD‑пайплайн.

Создадим четыре основных сущности:

• Commands — процесс (как запускается):

  • Analyze — анализирует требования и превращает их в спецификацию.

  • Design — проектирует систему на основе утвержденной спецификации.

  • Develop — реализует систему согласно спецификации и архитектуре.

  • Review — проводит ревью кода и проверяет качество реализации.

  • Security — проверяет систему на уязвимости и риски.

  • Test Generation — создает тестовые сценарии.

  • Flow Orchestrator — управляет полным жизненным циклом разработки.

  • DocsExplorer — следит за актуальностью документации.

• Agents — мышление:

  • Analyst — пишет поведение.

  • Architect — проектирует архитектуру.

  • Developer — реализует наши требования по придуманной архитектуре.

  • Reviewer — проверяет код.

  • QA — тестировщик.

  • Security — проверка на безопасность.

  • DocsExplorer‑ документация.

• skills — инженерные правила и стандарты кодирования.

• spec — истина системы (генерируется агентами).

Попробуем на примере:

«Нужно сделать возможность оформления заказа книги. Должен быть сервис, который принимает заказ, и проверка наличия товара на складе»

Запускаем одной командой /flow — и процесс идёт линейно, останавливаясь на этапах для апрува:

Правила работы:

• Этап не стартует, пока его зависимость не получила статус APPROVED.

• Статус хранится в front‑matter файла (single source of truth).

• Все переходы состояний пишутся в append‑only audit‑log.

• Если одобренный артефакт меняется — все зависящие от него артефакты автоматически становятся STALE и требуют повторного ревью.

  Агент в каждой фазе — это просто роль (аналитик, архитектор, разработчик), а решение «пропустить дальше» остаётся за разработчиком.

Этот STOP‑на гейте — не даёт агенту сразу прыгнуть от требований в код.

Этап 1 (Analysis) отклонил и дал замечания:

• Убрать из анализа технические решения (EF Core, PostgreSQL, InMemory, HttpClientFactory, конкретные таймауты) — анализу не место решать «как».

• Добавить раздел Domain Entities.

• Добавить раздел Use Cases.

После правок анализ ушёл на повторное ревью версией v2 — одобрил. Весь цикл остался в audit‑log:

• 01-analysis v1 | READY_FOR_REVIEW → REJECTED | убрать архитектурные решения +entities; +use cases; формат ошибок.

• 01-analysis v2 | REJECTED → DRAFT → READY_FOR_REVIEW → APPROVED.

Вот ради этого момента всё и затевалось: ошибку поймали на уровне текста, до единой строчки кода. Поправить абзац в спеке — пара минут. Переписывать сервис, сгенерённый по кривой спеке — полдня

Что получилось в коде

После одобрения Analysis и Design сгенерировались два сервиса на ASP.NET Core 9, чистая архитектура, сборка — 0 ошибок / 0 предупреждений. Структура проекта соответствует Clean Architecture: отдельные слои Application, Domain, Infrastructure

Что ещё нужно доработать:

• Проверяемое поведение — добавить полноценные unit‑тесты и интеграционные тесты.

• approve/reject я проставляю руками, статусы артефактов и audit‑log тоже веду вручную — отдельной программы‑оркестратора нет. А каскад STALE (когда правка одобренной спеки должна автоматически пометить зависимые артефакты устаревшими) в этом прогоне даже не понадобился — я его просто не проверял. Всё это надо отдать оркестратору: чтобы он сам блокировал следующий этап до одобрения предыдущего, вёл лог и пересчитывал статусы.

Что я понял про сам подход:

• Для маленьких проектов, это ощутимый overhead.

• Для больших проектов, похоже, взлетит — но только если спека нормальная и покрыть тестами.

• В легаси‑проектах можно внедрять постепенно, описывая сложные места в skills по мере необходимости.

• По итогу мы получаем команду, которой дали задания и ждем результат — проверяя качество на этапах выполнения.

Использовал:

Claude Opus 4.8

Промпт:

/flowTASK:Create two ASP.NET Core 9 REST services: Order Service and Stock Service.Order Service must expose a POST /orders/buy endpoint that accepts bookId, userId, and quantity. The request should be validated, and Order Service must call Stock Service over HTTP REST to verify whether the requested book is available in stock.Stock Service must expose a GET /stock/check/{bookId} endpoint that returns a JSON response containing bookId, available, and quantity.The stock logic may be mocked as follows: If bookId ends with "1", the book is always available. If bookId ends with "0", the book is unavailable. Otherwise, return a random availability result.Based on the response from Stock Service: If available = true, create an order with status CONFIRMED. If available = false, create an order with status REJECTED.If Stock Service is unavailable or times out, Order Service must return HTTP 503 Service Unavailable.Requirements: ASP.NET Core 9 REST over HTTP only JSON only Clean Architecture Dependency Injection FluentValidation ProblemDetails for error handling Serilog logging

Репозиторий с кодом и примером Flow.