Привет, Хабр! В этой статье расскажу, как я использую агенты, чтобы упростить Backend-разработку и не тратить на рефакторинг больше времени, чем на написание кода.

Все мы слышали об ИИ‑агентах для «штампования» полноценных сайтов. Звучит заманчиво. Пишешь запрос: «Хочу сайт про собачек», и вот он — готовый сайт. Потом идешь в код и долго подбираешь слова, чтобы цензурно его описать.

Разработка с нуля и работа с «пожившим» проектом с большой кодовой базой — совершенно разные истории. При написании с нуля кодовая база в некоторых случаях будет даже хорошей, или по крайней мере «подходящей» под масштабы проекта.

Как бы мы ни старались, но у человека контекст намного шире, чем у ИИ-агента. И если перед агентом ставить обширные задачи с долей абстракции, возрастает риск, что нам придётся переделывать за ним. В определённый момент агент начнёт тупить, и тогда встанет вопрос: либо вникать в то, что он написал, либо пробовать «докрутить» промпт, надеясь, что само заработает.

Vibe‑разработка — это процесс создания запроса, который определяет временные затраты на разработку. И для этого необходимо передать контекст и установить те самые рамки.

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

Первая «ограда»: необходимо собрать этот файл и хранить его в корне проекта. Он содержит контекст проекта для ИИ‑агента, то есть информацию о том, как здесь принято писать код.

В файле описаны:

• Архитектура:

  • Общая архитектура API

  • Шаблоны

  • Где хранится бизнес-логика

  • Как пишем тесты

• Повторяющиеся паттерны

• Технологии (например, Python 3.11, чтобы вместо Optional сразу писал type | None)

• Структура проекта

• Команды:

  • Как запустить линтеры

  • Как запустить тесты

Пример:

5. Тестирование

- Тесты пишутся с использованием pytest
- Используются общие фикстуры из tests/conftest.py
- Используются фабрики для генерации тестовых данных из tests/utils/factories/
- пишутся через функции

Результат: вы предотвращаете многочасовой рефакторинг и «подгонку» стиля кода под ваш проект. Теперь агент самостоятельно напишет тесты, прогонит линтеры и исправит недочёты.

Это правило мышления и формат ответа для ИИ-агента. В нем указывается, как улучшить уточнение требований и описывается сценарий поведения агента, если точно он не знает, что делать.

Пример:

## Обязательные правила

- Всегда опирайся на PROJECT_MAP.md
- Соблюдай выявленные архитектурные паттерны
- Перед кодом думай о точке расширения и минимальном diff
- Объясняй ПОЧЕМУ выбран подход, а не только ЧТО сделано
- Не пересказывай задание пользователя
  
## Формат ответа (обязателен)
Каждый ответ должен иметь структуру:

1. Понимание задачи
2. Архитектурное решение
3. План
4. Изменения
5. Как проверить
6. Риски (если есть)

## Если не хватает информации

- Задай 1–2 точечных вопроса
- Не начинай писать код вслепую

Далее подключаете предыдущий файл PROJECT_MAP.md для работы в связке. Структура вашего проекта выглядит следующим образом:

docs/ai
├── PROJECT_MAP.md
└── RESPONSE_RULES.md

В Cline создаёте файл GLOBAL_RULE.md (или иначе).

В нём указываете связку из предыдущих файлов:

Роль: опытный django backend разработчик

Всегда:
- ориентируйся на docs/ai/PROJECT_MAP.md
- отвечай по правилам из docs/ai/RESPONSE_RULES.md
- делай минимальные безопасные правки

В начале диалога пиши что ты ознакомился с PROJECT_MAP.md и RESPONSE_RULES.md

С использованием агента генерирование фабрик и написание E2E, модульных или любых других тестов значительно ускоряется. Для меня написание тестов всегда было очень муторным занятием: большая часть энергии уходила не на разработку тестовых сценариев, а на подключение кода, фабрик и подготовку окружения.

Теперь же достаточно написать запрос вроде:

Для ApiView: @path/to/view.py

Напиши тесты для кейсов:
- Кейс 1
- Кейс 2. Параметризированный
- ...
  
Используй freezegun в Кейсе N

Документирование написанного кода и оформление doc-string для функций, классов и модулей. Проект стал значительно приятнее и чище.

Ситуация, когда вы вручную делаете один блок похожего кода и просите «размножить» на остальные участки кода.

Бывают ситуации, когда понимаешь, что выбранный путь — не самый оптимальный.

Какой паттерн лучше подойдёт для рефакторинга кода? Опишите плюсы и минусы.

Иногда агент на основе проекта подсказывает альтернативные решения, но выбор за вами.

Имба. Для написания клиента запрос будет выглядеть так:

Проанализируй swagger: <url-to-swagger>

Создай клиент для получения данных из этого сервиса. Сделай новый класс на подобии: @path/to/clean-example-client.py

Модели положи по аналогии.

Опираясь на структуру проекта, агент опишет:

• Клиент

• Входные и выходные модели

• Фабрики для тестов

Удобно!

Иногда после реализации сложной логики, разбитой по разным конечным точкам и завязанной на различных параметрах, возникает необходимость ручного тестирования на стенде, но фронтенд ещё не готов. В таких случаях достаточно описать агенту, какие ручки и сценарии нужно протестировать, и он создаст полноценный postman-flow. Результат: файл flow.json, который вы импортируете в Postman.

Postman-коллекция от агента

Postman-коллекция от агента

В Cline есть переключатель Plan и Act. Для значительных изменений следует сначала обсудить задачу с агентом и выявить конечную точку, и только потом выполнять.

Моя ошибка заключалась в том, что я пренебрегал этой функцией, выполняя любые запросы в режиме «Исполнения». Из‑за этого приходилось несколько раз писать лишние промпты для исправления, чего можно было избежать, используя режим «Планирования».

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

• Выбор архитектуры

• Выбор технологий

• Формат межсервисного взаимодействия

• Другие, где есть риски и нужен широкий контекст

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

Если модель тупит, значит, контекстная область слишком большая. Чтобы это исправить, нужно разбить задачу на подзадачи и выполнять их по очереди.

Агент — это инструмент, а не панацея. Он не нуждается в отпусках, премиях, отгулах и не болеет. Если не можешь победить — возглавь. Агенты — легальный способ ускорить развитие разработчика, если использовать их с умом.