Roo Code компании стоит проверять на разделении планирования и выполнения

Что команда собирается использовать? На 7 октября 2026 README официального репозитория сообщает о закрытии Roo Code. roocode.com ведёт на Roomote.

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

Инструкция по старой версии не подтверждает совместимость вашей установки. Права и доступ к API проверяют в том инструменте, который будет работать.

Здесь разбираем режимы по официальной документации. Прогон на вашем проекте ещё предстоит сделать; измеренного эффекта от Roo Code мы не обещаем.

Режимы задают инструкции и набор инструментов. Architect читает проект и редактирует markdown-файлы, а Code может менять код и выполнять команды.

Настройка Kilo Code требует согласовать модель, расходы и права агента.

Например, Architect записывает план в документ до начала правок программы. CTO получает возможность отклонить решение раньше выполнения.

Имя режима не создаёт сотрудника с отдельной ответственностью. Пользовательская конфигурация меняет права, MCP даёт доступ к подключённым инструментам.

Проверьте фактические полномочия установки. Правила для ИИ-агентов задают границы проекта; переключатель режима должен их исполнять.

Оценка агента Cline включает доступные действия, выбранную модель и принятые изменения.

Что сдаёт планирующий режим? Объяснение изменения, которое CTO может проверить до исполнения. Список «изучить, исправить, протестировать» этого не даёт.

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

Возьмём письма подписки. В нашей машине ревью 17 июля 2026 нашло, что повторная отправка формы создавала ещё одно письмо. Первой отправки было недостаточно.

Для такого прогона план должен назвать поведение при повторном нажатии. Если записано только «письмо приходит», исполнитель может сохранить поломку.

Orchestrator раздаёт подзадачи, но не пересылает всю историю автоматически. По документации Boomerang Tasks подзадача получает свою историю и начальную инструкцию.

Передайте согласованный план вместе с критерием. Для письма это включает повторное нажатие. Просьба «реализовать план» без самого плана заставляет угадывать.

Родитель после завершения получает итог подзадачи. Собственная история помогает разделить работу, но итог остаётся сообщением исполнителя.

Обратный переход тоже проверяют. «Готово, проверки зелёные» не заменяет diff и воспроизводимые результаты. Иначе руководитель принимает пересказ.

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

Тесты показывают поведение на заложенных сценариях. Если повторное нажатие не проверили, зелёный результат не отвечает на этот вопрос.

Проверка, откат и права определяют цену ошибки. Здесь проверяем, заметили ли её до выпуска и что дополнили в следующей задаче.

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

Как оценить цену дополнительных этапов? Сравните с текущим порядком на сопоставимых задачах: время до принятого результата, возвраты, время руководителя.

Для письма запишите результат первого и повторного действия. После прогона сохраните план, diff и проверки. Получилась ли сдача без ручной починки?

Не меняйте сразу инструмент, модель, доступ и критерий. Если CTO дольше объясняет контекст и чаще чинит сдачу, переключатель не решил проблему.

Причины, почему ИИ не ускорил разработку, разобраны отдельно. Решение о вашем процессе должно опираться на результат вашего прогона.

Кто поддержит порядок после прогона? На vibecoding.ru инженер ведёт машину агентов: задаёт правила и принимает результат. На /open#operator эта роль показана отдельно.

Принцип разбираем в курсе агентной разработки: «Codex, Claude Code, Cursor», «Типы агентов», «Как читать бенчмарк». Это опыт нашей машины и обучения.

Если работу нужно передать инженеру, на странице подписки есть «Все проекты» с тремя потоками. В каждом в работе одна задача.

1. Проверьте поддержку выбранной установки. Оригинальный Roo Code закрыт, форк и новый продукт оценивают отдельно.
2. Примите план до правок. Нужны результат, границы и сценарий проверки.
3. Передайте план и критерий исполнителю, получите diff и следы проверок.
4. Проверьте задачу отдельным запуском. Из найденной ошибки добавьте критерий следующего прогона.
5. Сравните принятые задачи, возвраты и время руководителя. По этим данным решайте, оставлять ли разделение этапов.