Ваш конспект

Loop Engineering: Тандем моделей для автономной разработки

Ключевые тезисы:

• Использование двух разных моделей (например, от OpenAI и Anthropic) в ролях тимлида и разработчика создает систему автономной разработки с объективным ревью.
• Критерии приемки и тесты — это объективные факты, на основе которых принимается решение о готовности кода.
• Основная проблема одиночной модели — предвзятость и отсутствие постоянной сверки с планом.
• Роль человека — нести ответственность и управлять процессом, а не верить агенту на слово.

Суть подхода: Разделение ролей

Автор применяет принцип работы команд разработчиков к AI-агентам:

• Одна модель (например, GPT-4o/Claude) выступает как тимлид: составляет документацию, планирует, ставит задачи, делает ревью.
• Другая модель (например, Claude Code/Codex) выступает как кодер: пишет код по заданию тимлида.

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

Как работает цикл (Loop Engineering)

Нормальный, адекватный цикл разработки выглядит так:

1. Спецификация и критерии приемки: Тимлид готовит детальный план, ТЗ и четкие критерии, по которым будет оцениваться работа.
2. Имплементация: Кодер получает задачу и пишет код.
3. Тестирование и ревью: Тимлид проверяет код:
   • Прогоняет тесты (unit, end-to-end и др.).
   • Проверяет соответствие критериям приемки.
   • Ищет ошибки, "AI slop" (мусорный код), нарушения стиля.
4. Вердикт:
   • Принято: Если все тесты пройдены и критерии соблюдены. Работа эскалируется человеку.
   • На доработку: Если тесты провалены или критерии не выполнены. Цикл замыкается — код с конкретными замечаниями возвращается кодеру на исправление.

Роль тестов критически важна. Без прохождения тестов любое утверждение агента о готовности кода — всего лишь субъективное мнение. Тесты — это измеримый и объективный артефакт.

Техническая реализация и инструменты

• Инструменты: Автор использует тандем Claude Opus (как тимлид) и GPT-4o/Codex (как кодер), постоянно тестируя и меняя их роли.
• Скиллы (Skills): Для автоматизации созданы специальные "скиллы" в формате .md-файлов:
  • Claude.md: Описывает критерии приемки, запрещает Клоду писать код самостоятельно, указывает, какой скилл использовать.
  • Скилл для Codex (Teamleaded): Детально описывает весь рабочий цикл: дизайн, написание промпта, делегирование задачи кодексу, поллинг статуса, проведение ревью.
• Команда go: Используется для запуска кодера в режиме выполнения задачи до достижения критериев.
• Гейты (Gates): Обязательные проверки, вшитые в go-промпт на каждый этап.

Экономический смысл и цена ошибки

• Вопрос: Зачем платить за две подписки (например, $100 + $100), если можно платить $200 за одну мощную модель?
• Ответ: Это вопрос цены ошибки. Второй ревьювер (другая модель) выступает как "стопер" или "блокер", повышая качество и снижая риски.
• Распределение задач: Модели с более щедрыми лимитами токенов (например, от OpenAI) можно использовать для нагруженных задач, а более "дорогие" (например, Claude) — для критически важного ревью и планирования.

Пример из практики

Задача: Добавить в CRM кнопку экспорта лидов в CSV с определенными полями.

1. Клод (тимлид) получает промпт с критериями (наличие кнопки, правильные поля в CSV, обработка пустого списка и т.д.).
2. Клод вызывает через терминал агента-кодера (Codex) и ставит ему задачу в режиме go.
3. Codex пишет код, пытаясь удовлетворить критерии.
4. Клод "просыпается", проверяет результат: устанавливает зависимости, прогоняет тесты, проводит ревью на качество кода.
5. Если все "зеленое" — работа принимается. Если нет — отправляется на доработку с конкретными указаниями.

Выводы:

• Loop Engineering — это не просто "дать задачу агенту", а выстроить замкнутый цикл с автоматической проверкой на основе объективных критериев.
• Использование тандема разных моделей устраняет ключевую проблему предвзятости и позволяет создавать сложные системы почти автономно.
• Человек в этой системе остается ответственным архитектором и менеджером, который контролирует процесс через четкие критерии приемки, а не пишет код вручную.