Методология триады: как я выстроил работу с двумя ИИ-агентами

Начало года. Самое время пересмотреть рабочие процессы. Пока задачи ещё не навалились, можно спокойно попробовать что-то новое. Расскажу про подход, который изменил мою работу за последний год.

Меня зовут Михаил Дюжев, я директор департамента обеспечения качества в Ростелекоме. 15 лет в ИТ. Несмотря на управленческую роль, я продолжаю глубоко участвовать в технических процессах: проектирую архитектуру тестовых фреймворков, пишу код, провожу проверки. Работы много, а времени мало.

В какой-то момент понял, что нужен помощник, который возьмёт на себя рутину. Не замена мне, а усилитель. Чтобы я мог сосредоточиться на архитектурных решениях и сложных случаях, пока кто-то другой пишет типовой код по моим инструкциям.

Этим «кем-то» стали нейросетевые агенты. Расскажу про подход, который мы обкатали на нескольких проектах в рамках экспериментов с этими инструментами.

Почему именно автоматизация тестирования

В Ростелекоме в направлении автоматизации тестирования мы часто экспериментируем с новыми подходами, инструментами и внедрением агентов. Почему именно здесь? Цикл разработки короче, меньше заинтересованных сторон, а значит путь от гипотезы до результата проходит гораздо быстрее. Можно попробовать что-то новое и через неделю понять, работает это или нет.

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

Три роли, три участника

Началось всё с раздражения. Сижу с агентом, пытаюсь что-то сделать, и понимаю: мы оба занимаемся одним и тем же. Я думаю над архитектурой, он тоже думает. Я начинаю писать код, он параллельно что-то генерирует. В итоге два полуфабриката вместо одного готового результата.

Плюс бесконечные уточнения. «А ты имел в виду так или вот так?», «Какой шаблон использовать?», «Куда положить файл?». Половина времени уходила на объяснения вместо работы.

Тогда я попробовал разделить роли. Получилась триада.

Три роли, три задачи

Я (человек) выступаю владельцем продукта. Решаю что делаем, принимаю результат, говорю «это не то» когда это не то. Провожу проверку кода и разрабатываю HLD-схемы.

Claude Opus (в команде зовём «шеф») работает стратегом. Думает, планирует, пишет инструкции для агента, проверяет результаты. Работает через веб-интерфейс. Видит большую картину.

Claude Code (он же «коллега») работает исполнителем. Пишет код, запускает команды, фиксирует изменения. Работает в редакторе кода. Не философствует, а делает.

Главный принцип: Opus думает, Code делает, я направляю и проверяю.

Если смешать роли, начинается хаос. Opus выдаёт код, который некуда деть. Code уходит в рассуждения вместо работы. Я теряюсь в деталях вместо того, чтобы думать о продукте.

Хороший признак правильной настройки: Code не тратит время на размышления, а сразу выдаёт результат. Если агент начинает философствовать, значит инструкции недостаточно чёткие.

Почему именно два агента, а не три или пять

Пробовал добавить третьего агента. Специализированного. «Этот пусть пишет тесты, этот код, этот документацию». Логично же?

На практике получилась каша. Я начал терять контекст, пропускать ошибки, делать допущения вместо проверки. Мозг просто не справлялся.

Это не моя личная проблема. В менеджменте есть понятие нормы управляемости: руководитель эффективно управляет 5-7 людьми. С агентами это число меньше, потому что они работают быстрее и генерируют больше результатов для проверки.

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

Ограничение на два агента это не недостаток, а защита. Естественный ограничитель, который не даёт превратиться в бездумного диспетчера задач.

Что реально ускоряется

Давайте честно. Мы пока не готовы называть конкретные цифры ускорения. Оценки на текущем этапе сильно гуляют в зависимости от типа задач, сложности проекта и опыта работы с агентами. Но видим, что на определённых задачах работа идёт значительно быстрее.

Где эффект заметен сильнее всего:

• Настройка тестовой инфраструктуры

• Написание типовых автотестов

• Анализ и исправление стандартных ошибок

• Генерация кода по шаблонам

• Рефакторинг по известным подходам

Это не магия. Это автоматизация рутины.

Что НЕ ускоряется

Нейросеть не ускоряет то, что требует понимания контекста и критического мышления:

• Стратегическое планирование

• Определение приоритетов

• Проверка архитектурных решений

• Общение с командой и бизнесом

• Исследовательское тестирование

• Понимание предметной области

Агент берёт на себя рутину, человек занимается тем, где нужна голова. Это разделение фундаментально.

Настройка: три файла, которые меняют всё

Перед работой с агентом нужно потратить время на настройку. Это инвестиция, которая окупается очень быстро.

Файл 1: CLAUDE.md

Главный контекст проекта. Агент читает его автоматически при старте. Кладётся в корень репозитория.

# Warehouse Management System

## Проект
Система управления складом для логистической компании.
Микросервисная архитектура, 12 сервисов, ~50k пользователей.

## Стек
- Backend: Java 17, Spring Boot 3.2, PostgreSQL 15
- Frontend: Vue 3, TypeScript, Pinia
- Инфраструктура: K8s, GitLab CI/CD, Prometheus/Grafana
- Тесты: JUnit 5, REST Assured, Selenide

## Архитектура
/backend
  /warehouse-api      - REST API для работы со складом
  /inventory-service  - управление товарами
  /order-service      - обработка заказов
/frontend
  /warehouse-ui       - основной интерфейс
/tests
  /api-tests          - автотесты API
  /e2e-tests          - UI тесты

## Ключевые команды
# Сборка
mvn clean package -DskipTests

# Тесты
mvn test                           # unit
mvn verify -Pintegration           # integration
cd tests/api-tests && mvn test     # API тесты

# Локальный запуск
docker-compose up -d

## Правила (нарушать нельзя)
1. Не менять версии зависимостей без согласования
2. Не трогать файлы в /legacy до рефакторинга
3. Коммиты через feature-ветку → MR → проверка
4. Тесты обязательны для нового кода
5. Логирование через SLF4J, не System.out

## Текущий статус
Спринт 14: рефакторинг inventory-service
Активные задачи: WH-234, WH-235, WH-237

Размер файла: 200-400 строк. Больше не нужно, меньше не даёт достаточного контекста.

Файл 2: settings.json

Настройки агента. Кладётся в .claude/settings.local.json. Определяет что можно делать без спроса, что требует подтверждения, что запрещено.

{
  "permissions": {
    "allow": [
      "Bash(mvn test *)",
      "Bash(mvn clean package *)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(grep *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(curl -X GET *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Bash(docker system prune *)",
      "Bash(mvn deploy *)",
      "Bash(kubectl delete *)"
    ]
  },
  "preferences": {
    "commitStyle": "conventional",
    "testFirst": true,
    "maxFilesPerChange": 10
  },
  "context": {
    "currentSprint": "Спринт 14",
    "activeTasks": ["WH-234", "WH-235", "WH-237"],
    "focusArea": "inventory-service refactoring"
  }
}

Начните с разрешений на чтение и тесты. Это безопасно и сразу ускоряет работу. Запретите всё, что связано с продакшеном. Добавляйте разрешения постепенно по мере доверия.

Файл 3: Инструкции к задачам

Папка docs/instructions/ с детальными инструкциями для крупных задач. Каждая задача или фаза в отдельном файле.

# WH-234: Рефакторинг InventoryService

## Контекст
InventoryService сейчас делает слишком много: и бизнес-логику, 
и валидацию, и работу с БД напрямую. Нужно разделить на слои.

## Задачи

### Task 1: Создать InventoryRepository
Файл: `inventory-service/src/main/java/.../InventoryRepository.java`

По образцу из `order-service/.../OrderRepository.java`:
- Интерфейс extends JpaRepository
- Кастомные методы для поиска

Тест: `InventoryRepositoryTest.java` - минимум 3 теста

Коммит: `refactor(inventory): extract repository layer`

### Task 2: Выделить валидацию
...

## Критерии готовности
- [ ] Все существующие тесты проходят
- [ ] Покрытие нового кода > 80%
- [ ] Нет прямых обращений к EntityManager из Service

Рабочий цикл на практике

«Утро»: планирование с Opus

Открываю чат с Opus, загружаю контекст проекта. Вот реальный пример диалога:

Я: Сегодня работаем над WH-234. Посмотри текущее состояние inventory-service, составь план рефакторинга на 4-5 задач.

Opus: Посмотрел структуру. InventoryService на 800 строк, делает слишком много. Предлагаю разбить так:

1. Выделить InventoryRepository (работа с БД)

2. Создать InventoryValidator (валидация входных данных)

3. Вынести InventoryMapper (преобразование DTO)

4. Оставить в сервисе только бизнес-логику

5. Добавить тесты на каждый новый класс

Начать с repository, потому что от него зависят остальные. Хочешь, подготовлю детальную инструкцию для Code?

Я: Да, готовь. И добавь примеры из order-service, там похожая структура.

После этого Opus создаёт файл docs/instructions/WH-234.md с детальным планом.

«День»: работа с Code

Открываю редактор с Claude Code. Вот как выглядит типичная сессия:

Я: Прочитай CLAUDE.md и docs/instructions/WH-234.md. Начинай с Task 1.

Code: Прочитал. Создаю InventoryRepository по образцу OrderRepository.

[создаёт файл, показывает код]

Готово. Добавил интерфейс с базовыми методами и три кастомных: findByWarehouseId, findByProductCode, findLowStock. Запустить тесты?

Я: Запускай.

Code: Тесты прошли. Коммит?

Я: Коммить. Дальше Task 2.

Короткие команды работают лучше длинных, когда агент уже в контексте. «Task 2, поехали» эффективнее повторения всей инструкции.

Примеры команд, которые работают

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

# Начало работы
Прочитай CLAUDE.md и docs/instructions/[задача].md

# Переключение между задачами
Мы на WH-234, Task 3

# Быстрые команды в контексте
Дальше
Task 2, поехали
Коммить
Запусти тесты
Покажи diff

# Исправления
Откати последний файл
Сделай как в order-service
Убери лишние логи

# Проверки
Что поменялось?
Какие файлы затронуты?
Есть конфликты?

Если агент потерял контекст

После долгой паузы или сжатия истории диалога достаточно:

«Прочитай CLAUDE.md, мы на WH-234, Task 3.»

Не нужно пересказывать историю. Агент восстановит контекст из файлов.

Коммиты

После каждой логической единицы работы, не в конце дня. Это позволяет откатиться если что-то пошло не так.

Типичные грабли и как их обходить

Агент застрял на задаче

Не объясняйте словами. Команда «сделай как в файле X» работает лучше абстрактных объяснений. Конкретный пример всегда эффективнее теории.

Плохо: «Нужно сделать репозиторий с правильной структурой и методами для поиска»

Хорошо: «Сделай как в order-service/OrderRepository.java, только для inventory»

Результат неправильный

Откатите через git и дайте более точную инструкцию. Попытки «починить» плохой результат обычно дороже, чем переделать с нуля с правильным ТЗ.

Плохо: «Поправь вот тут и вот тут, и ещё вот это не так»

Хорошо: «git checkout -- . Теперь давай заново. Создай файл X с методами A, B, C. Пример структуры в файле Y»

Агент философствует вместо работы

Инструкции слишком абстрактные. Добавьте конкретики: образцы кода, точные шаги, чёткие критерии.

Плохо: «Нужно улучшить производительность сервиса»

Хорошо: «Добавь кэширование в метод getInventory(). Используй @Cacheable как в ProductService.getProduct()»

Слишком много переспросов

Улучшите CLAUDE.md. Скорее всего, там не хватает контекста о проекте или правилах.

Шаблон хорошей инструкции

Вот структура, которая работает:

# [Номер задачи]: [Название]

## Контекст
Одним абзацем: что не так сейчас и почему это нужно исправить.

## Задачи

### Task 1: [Конкретное действие]
Файл: [точный путь]
По образцу: [путь к примеру]
Что сделать:
- [конкретный пункт 1]
- [конкретный пункт 2]
Тест: [название теста]
Коммит: [текст коммита]

### Task 2: [Следующее действие]
...

## Критерии готовности
- [ ] [Проверяемый критерий 1]
- [ ] [Проверяемый критерий 2]

## Чего НЕ делать
- Не трогать [файл/модуль]
- Не менять [что-то конкретное]

Метрики: как понять что всё работает

Хорошая сессия:

• Агент выполняет задачи без лишних вопросов

• Результат соответствует ожиданиям с первого раза

• Время уходит на проверку, не на объяснения

Плохая сессия:

• Много переписки

• Частые переспросы

• Результаты приходится переделывать

• Ощущение что быстрее было бы самому

Если сессии плохие, проблема обычно в подготовке. Улучшайте CLAUDE.md и инструкции.

Первый запуск на новом проекте

1. Opus анализирует проект, создаёт CLAUDE.md

2. Выбираете простую первую задачу для калибровки

3. Code выполняет, вы смотрите на результат

4. Корректируете инструкции по итогам

После 2-3 задач процесс налаживается и дальше идёт на автомате.

Честный итог

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

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

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

Попробуйте на небольшом проекте. Настройте CLAUDE.md, дайте агенту простую задачу, посмотрите на результат. Дальше разберётесь.