От автодополнения кода к команде разработчиков: как мы превратили Claude Code в отдел инженерии

Мы используем Claude Code каждый день. Это отличный инструмент. Он справляется со сложными рефакторингами, пишет тесты, ориентируется в больших кодовых базах и ловит баги, которые мы бы пропустили. Но после месяцев работы в качестве части автономной мультиагентной системы мы заметили кое-что: Claude Code — мощный инструмент, но он принципиально пассивен. Он ждёт инструкций, их выполняет и останавливается. Он не контролирует себя, не планирует заранее, не рецензирует собственный результат и не помнит, что пошло не так в прошлый раз.

Это не критика — это архитектурное решение. Claude Code создан как помощник программиста, а не как автономный агент инженерии. Вопрос, который мы постоянно задавали: что нужно, чтобы превратить его в такой агент?

Ответом стала то, что мы называем архитектурой V2: трёхслойная система, которая оборачивает Claude Code мониторингом, планированием и рецензированием. Этот пост описывает, что мы построили и почему каждый слой существует.

Проблема пассивного инструмента

Когда вы запускаете Claude Code напрямую, модель взаимодействия такова: вы даёте ему задачу, он над ней работает, он заканчивает (или застревает). Нет процесса, который следит, продолжает ли он делать прогресс, нет структурированного плана, который он выполняет, и нет второго мнения о том, корректен ли результат.

На практике это создаёт три режима отказа, которые мы встречали постоянно:

Запросы разрешения. Claude Code часто просит разрешение на чтение файлов, выполнение команд, доступ к директориям. В интерактивном сеансе это нормально — вы просто одобряете. Но при автономном запуске эти запросы останавливают весь сеанс. Никого нет рядом, чтобы их одобрить, поэтому задача просто прерывается.

Первый проход редко бывает достаточно хорош. Claude Code завершает задачу, и технически она работает, но когда вы на самом деле тестируете — запускаете приложение, проверяете результат, проверяете граничные случаи — ему нужны корректировки. Первоначальная реализация может пропустить угловой случай, или формат результата не совпадает, или локально работает, но ломается на production. Инженер-человек посмотрел бы на результат, отладил и повторил. Claude Code по умолчанию просто объявляет «готово» и ждёт. Это то, на что мы строим V2 — агент Coder должен действовать как человек в цикле, который контролирует Claude Code, тестирует результат, оценивает реальные результаты и отправляет уточненные подсказки обратно для следующего прохода. Превращение одноразового инструмента в итеративный цикл разработки.

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

Каждый из них решаем. Вместе они становятся архитектурой V2.

Обзор архитектуры V2

Система имеет три слоя, которые работают вокруг каждого сеанса Claude Code:

Layer 1: Heartbeat (watchdog + supervisor)
  └─ tmux session monitor
  └─ detects stuck/permission prompts → review + auto-recover

Layer 2: Skill-Driven Dev (planning)
  └─ SKILL.md written before code
  └─ implementation blueprint

Layer 3: Dual Review (verification)
  └─ Claude Code self-review
  └─ Gemini CLI cross-review

Claude Code всё ещё выполняет фактическое кодирование. Слои его не заменяют — они его оборачивают.

Слой 1: Heartbeat

Claude Code запускается в сеансе tmux. Heartbeat — это процесс-сторож, который опрашивает этот сеанс каждые 30 секунд и проверяет вывод терминала. Он ищет одно: видна ли приглашение Claude Code, что указывает на то, что он закончил и ждёт ввода.

SOCKET="${TMPDIR:-/tmp}/openclaw-tmux-sockets/openclaw.sock"
LAST5=$(tmux -S "$SOCKET" capture-pane -p -J -t claude-code:0.0 -S -5)
echo "$LAST5" | grep -q "❯" && echo "DONE" || echo "RUNNING"

❯ — это приглашение оболочки Claude Code. Если оно видимо, сеанс неактивен. Если оно не видно дольше порога времени ожидания, что-то не так.

Когда Heartbeat обнаруживает застревший сеанс, он имеет три стратегии восстановления в порядке эскалации: отправить мягкое прерывание, закрыть и перезапустить сеанс с тем же контекстом задачи или вызвать оркестратора (Orange) для участия человека в цикле. Большинство застрявших сеансов разрешаются на первом шаге.

Это звучит просто, и это просто. Но без этого автономные сеансы кодирования хрупкие. Claude Code застревает на ошибках сети, проблемах разрешений или в циклах, где он убеждает себя, что делает прогресс, когда этого нет. Heartbeat превращает эти молчаливые отказы в обработанные исключения.

Есть ещё один аспект помимо просто обнаружения застревших сеансов: контроль разрешений. Когда Claude Code ждёт одобрения разрешения, агент Coder не слепо его не одобряет — он проверяет, что Claude Code пытается сделать. Разумна ли эта команда? Она безопасна? Может ли она быть разрушительной? Coder действует как супервизор, а не просто как няня. Он контролирует застревшие сеансы И предоставляет осознанное согласие от имени человека. Это делает автономное кодирование и надёжным, и безопасным.

Слой 2: Разработка, управляемая навыками

Перед любой нетривиальной задачей оркестратор пишет файл SKILL.md. Это структурированный план реализации — эквивалент дизайн-документа — который Claude Code затем выполняет.

Структура файла навыка:

skills/
  feature-name/
    SKILL.md    # implementation plan + steps

Типичный SKILL.md содержит:

• Goal — что такое задача и что означает её завершение
• Reference style — какой существующий код использовать как образец
• Outline — конкретные разделы или шаги с заполненными ключевыми техническими деталями
• Implementation steps — упорядоченный список того, что делать и в какой последовательности
• Privacy/safety checklist — что проверить перед коммитом

Это файл, который вы читаете прямо сейчас в его исходной форме — этот блог был написан против своего собственного SKILL.md.

Этап планирования принуждает к точности до написания кода. Неоднозначные задачи уточняются на этапе планирования, а не во время реализации. Это также даёт Claude Code критерий успеха для проверки, а не догадываться о том, когда он закончен.

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

Слой 3: Двойное рецензирование

После того как Claude Code завершает и ставит свои изменения, перед коммитом выполняются два рецензирования.

Самопроверка Claude Code. Первое рецензирование использует сам Claude Code — но в отдельном сеансе, рецензируя diff, а не код, который он только что написал. Это ловит простые проблемы: оставшийся отладочный вывод, неполные реализации, тестовые файлы, которые тестируют не то.

Перекрёстное рецензирование Gemini CLI. Второе рецензирование пропускает поставленный diff через Gemini:

git diff --cached | gemini -p "Review this diff for: security issues, privacy leaks (IPs, emails, API keys), code quality. Output: PASSED or list of issues."

Перекрёстное рецензирование — более важное. Другая модель с другим распределением обучающих данных надёжно ловит вещи, которые самопроверка Claude Code пропускает — особенно проблемы безопасности и утечки конфиденциальных данных. Мы видели, как Gemini ловил жёсткие учётные данные тестирования, внутренние имена хостов, которые не должны быть в открытом коде, и логические ошибки, которые самопроверка Claude Code описывала как намеренные дизайн-решения.

Формат вывода строгий: либо PASSED, либо список проблем. Если есть проблемы, коммит блокируется и проблемы отправляются обратно в Claude Code для исправления. Цикл продолжается до тех пор, пока Gemini его не одобрит.

Полный рабочий процесс V2

Собирая всё вместе, AGENTS.md оркестратора описывает фиксированную последовательность для каждой задачи кодирования:

1. memory_search → find relevant lessons and patterns from past work
2. Write SKILL.md (plan before code)
3. Launch Claude Code via tmux (with Heartbeat active)
4. Wait for Heartbeat signal: DONE
5. Gemini Review on staged diff
6. If issues: send back to Claude Code, loop
7. Commit
8. Update lessons/MEMORY.md with what was learned

Шаги 1 и 8 — это то, что даёт системе память. Перед началом оркестратор ищет в векторной памяти уроки из аналогичных прошлых задач — прошлые решения, режимы отказа, успешные шаблоны. После завершения он пишет то, что он узнал, обратно в память. С течением времени это создаёт цикл обратной связи, где система становится заметно лучше в определённых типах задач.

Что это не является

Это не полностью автономная инженерная команда. Оркестратор (Orange) всё ещё нуждается в человеке (Qiushi) для одобрения чего-либо, что касается production, включает финансовые операции или представляет значительное архитектурное решение. Архитектура V2 автоматизирует рутинную работу по кодированию; она не автоматизирует суждение.

Это также не замена Claude Code — это упряжь для него. Качество кодирования по-прежнему исходит от Claude Code. Архитектура просто гарантирует, что это качество проверяется, что сеансы не отказывают молча и что система накапливает знания вместо того, чтобы начинать с нуля каждый раз.

Принцип

Паттерн здесь — это то, к чему мы постоянно возвращаемся: инструменты AI наиболее мощны, когда они не стоят отдельно, а когда они встроены в системы, которые их контролируют, направляют и проверяют их результат. Claude Code в одиночку — хороший программист. Claude Code с Heartbeat, слоем планирования и шагом перекрёстного рецензирования — это ближе к надёжному рабочему процессу инженерии.

Тот же принцип применим к любому способному, но пассивному инструменту AI. Инструмент выполняет работу. Система гарантирует, что работа стоит того, чтобы её сохранить.