Агентная разработка полного цикла: от брифа до деплоя
TL;DR — Ключевые тезисы
- Агентная разработка требует строгого цикла: бриф → спека → реализация → верификация → деплой
- Memory Bank — структурированная база знаний о проекте, без неё модель теряет контекст
- Вертикальные слайсы + CLI-тестирование заменяют хрупкие браузерные E2E-тесты
- Верификация — не опциональный этап, а обязательная гигиена на каждом шаге
- Реальный результат: HR-система из 25 000 строк кода за 2 рабочих дня
Введение: почему агентная разработка — это не просто «попросить ChatGPT написать код»
Агентная разработка полного цикла радикально отличается от привычного «написал промт — получил код». Это системный процесс, в котором AI-агент становится полноценным участником разработки — от уточнения требований до деплоя и верификации на продакшне.
Денис, опытный разработчик и автор Telegram-канала Dexd Notes, на практике выстроил такой флоу и за 2 дня реализовал HR-систему оценки 360 — 25 000 строк кода с нуля. В этой статье — детальный разбор каждого этапа его подхода.
Эта статья для тех, кто уже пробовал работать с Claude, Codex или другими агентами и хочет перейти от случайных экспериментов к воспроизводимому, предсказуемому результату.
Содержание
1. Этап 1 — Бриф: как правильно формулировать задачу
2. Этап 2 — Memory Bank: долгосрочная память проекта
3. Этап 3 — Спецификация и вертикальные слайсы
4. Этап 4 — Верификация и тестирование
5. Этап 5 — CLI-интерфейс вместо браузерных тестов
6. Этап 6 — Стейджинг и деплой без рисков
8. Реальный кейс: HR 360 за 2 дня
9. FAQ
10. Итоги и чеклист
Этап 1 — Бриф: как правильно формулировать задачу
Бриф — это граница между Problem Space (что хочется) и Solution Space (как это реализовать). Большинство разработчиков пропускают этот этап или делают его слишком быстро — и потом удивляются, почему агент сделал «не то».
Итеративное уточнение брифа
Правильный бриф рождается через несколько итераций. Алгоритм такой:
1. Написать первоначальную хотелку в свободной форме
2. Попросить агента (или GPT в веб-чате) выявить противоречия и gaps — то, что не доспецифицировано
3. Добавить недостающее в исходный промт
4. Повторить 5–10 раз, пока модель не начнёт задавать вопросы про несущественные детали
Важный технический приём: вместо того чтобы продолжать диалог (наращивая контекст), редактируйте исходное сообщение. В Codex и Claude Code — двойное нажатие Esc для редактирования предыдущего сообщения. В Obsidian удобно вести «живой промт», который растёт с каждой итерацией.
Почему это важно? Начало контекста — самая «ценная» зона для языковых моделей. Каждый токен там влияет на всю сессию сильнее, чем токены в середине. Мусор в начале контекста = деградация качества на всём протяжении работы.
Структура хорошего брифа
Хороший бриф содержит два раздела:
- Доменный — что мы делаем, предметная область, пользователи, бизнес-логика
- Технический — стек (язык, фреймворк, БД, хостинг), архитектурные ограничения, предпочтения
Совет: используйте мейнстримовый стек. TypeScript + Node, PostgreSQL, Next.js, Vercel — это не занудство, а прагматика. Модели обучены на огромном массиве именно такого кода и работают с ним значительно лучше, чем с экзотическими решениями.
Этап 2 — Memory Bank: долгосрочная память проекта
Memory Bank — это структурированная база знаний о проекте в виде файлов в репозитории. Без него каждая новая сессия агента начинается «с нуля», и он не знает о предыдущих решениях, архитектуре и контрактах.
Зачем нужен прогрев контекста
Прежде чем приступать к задаче, агент должен «прогреться» — изучить Memory Bank. Этапы прогрева:
1. Общий прогрев — агент читает индекс проекта, понимает структуру целиком
2. Специализированный прогрев — агент изучает конкретную подсистему, с которой предстоит работать
Если Memory Bank отсутствует — несколькими промтами попросите агента изучить проект сверху вниз и дождитесь, пока он вернётся с готовым пониманием структуры.
Структура Memory Bank по принципам C4
Эффективный Memory Bank строится по принципам C4-документации (Context → Container → Component → Code) и включает:
index.md— точка входа, обзор системы/specs/— технические спецификации подсистем/plans/— эпики, фичи, планы реализации, отчёты тестированияmemory-bank-bible.md— принципы структурирования (single source of truth, атомарность, прогрессивное раскрытие)
Ключевые принципы Memory Bank:
- Нет дублирования — каждый факт хранится в одном месте
- Кросс-ссылки между документами
- Большие файлы разбиваются на части
- После каждой фичи — обновление документации
Этап 3 — Спецификация и вертикальные слайсы
После брифа агент превращает хотелки в набор эпиков и фич. Но ключевое архитектурное решение здесь — организация кода вокруг вертикальных слайсов.
Что такое вертикальный слайс
Вертикальный слайс — это единица ценности, которая пронизывает все слои системы сверху вниз: UI → API → бизнес-логика → база данных. Для интернет-магазина это может быть «добавить товар в корзину» или «получить персональные рекомендации».
Преимущества подхода:
- Код сгруппирован вокруг функции, а не технического слоя
- Агент понимает, что именно он реализует и как это проверить
- Каждый слайс можно независимо тестировать
- Memory Bank хранит контракт каждого слайса
Планирование без оверинжиниринга
Одна из хронических проблем современных LLM (Claude 4, GPT-5.2, GPT-5.3) — склонность усложнять. Модели оборачивают простые вещи в ненужные абстракции, городят лишние конструкции.
В промте планирования явно пишите: «используй самый простой способ реализации, без оверинжиниринга». Это не просьба, а требование — без него модель будет усложнять по умолчанию.
Этап 4 — Верификация и тестирование
Верификация — центральная тема подхода. Она встроена в каждый этап, а не вынесена в отдельную финальную фазу.
Иерархия тестирования
Acceptance Test (вертикальный слайс) ← самый важный
↑
Integration Tests
↑
Unit Tests
↑
Type checks + linter + build
Принцип: юнит-тесты — это гигиена, обязательная, но вспомогательная. Главный тест — тот, что проверяет, работает ли вертикальный слайс целиком, в соответствии с бизнес-требованиями.
BDD-сценарии как приёмочные тесты
Для каждого вертикального слайса прописывается BDD-сценарий в формате Given/When/Then:
Given: пользователь есть в HR-справочнике компании
When: пользователь пытается войти в систему
Then: вход проходит успешно
Given: пользователь отсутствует в справочнике
When: пользователь пытается войти
Then: система возвращает ошибку 403
Критически важно: сценарий должен покрывать весь габарит фичи, включая все edge-cases и обработку ошибок. Если один сценарий не вмещает — делайте несколько. Агент, которому не дали обратную связь через тесты, выдумывает поведение системы в ошибочных ситуациях — и выдумывает непредсказуемо.
Агентный тест как высший уровень верификации
Для сложных интеграционных сценариев (когда затронуты внешние системы, браузер, несколько сервисов) — создаётся агентный тест: отдельная агентная сессия с промтом, описывающим:
- Что агент должен сделать
- Какое поведение является ожидаемым
- Что считается отклонением и как его зафиксировать
Такой агент гоняет сценарий через браузер или CLI, докладывает о результатах. Это автоматизирует то, что раньше QA делал вручную.
Этап 5 — CLI-интерфейс вместо браузерных тестов
Один из самых практичных инсайтов: браузерная автоматизация через Playwright под управлением агента — ненадёжна. Агент медленно скроллит, теряется в интерфейсах, не может стабильно кликать по элементам.
Решение: общий клиентский модуль + CLI
Архитектура строится так:
┌─────────────────────┐ ┌─────────────────────┐
│ Графический UI │ │ CLI-интерфейс │
│ (Next.js / React) │ │ (командная строка) │
└──────────┬──────────┘ └──────────┬──────────┘
│ │
└──────────┬─────────────┘
│
┌──────────▼──────────┐
│ Общий client.ts │
│ (вся логика API) │
└──────────┬──────────┘
│
┌──────────▼──────────┐
│ Backend / API │
└─────────────────────┘
Ключевой принцип: CLI — это тонкая оболочка над общим клиентским модулем. Вся бизнес-логика взаимодействия с бэкендом — в общей библиотеке. CLI только транслирует команды из терминала в вызовы этой библиотеки.
Преимущества CLI-тестирования
| Критерий | Браузерный тест | CLI-тест |
|---|---|---|
| Скорость | Медленно | Быстро |
| Надёжность | Хрупкий | Стабильный |
| Поддержка | Высокие затраты | Минимальные |
| Покрытие логики | Только UI | Весь клиентский слой |
CLI поддерживает два режима вывода: human-readable (для разработчика) и JSON (для агента). Это позволяет агенту получать детерминированный машиночитаемый ответ о результате каждой операции.
Этап 6 — Стейджинг и деплой без рисков
Пускать агента к продакшн-базе с широкими задачами — это рулетка. Агент всегда может ошибиться: почистить не только тестовые данные, но и продакшн-таблицу.
Три окружения как минимум
Local (разработка) → Beta (стейджинг) → Production
- Local — для быстрых итераций без пушей
- Beta — для агентных тестов, полная копия прода
- Production — только через GitOps-промоушен из беты
Технически: отдельные поддомены (beta.yourdomain.com), отдельные физически изолированные базы данных. Агент работает только в окружении beta.
Верификация деплоя
После каждого деплоя — автоматическая проверка: агент заходит на задеплоенную версию через браузер или CLI, прогоняет smoke test с тестовым пользователем, подтверждает работоспособность.
Без этого случались ситуации: beta полностью оттестирована, деплой прошёл «успешно» — а на проде баг из-за миграции базы данных. Верифицировать деплой обязательно.
Кодревью и упрощение
После реализации и верификации — этап кодревью. Для продакшн-кода (не демо) обязательно.
Главный фокус: упрощение
Модели склонны усложнять код — это системная особенность, а не баг. Claude 4 и GPT-5.x добавляют лишние абстракции, оборачивают простое в сложное, создают длинные цепочки вызовов.
Почему упрощение критично: сложный код сложнее понять модели в будущих сессиях. Модели плохо понимают виртуальное состояние системы, если оно уходит глубже второго уровня вложенности. Каждый лишний уровень абстракции — это потенциальная ошибка при следующей доработке.
Хорошее правило: «если этот код можно написать проще без потери функциональности — значит, нужно написать проще».
Дополнительные аспекты ревью:
- Безопасность: отсутствие незащищённых эндпоинтов, SQL-инъекций
- Типизация: полное использование TypeScript без
any - Лучшие практики языка: Biome/ESLint чисто
Реальный кейс: HR 360 за 2 дня
Задача: HR-система оценки 360 — сотрудники оценивают друг друга, система формирует анкеты, управляет структурой компании.
Стек: TypeScript, Node.js, Next.js, PostgreSQL (Supabase), Vercel
Инструменты: OpenAI Codex (GPT-5.2 / GPT-5.3, high reasoning), ChatGPT для брифа
Результат:
- Старт: вторник после обеда
- Готово: среда вечером
- Объём кода: 25 000 строк
- Покрытие фич: почти все эпики включая UI
Процесс по этапам:
1. Бриф итеративно прорабатывался в ChatGPT (~10 итераций редактирования исходного сообщения)
2. Агент (Codex) получил бриф + структуру Memory Bank Bible → сгенерировал эпики и фичи
3. Каждая фича реализовывалась отдельной сессией (20–50 минут на фичу)
4. Тесты через CLI-интерфейс, скриншоты как доказательства прохождения сценариев
5. UI-референсы из Figma/Tича для графической части
Главный вывод: без оркестратора — хлопотно. Каждую фичу нужно запускать вручную. Следующий шаг — автономный оркестратор, который прогоняет все фичи ночью без участия разработчика.
FAQ
Что такое агентная разработка полного цикла?
Агентная разработка полного цикла — это подход, при котором AI-агент (Claude, Codex, GPT) участвует во всех этапах: от уточнения требований и написания спецификаций до реализации кода, тестирования и деплоя. Разработчик задаёт направление и контролирует результаты, не выполняя рутинные операции вручную.
Чем Memory Bank отличается от обычного README?
Memory Bank — это живая, структурированная база знаний с кросс-ссылками, шаблонами документов и принципами организации (C4-модель, прогрессивное раскрытие). Он обновляется после каждой фичи. README — это статичный документ для людей. Агент читает Memory Bank в начале каждой сессии, чтобы восстановить контекст проекта.
Зачем CLI-интерфейс, если есть Playwright?
Playwright под управлением агента работает медленно и ненадёжно — агент теряется в интерфейсах, не может скроллить, пропускает элементы. CLI-интерфейс тестирует ту же клиентскую логику, что и UI, но детерминированно и быстро. Общий клиентский модуль гарантирует, что CLI и UI используют одни контракты.
Как проверить, что агент не срезал углы при реализации?
Верификация против исходной спецификации — отдельный обязательный этап. По данным экспериментов с Claude 4 Opus и Sonnet, до 15% от первоначального плана может быть выполнено не полностью. После реализации явно просите агента: «сравни результат с планом фичи и укажи, что не реализовано».
Нужен ли стейджинг для небольших проектов?
Как только в проекте появляется хотя бы один сторонний пользователь — стейджинг обязателен. Агент с широкими задачами (тестирование, деплой, работа с БД) может ошибиться и удалить данные. Изоляция beta-окружения — единственная надёжная защита.
Какая модель лучше для агентной разработки?
Для планирования и брифа: GPT-5.2 Pro (при наличии доступа) или GPT-5.3. Для реализации кода: GPT-5.3 с high reasoning в Codex. Claude лучше для творческих задач и обсуждений, но требует больше «ограждений» для точного следования плану.
Итоги и чеклист
Агентная разработка полного цикла — это не магия и не замена разработчика. Это система, которая позволяет одному человеку производить объём кода, ранее требовавший команды.
Ключевые условия работы системы:
- Качественный бриф с итеративным уточнением
- Memory Bank как долгосрочная память проекта
- Вертикальные слайсы с BDD-тестами
- CLI-интерфейс для надёжного тестирования
- Верификация на каждом этапе, не только в конце
- Изолированное beta-окружение
Чеклист агентного флоу
- [ ] Бриф проработан через 5+ итераций, все gaps закрыты
- [ ] Memory Bank создан и прогрет в начале сессии
- [ ] Каждая фича — отдельный вертикальный слайс с контрактами
- [ ] BDD-сценарии покрывают happy path и все edge-cases
- [ ] CLI-интерфейс реализован поверх общего клиентского модуля
- [ ] Тесты прогнаны, скриншоты/логи как доказательства
- [ ] Верификация против исходного плана — явная проверка
- [ ] Beta-окружение изолировано от продакшна
- [ ] После деплоя — автоматический smoke test
Материал подготовлен на основе практического опыта, представленного на стриме канала AI Driven Development совместно с Денисом (Telegram: Dexd Notes).