Улучшаем Backend-разработку в Cline на примерах

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

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

Чем глубже в лес, тем толще партизаны

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

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

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

Как улучшить промпты в Cline

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

1. Файл PROJECT_MAP.md

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

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

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

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

  • Шаблоны

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

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

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

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

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

• Команды:

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

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

Пример:

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

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

2. Файл RESPONSE_RULES.md

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

Пример:

## Обязательные правила - Всегда опирайся на PROJECT_MAP.md - Соблюдай выявленные архитектурные паттерны - Перед кодом думай о точке расширения и минимальном diff - Объясняй ПОЧЕМУ выбран подход, а не только ЧТО сделано - Не пересказывай задание пользователя ## Формат ответа (обязателен) Каждый ответ должен иметь структуру: 1. Понимание задачи 2. Архитектурное решение 3. План 4. Изменения 5. Как проверить 6. Риски (если есть) ## Если не хватает информации - Задай 1–2 точечных вопроса - Не начинай писать код вслепую

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

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

3. Cline Rules

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

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

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

Сценарий для использования

1. Тесты

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

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

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

2. Документирование

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

3. «Сделай по примеру»

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

4. Аналитика

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

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

5. Генерирование pydantic-моделей по ссылке на Swagger

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

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

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

• Клиент

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

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

Удобно!

6. Создание Postman-коллекций для ручного тестирования

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

Ньюансы

Режим работы

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

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

Отношение

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

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

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

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

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

Советы

Составление файлов doc/ai

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

Если модель тупит

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

Выводы

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