Внедрение в команде: пилот, правила, масштаб

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

Зачем пилот, если все и так пробуют

Стихийное использование даёт впечатления, но не данные. Разработчики искренне переоценивают собственное ускорение: в исследовании METR 2025 года участники ожидали ускорения на 24% и после работы считали, что ускорились на 20%, хотя измеренное время задач с ИИ выросло на 19% (METR). Сама METR позже пометила эти результаты как устаревшие — инструменты изменились, — но вывод о ненадёжности самооценок никуда не делся. Подробнее о цифрах — в уроке про метрики.

Пилот отвечает на три вопроса:

1. На каких задачах агент реально помогает именно в вашем стеке и репозиториях.
2. Какие правила нужны, чтобы качество не просело.
3. Сколько стоит проверка того, что сделал агент, — во времени ревьюеров и QA.

Как выбрать границы

Команда. Один проект, 3–6 человек, в том числе хотя бы один скептик и один тестировщик. Скептик найдёт слабые места быстрее энтузиастов, тестировщик увидит то, что не видно в диффе.

Проект. Живой, с CI и хоть какими-то тестами. На проекте без тестов вы будете измерять не агента, а отсутствие страховочной сетки.

Типы задач. Заранее выпишите 3–4 класса: например, баги с воспроизведением, мелкие фичи в админке на OctoberCMS, покрытие тестами, вёрстка по макету. Так результаты можно будет сравнить, а не пересказывать.

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

Базовая линия до старта

Без «до» не будет «после». Зафиксируйте за последние несколько недель по тому же проекту:

• время от взятия карточки в работу до мержа (по Kaiten и GitLab);
• средний размер MR и время до первого ревью;
• число возвратов из QA и багов после релиза;
• короткий опрос команды: что раздражает в процессе, где теряется время.

Это займёт час, а потом сэкономит недели споров.

Минимальные правила до первого MR

Правила пилота — не бюрократия, а то, что вы потом унесёте в масштаб.

Данные и доступ. Работаем через рабочее пространство компании, а не через личные аккаунты. Решение о том, какой код клиентов можно отправлять в модель и можно ли использовать облачные задачи, принимает техдир — см. «Данные и код клиентов». В Enterprise-пространствах облачный Codex по умолчанию выключен и включается администратором (admin setup).

Права агента. Для повседневной работы документация рекомендует песочницу workspace-write с одобрениями on-request: запись только в рабочий каталог, сеть по умолчанию выключена (approvals и безопасность). Полный доступ — только в изолированных окружениях. Подробно — в уроке «Песочница и одобрения».

Секреты. Никаких боевых ключей и паролей в рабочем каталоге и переменных окружения, которые видит агент.

Ревью. Каждый MR, сделанный с агентом, проходит обычное человеческое ревью. Автор сначала сам читает дифф и проверяет поведение — отдавать коллегам непроверенный код нельзя.

Прозрачность. Договоритесь, как отмечать участие агента в MR: метка, строка в описании. Это решение команды, OpenAI его не навязывает, но без пометки вы не соберёте статистику.

Чек-лист пилота

## До старта
- [ ] Цель пилота в одном предложении и 3–4 класса задач
- [ ] Участники, включая скептика и тестировщика
- [ ] Базовая линия: время до мержа, размер MR, возвраты из QA
- [ ] Решение техдира по данным клиента и облачным задачам
- [ ] Доступ через рабочее пространство, личные аккаунты не используем
- [ ] AGENTS.md в репозитории: команды сборки, тестов, линта, запреты
- [ ] Права по умолчанию: workspace-write + on-request

## Во время
- [ ] Метка «agent» на MR и карточках
- [ ] Короткий лог: задача, что получилось, где агент ошибся
- [ ] Повторяющаяся ошибка → правило в AGENTS.md через MR
- [ ] Еженедельная 30-минутная ретро

## После
- [ ] Сравнение с базовой линией по классам задач
- [ ] Опрос команды
- [ ] Список правил, которые переносим на все проекты
- [ ] Решение: масштабировать / доработать / остановить

Критерии перехода к масштабу

Масштабировать стоит, когда выполнены три условия. Есть хотя бы один класс задач, где результат стабильно хороший и проверка не дороже ручной работы. Правила сформулированы и лежат в репозитории, а не в памяти участников. Ревьюеры и QA не перегружены — если перегружены, сначала чините процесс ревью.

Масштабируйте по проектам, а не по людям: следующий проект получает готовый командный стандарт, а участник пилота на первые недели становится его проводником. Документация Codex советует похожую последовательность для автоматизации: не ставить задачу по расписанию, пока она не работает надёжно вручную (best practices). С людьми и процессами логика та же.

Если пилот не удался

Это тоже результат. Чаще всего причина не в модели, а в среде: агенту не сказали, как запускать тесты, задачи были расплывчатыми, проект без проверок. В документации есть формулировка, что многие проблемы качества на деле оказываются проблемами настройки. Разберите лог пилота: какие ошибки повторялись и какое правило, инструмент или тест их бы предотвратил.