Roo Code был кодовым агентом для VS Code, но официальная документация сообщает о закрытии расширения в мае 2026 года. Поэтому будущий пилот начинается с проверки архивной версии и ответственного за её поддержку, затем команда оценивает режимы, запросы разрешения, diff, тесты и доступ к файлам на отдельной ветке. Результат такой проверки пока остаётся открытым.
Статус расширения
Roo Code был расширением для VS Code с режимами работы и инструментами чтения, правки и запуска команд. Официальная документация сообщает о закрытии расширения в мае 2026 года; будущий пилот возможен лишь после решения команды о поддержке архивной версии.
Запрос «roo code» сегодня начинается с проверки состояния проекта. Официальная страница документации прямо сообщает о закрытии расширения, а репозиторий разработчика помечен как архивный и доступен для чтения. Соседние страницы сохраняют старые инструкции по установке. Ориентиром для статуса служит сообщение о закрытии проекта. Поэтому предложение команде звучит условно: изучить уже выбранную архивную версию в изолированной среде, определить владельца её поддержки и лишь затем решать вопрос о применении.
Сценарий статьи — конкретный агентный проход по отдельной ветке репозитория. Разработчик задаёт задачу, смотрит запросы к инструментам, сверяет изменения файлов и запускает собственные проверки. Общий маршрут ИИ-агента в разработке раскрывает роли репозитория и ревью. Здесь внимание на исторических механизмах Roo Code и на критериях решения о пилоте. Страница про Cline описывает другой продукт. Результат проверки Cline нельзя переносить на Roo Code из-за различий между проектами.
Нужен предварительный критерий остановки: команда прекращает подготовку пилота, если отсутствуют допустимый экземпляр расширения, безопасный источник модели, владелец поддержки либо разрешение на использование кода проекта. Такой вывод полезнее демонстрации красивого диффа без будущего сопровождения. В статье ниже шаги остаются проектной схемой: выполненного испытания и подтверждённых результатов здесь нет.
Границы доступа
В документации режимов Roo Code описаны Ask, Architect, Code и другие роли. Ask предназначен для чтения и вопросов, Code получает группы инструментов чтения, редактирования и команд. Для пилота удобно сначала запросить объяснение участка кода в режиме чтения, а затем перейти к правке только после согласования задачи. Режим разграничивает инструменты внутри расширения. Права операционной системы и правила репозитория действуют отдельно.
Описание инструментов показывает запрос разрешения перед применением средства чтения, правки или запуска команды. В настройках есть автоматическое одобрение отдельных категорий действий; официальное предупреждение связывает его с риском потери данных и нежелательных команд. В предложенном пилоте автоматическое одобрение оставляют выключенным. Разработчик сверяет путь файла, параметры команды и ожидаемый результат каждого запроса.
| Контур | Разрешение для пилота | Кто проверяет |
|---|---|---|
| Файлы проекта | Только рабочая копия без секретов | Владелец репозитория |
| Правка кода | Отдельная ветка и просмотр диффа | Разработчик и ревьюер |
| Команды | Явное одобрение безопасных проверок | Разработчик |
| Внешние инструменты | Отключены до отдельного решения | Ответственный за доступ |
Файл .rooignore по официальному описанию ограничивает доступ части инструментов к путям внутри рабочего пространства. Для системной изоляции нужно отдельное окружение; обработка команд охватывает лишь известные варианты. Поэтому рабочую копию отделяют от секретов и производственных ресурсов на уровне окружения. Серверные права на внешние сервисы и подтверждения действий проверяются на стороне этих сервисов. Текст запроса к модели служит только указанием для агента.
Пробная задача
Для будущего пилота подойдёт небольшая реальная правка с понятным критерием: например, добавить проверку уже существующего правила в модуле без доступа к клиентским данным. Тимлид выбирает отдельную ветку, фиксирует исходное состояние и выдаёт агенту только нужные файлы. В описании задачи перечислены допустимые изменения, связанный тест и запрет на побочные правки. Речь о плане будущего пилота. Фактические результаты появятся только после проверки.
- Проверьте архивную версию расширения, её происхождение, совместимость с редактором и владельца сопровождения.
- Подготовьте отдельную ветку и рабочую копию с разрешённым набором файлов и без секретов.
- Попросите Roo Code объяснить участок кода в режиме чтения и покажите человеку план правки.
- Разрешайте запросы к инструментам по отдельности; просматривайте путь, команду и предполагаемые изменения.
- После правки сверьте Git diff, запустите согласованные тесты и передайте результат на ревью.
Модель может предложить гипотезу о причине ошибки и объяснить выбранный участок. Проверку формул, полных выгрузок и точного поведения программы отдавайте тестам, парсеру или скрипту. Человек сравнивает результат с задачей и исходным кодом. Если агент изменил файл вне оговорённого участка, разработчик останавливает проход и разбирает причину. Прохождение теста служит одним из признаков. Слияние ветки требует отдельного ревью.
Для испытания нужны фиксируемые вход и выход: формулировка задачи, выбранный режим, запросы к инструментам, итоговый дифф и результат проверок. Запись позволяет отличить ошибку модели от неверной постановки и от проблемы архивного расширения. При невозможности повторить сценарий команда откладывает дальнейшее использование и документирует блокер.
Дифф и тесты
Ревью начинается с обычного Git diff отдельной ветки. Разработчик проверяет список файлов, изменения интерфейсов, обработку ошибок и наличие посторонних правок. Документация Roo Code о checkpoints описывает просмотр различий и восстановление состояния в отдельном теневом Git-хранилище. Этот механизм полезен как локальная возможность исторического расширения; официальный ревью-процесс команды всё равно опирается на ветку, тесты и решение ответственного человека.
Набор проверок задают до запроса к агенту. Подходят существующие тесты затронутого модуля, статический анализ и ручной проход по граничному случаю. При падении теста модель может объяснить сообщение и предложить исправление, а разработчик сверяет гипотезу с кодом. Команду запуска теста согласуют явно: инструмент исполнения способен выполнять произвольные операции в пределах предоставленного окружения. Упоминание «тесты пройдены» в ответе агента требует подтверждения выводом реального запуска.
Отдельно оцените доступ к файлам. Просмотрите, какие пути агент пытался читать и менять, соблюдал ли выбранный режим и как реагировал на отказ. При запросе к секретам или чужому каталогу пилот останавливают и исправляют границу окружения. Файл исключений помогает уменьшить поверхность доступа, но проверка команды и серверные разрешения остаются необходимыми. Для общей методики подойдёт разбор прав ИИ-агентов.
Если команда обсуждает применение кодового агента к своему процессу, критерии доступа и ревью можно разобрать в рамках консультации по внедрению ИИ. Стоимость такой работы обсуждают после оценки репозитория и требований к контролю. Сначала нужен ясный ответ, кто поддерживает архивное расширение и кто принимает итоговый дифф.
Хотите оценить безопасность пилота кодового агента?
Решение команды
Предлагаемая приёмка пилота состоит из проверки задачи и проверки инструмента. Для задачи нужны корректный дифф, подтверждённые тесты и понятное объяснение исправления. Для инструмента нужны соблюдение границ файлов, управляемое одобрение команд, воспроизводимость прохода и понятный путь поддержки. Закрытый статус Roo Code — отдельный критерий: даже при удачной правке пригодность архивной версии для постоянного процесса требует отдельного решения о поддержке.
Результаты будущего испытания фиксируйте как наблюдения, без заранее заявленного ускорения или снижения затрат. Укажите, какие запросы к инструментам потребовали вмешательства, какие файлы изменились, где возникли ошибки и смог ли ревьюер объяснить итоговую правку. Если проверка версии или сопровождения провалена, оформите решение об отказе от пилота либо о его ограничении исследовательской средой. Решение принимает команда по своей политике; ответ агента служит материалом для разбора.
Сравнение с Cline уместно только после отдельной проверки Cline по той же задаче и правилам доступа. Историческое родство проектов оставляет открытыми вопросы о режимах, разрешениях и качестве диффа. В этой статье критерии относятся именно к Roo Code и его архивной документации. Для более широкого разговора о ревью задач кодового агента полезен материал о сценариях тестирования ИИ-агентов.
Сначала подтвердите статус и происхождение выбранной версии Roo Code. Затем назначьте владельца поддержки и подготовьте ограниченную ветку с проверяемой задачей.
Если эти условия выполнены, команда получает основание провести будущий изолированный пилот. Если поддержка архивной версии остаётся без владельца, разумно закрыть вопрос до доступа к рабочему коду. Такой порядок сохраняет главное: человек утверждает инструменты, читает дифф и принимает результат после проверки.