Тандем AI-моделей: автономная разработка без ручного ревью

Проблема одной модели: предвзятость

Главная проблема: одна AI-модель, которая пишет код, уже считает его правильным. Она защищает свои решения, не видит собственных ошибок и пропускает баги, потому что закоснела в своей точке зрения. Это когнитивное смещение нельзя преодолеть, попросив ту же модель пересмотреть свой же код.

Решение: разделить роли между двумя независимыми моделями от разных компаний:

• Тимлид (Claude Opus): проектирование, документация, постановка чётких критериев приёмки, строгое ревью по фактам.
• Разработчик (GPT-4o, DeepSeek, Cursor): реализует задачу по заданию тимлида.

Ключ успеха: разные модели, обученные разными компаниями, обеспечивают по-настоящему независимый взгляд и исключают системные ошибки, характерные для одной архитектуры.

Цикл Loop Engineering: от спеки до верификации

Вместо наивного «написано — значит готово» работает структурированный цикл обратной связи:

1. Спецификация и критерии приёмки: тимлид пишет четкое описание задачи и перечисляет условия успеха.
2. Имплементация: разработчик (вторая модель) пишет код по заданию.
3. Ревью и тестирование: тимлид проверяет code diff, запускает тесты, сверяет результат с критериями приёмки.
4. Верификация и решение:
   • Если все критерии выполнены и тесты зелёные — работа принимается.
   • Если найдены ошибки — отправляется на доработку с конкретными замечаниями и список требуемых правок.
5. Повтор до успеха: цикл повторяется, пока все критерии не станут зелёными.

Роль человека: не делать ручное ревью, а нести окончательную ответственность за результат и определять критерии приёмки. Человек проверяет только финальный результат и бизнес-логику.

Практический пример: экспорт лидов в CSV

Задача: добавить кнопку экспорта лидов в CSV.

Критерии приёмки

• В интерфейсе видна кнопка экспорта.
• CSV-файл содержит нужные поля (имя, почта, телефон и т.д.).
• Пустой список обрабатывается без ошибок.
• Формат CSV валиден и открывается в Excel/Google Sheets.

Процесс выполнения

1. Claude (тимлид) получает промт с задачей и критериями.
2. Claude отправляет агента-кодера (Cursor / GPT) с командой реализовать функционал.
3. Разработчик работает до полного выполнения всех условий.
4. Claude проверяет результат: изучает diff, запускает тесты, ищет нарушения критериев.
5. Если тесты не проходят — отправляет список доработок с конкретными замечаниями.
6. Цикл повторяется до зелёных тестов.

Результат: полностью рабочий функционал с доказанным качеством (тесты), без ручного ревью человеком.

Почему тесты — единственный судья

Ключевая идея: тесты — это объективные факты, а не мнение модели. Пока функционал не подтверждён тестами, всё остальное — лишь гадание о работоспособности.

Юнит-тесты, end-to-end тесты, smoke-тесты дают измеримое доказательство выполнения задачи:

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

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

Как организовать проект для тандема

Для слаженной работы тандема нужны два основных инструмента:

1. claude.md (главный файл проекта)

• Описание проекта и его целей.
• Явное указание критериев приёмки для каждой задачи.
• Ключевой запрет: Claude не пишет код самостоятельно, а только планирует и ревьюит.
• Описание инструментов, dependencies и stack'а.

2. Skill-файл (например, cursor_teamlead.md)

• Пошаговое описание цикла Loop Engineering.
• Как делегировать задачи разработчику (второй модели).
• Как настраивать гейты приёмки (gate) в каждый go prompt.
• Техники проверки результата на предмет «AI slop» (мусора, галлюцинаций и низкокачественного кода).
• Шаблоны промтов и вспомогательные bash-скрипты для автоматизации.

Вся логика Loop Engineering живёт в skill-файле, что позволяет легко переиспользовать подход на других проектах.

Экономика тандема: окупается ли вторая подписка?

Использование двух платных моделей увеличивает расходы, но инвестиция часто себя оправдывает:

Практический пример: проект из ~100 000 строк кода реализован с DeepSeek (разработчик) и Cursor (тимлид) за менее $30 — это рентабельно для сложных систем.

Результаты на реальных проектах

Масштабный пример: 100 000 строк за <$30

• В большом бизнес-проекте использовался тандем DeepSeek (разработчик) + Cursor (тимлид).
• Написано более 100 000 строк производственного кода.
• Затраты на подписки: менее $30 на всю разработку.
• Все критерии приёмки выполнены, тесты зелёные, результат готов к боевой эксплуатации.

Оптимальное распределение ролей по моделям

• Claude (Anthropic): тимлид-задачи требующие глубокого анализа, строгого ревью и принятия решений, несмотря на лимиты контекста.
• Cursor / GPT / DeepSeek: ресурсоёмкие задачи по генерации кода, где важна экономия токенов и скорость.

Главный итог: такой подход позволяет получать качественный результат полностью автономно, с полной доказательной базой (тесты, артефакты, логи), что ускоряет разработку и повышает уверенность в коде без переплаты за человеческий ревью.