Стратегия: где агенты дают эффект

Главная ошибка внедрения — считать, что агент ускоряет «разработку вообще». Он ускоряет одни классы задач, почти не влияет на другие и вредит третьим. Стратегия техдира — понять, какие задачи у вас каких классов, и вкладываться туда, где эффект подтверждается. В уроке — что говорят исследования, что говорит сама OpenAI и как разложить работу агентства на карту.

Что говорят данные

Сначала холодный душ. В рандомизированном исследовании METR (июль 2025) 16 опытных разработчиков решали 246 задач в своих же зрелых open source-репозиториях. С разрешённым ИИ задачи заняли на 19% больше времени, хотя до эксперимента участники ждали ускорения на 24%, а после него считали, что ускорились на 20% (METR, 2025). METR прямо оговаривает: это не доказательство, что ИИ замедляет большинство разработчиков.

В обновлении февраля 2026 года (57 разработчиков, более 800 задач) точечные оценки сдвинулись в сторону ускорения, но все доверительные интервалы включают ноль, а сами авторы называют данные очень слабым свидетельством из-за сильных эффектов отбора: часть участников отказывалась работать без ИИ (METR, 2026). Устойчивый вывод из обеих работ один: самоощущение ускорения ненадёжно.

Отчёт DORA 2025 (почти 5 000 респондентов) нашёл положительную связь использования ИИ с пропускной способностью, но отрицательную — со стабильностью поставки. Ключевая рамка отчёта: ИИ — усилитель того, что в команде уже есть (DORA 2025). Хорошие тесты, CI и ревью он усиливает. Их отсутствие — тоже.

Что говорит OpenAI о своём опыте

В гайде «How OpenAI uses Codex» перечислены семь сценариев внутри компании: понимание кода, рефакторинг и миграции, оптимизация производительности, покрытие тестами, скорость разработки, работа «в потоке» между встречами, исследование идей (PDF). Там же совет давать хорошо очерченные задачи «примерно на час» — но гайд написан ещё в период research preview, и размер задач с тех пор вырос.

Статья OpenAI о harness engineering описывает внутренний продукт, где за пять месяцев около миллиона строк написали агенты (OpenAI). Важна оговорка самих авторов: такое поведение агентов держится на структуре и инструментах конкретного репозитория и не переносится на другие проекты без сопоставимых вложений. Это greenfield, построенный под агентов с первого коммита, — не ориентир для клиентского легаси.

Карта задач агентства

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

Закономерность простая: эффект есть там, где «готово» можно проверить машиной — тестом, линтером, сборкой, скриншотом. Там, где «готово» решает человек по неявным критериям, агент производит правдоподобный черновик, а проверка съедает выигрыш. OpenAI в материалах про Symphony пишет о том же: неоднозначная работа, требующая суждения, остаётся интерактивной (OpenAI).

Где агент вредит

• Проекты без тестов и без воспроизводимого окружения. Агент не может проверить себя, и проверка целиком ложится на ревьюера.
• Код, который никто в команде не понимает. Агент воспроизводит существующие шаблоны, включая плохие, — это наблюдение команды OpenAI о дрейфе кода.
• Задачи с доступом к боевым данным и секретам клиента. Риск утечки растёт быстрее, чем выигрыш во времени (подробнее — в уроке про модель безопасности).
• Оценка сроков «с учётом агента» до пилота. Обещать клиенту ускорение, которое вы не измерили, — прямой путь к сорванным срокам.

Стратегия внедрения

Рабочая последовательность для агентства:

1. Выберите два-три класса задач с высоким ожидаемым эффектом и проверяемым результатом. Обычно это тесты, разбор чужого кода и миграции.
2. Выберите проекты, где договор с клиентом и характер данных позволяют работать с агентом (см. урок про данные).
3. Подготовьте среду: AGENTS.md с командами сборки и тестов, рабочий локальный запуск, CI. Документация OpenAI прямо говорит, что многие проблемы качества на деле проблемы настройки (best practices).
4. Зафиксируйте базовую линию метрик до пилота — иначе вы будете сравнивать с ощущениями (см. урок про эффект).
5. Масштабируйте по классам задач, а не по людям. Сначала «все пишут тесты с агентом», потом следующий класс.

Тимлидская часть этой работы — пилот в команде, правила, стандарты — разобрана в курсе «Codex для тимлидов». Ваша часть — выбор классов задач, проектов и рамок риска.