# Цикл работы с агентом

> Подготовка, работа и контроль качества: как выглядит рабочий день с агентной разработкой

_Источник: https://sii.sergeivolchkov.ru/materials/agent/workflow_



Агентная разработка в курсе устроена как цикл: машина генерирует, человек
проверяет и отвечает за результат. **Сгенерированный агентом код — твой
код**, и вопросы на защите будут к тебе.

Цикл состоит из трёх фаз.

<PhaseMark phase="a" />

## Фаза A. Подготовка — до первой строчки кода [#фаза-a-подготовка--до-первой-строчки-кода]

Эту часть чаще всего пропускают, а именно здесь обычно и закладывается
неудачная сессия.

1. **Собери контекст в отдельном пространстве.** Задача, ограничения,
   примеры — в отдельный проект (Claude Projects, отдельный чат, папка
   `research/`), где формируется видение результата. Основной репозиторий
   не место для брейншторма.
2. **Ресёрч воронкой.** Сначала точный запрос,
   потом расширение поля, потом отбор релевантного. Каждый источник
   проверяется — агент уверенно цитирует несуществующее.
3. **Напиши бриф.** Одна страница: какой мир строим, для кого, чем
   меряем. Это вход и для команды, и для агента.
4. **Создай память агента — `AGENTS.md`.** Соглашения проекта, стек,
   грабли, глоссарий. [Как её писать](/materials/agent/context).
5. **Окружение сразу.** `compose.yml` и `.env` в первый день, а не
   «когда будет что запускать». Агент, у которого есть способ запустить
   код, работает принципиально иначе, чем агент, пишущий вслепую.

Промышленная формулировка того же: **неясность намерения активно создаёт
риски**. Модель не сделает хороший промпт из размытой идеи — она сделает
её ещё более размытой.

<PhaseMark phase="b" />

## Фаза B. Работа — генерация под присмотром [#фаза-b-работа--генерация-под-присмотром]

6. **«Гугли всё непонятное» — постоянная инструкция агенту.** Незнакомый
   API, версия библиотеки, поведение фреймворка — ищем, а не
   галлюцинируем. Правило живёт в `AGENTS.md`, чтобы не повторять его
   каждую сессию.
7. **Каждое действие просматривается человеком.** Не уверен в решении —
   отправь агента искать подтверждение или дай направление сам. Принял
   не глядя — принял ответственность вслепую.

Ещё два приёма из практики:

* **Брейншторм и исполнение — в разных сессиях.** В финальный промпт
  уходит уже принятое решение, а не процесс его принятия.
* **Заранее проговаривай, чего делать не нужно.** Ограничения («не
  трогай схему БД», «без новых зависимостей») экономят больше времени,
  чем подробное описание желаемого.

<PhaseMark phase="c" />

## Фаза C. Качество — планку держит машина [#фаза-c-качество--планку-держит-машина]

8. **Ревью-циклы «пока не найдётся существенное».** После пары модулей —
   полное ревью проекта агентом, исправления, повторный проход. Важная
   деталь: **нужен порог значимости**. Без него цикл не сходится — мелочи
   находятся бесконечно. Договорись заранее: чиним то, что ломает
   поведение или безопасность; косметику — списком в бэклог.
9. **Инструментальная планка.** `uv` (окружение и пакеты), `ruff`
   (линт и формат), `ty` (типы), pre-commit hook. Качество держит машина,
   а не сила воли в конце спринта.

```bash
uv sync                 # окружение из lock-файла
uv run ruff check --fix # линт и автоисправления
uv run ty check         # типы
uv run pre-commit install
```

Это ровно те же «sensors», о которых речь в
[материале про контекст](/materials/agent/context): обратная связь, по
которой агент понимает, что сделал не так, — без участия человека в
каждой мелочи.

## Отчёт агентной разработки [#отчёт-агентной-разработки]

У цикла есть письменный след: `docs/agent-workflow.md` — что генерировал
агент, что пришлось чинить руками, какие правила после этого появились в
`AGENTS.md`. Это не бюрократия, а единственный способ отличить «агент
написал систему» от «агент написал мне проблему, которую я не понимаю».

Хороший отчёт отвечает на три вопроса: **где агент сэкономил часы, где
он ошибся и как ты это поймал, что изменилось в правилах после этого**.