Agentic Engineering — что это
Навык Agentic Engineering описывает методологию разработки, в которой AI-агенты выполняют основную часть реализации, а человек фокусируется на контроле качества, управлении рисками и принятии архитектурных решений. Это подход, в котором инженер выступает как «дирижёр»: декомпозирует задачу, задаёт критерии завершения, выбирает подходящую модель и проверяет результат через автоматические тесты (evals).
Как работает
🔁 Eval-First (сначала тест, потом код)
Основной цикл работы строится вокруг автоматических проверок:
- Определите eval — тест, который описывает желаемое поведение (например, модульный тест на новую функцию).
- Запустите eval на текущем коде — зафиксируйте базовые ошибки (failure signatures).
- Реализуйте фичу с помощью AI-агента.
- Повторно запустите eval — убедитесь, что поведение исправлено.
- Проверьте регрессии — запустите другие тесты, чтобы не сломать существующую логику.
Пример короткого цикла в консоли:
# 1. Написать eval (тест)
pytest tests/test_feature.py -k "new_behavior" --junitxml=baseline.xml
# 2. Запустить AI-агента для реализации
agentic-engineering implement --prompt "add feature X"
# 3. Перезапустить eval и сравнить
pytest tests/test_feature.py -k "new_behavior" --junitxml=result.xml
diff baseline.xml result.xml
📦 Декомпозиция задач (правило 15 минут)
Каждая подзадача должна укладываться в ~15 минут работы агента и соответствовать трём критериям:
- ✅ Независимо проверяема — можно запустить отдельный eval.
- ✅ Один доминирующий риск — например, только безопасность или только API-контракт.
- ✅ Чёткое условие завершения — тест проходит, или код собирается.
Хорошая декомпозиция:
Задача: добавить аутентификацию пользователя
├─ Unit 1: хеширование паролей (15 мин, риск безопасности)
├─ Unit 2: эндпоинт логина (15 мин, риск API-контракта)
├─ Unit 3: управление сессиями (15 мин, риск состояния)
└─ Unit 4: защита роутов middleware (15 мин, риск логики)
Плохая декомпозиция: единая задача на 2 часа со смешанными рисками.
🧠 Маршрутизация моделей по сложности (Model Routing)
Выбор AI-модели в зависимости от задачи:
| Уровень |
Модель |
Тип задач |
Пример |
| 🟢 Лёгкий |
Haiku |
Классификация, шаблонные преобразования, узкие правки |
Переименовать переменную, добавить type annotation, отформатировать код |
| 🟡 Средний |
Sonnet |
Реализация фич, рефакторинг, написание тестов |
Реализовать модуль, отрефакторить функцию, написать unit-тесты |
| 🔴 Сложный |
Opus |
Архитектура, анализ первопричин, многомодульные инварианты |
Спроектировать систему, отладить сложный баг, ревью архитектуры |
Правило экономии: повышайте уровень модели, только когда более дешёвая не справляется из-за явного пробела в рассуждениях (reasoning gap).
🧩 Стратегия сессий
- Продолжать сессию для тесно связанных подзадач (например, несколько функций одного модуля).
- Начинать свежую сессию после крупных фазовых переходов (с реализации на тестирование).
- Делать compact (сжатие контекста) после достижения milestone, а не во время активной отладки.
👁️ Фокус ревью для AI-сгенерированного кода
Человек проверяет:
- Инварианты и граничные случаи —
null, пустые списки, граничные значения.
- Границы ошибок — правильная обработка исключений.
- Безопасность и предположения об аутентификации.
- Скрытые связи между модулями (hidden coupling) и риски rollout.
Не тратьте время на стилевые разногласия — если форматирование и линтинг автоматизированы, такие замечания не нужны.
💰 Отслеживание стоимости
Для каждой задачи рекомендуется вести учёт:
- Уровень модели.
- Примерное количество токенов (input / output).
- Количество повторов (retries).
- Затраченное время.
- Успех / неудача.
Пример записи:
Task: Implement user login
Model: Sonnet
Tokens: ~5k in, ~2k out
Retries: 1 (initial auth bug)
Time: 8 min
Outcome: Success
Когда использовать
- Вы управляете AI-driven разработкой в команде.
- Нужно спланировать декомпозицию задач для агентов.
- Хотите оптимизировать затраты на API моделей.
- Внедряете eval-first подход (тесты до кода).
- Проводите ревью AI-кода по чеклисту.
Важно знать
- Навык хорошо сочетается с другими: tdd-workflow (eval-first + TDD), verification-loop (непрерывная валидация), search-first (поиск существующих решений до реализации), coding-standards (стандарты кодирования на этапе ревью).
- Декомпозиция на 15-минутные блоки — не жёсткое правило, а ориентир для оценки
agent-sized units.
- Маршрутизация моделей — это не догма, а руководство: если Haiku справляется с рефакторингом — используйте её, даже если по таблице рекомендуется Sonnet.
Комментарии
Комментариев пока нет. Будьте первым.