Кейс Asana: управляемая работа ИИ-исполнителей

Кейс Asana: четыре параллельных ИИ-исполнителя, отдельные копии кода, проверка инженером, стоимость и выводы для автоматизации бизнеса.

Asana сообщила, что с помощью инструмента OpenAI удалила из большого проекта устаревшую систему тестирования Enzyme. Раньше компания оценивала такую миграцию минимум в пять лет и примерно в 6 миллионов долларов расходов на команду. Фактическая работа заняла две календарные недели, а модели и инфраструктура стоили около 12 тысяч долларов.

Цифры впечатляют, но полезный вывод находится не в сравнении «пять лет против двух недель». Это клиентский кейс Asana и OpenAI, а не независимый аудит. Он показывает условия, при которых параллельные агенты могут ускорить большую, но хорошо проверяемую задачу.

Что именно делали агенты

Enzyme мешала Asana обновлять фронтенд. Миграция требовала изменить множество тестов и убедиться, что новое состояние не ломает продукт.

Процесс был устроен так:

1. до четырёх ИИ-исполнителей работали параллельно; 2. каждый агент получал отдельную копию кодовой базы; 3. стартовая инструкция занимала всего несколько предложений; 4. инженер проверял прогресс дважды в день; 5. каждое предложенное изменение проходило человеческий просмотр; 6. итог подтверждался тестами, которые можно повторить.

Инженер потратил около полутора рабочих недель в пределах двух календарных. То есть человек не исчез из процесса: он ставил рамки, проверял изменения и отвечал за объединение результата.

Почему этот случай подходит для автоматизации

У задачи было четыре важных свойства.

Результат можно проверить

Устаревшая зависимость либо удалена, либо остаётся в коде. Тесты либо проходят, либо показывают конкретную ошибку. Агенту не нужно самостоятельно решать, что считать хорошим бизнес-результатом.

Изменения можно изолировать

Отдельная копия кода не позволяет одному агенту молча перезаписать работу другого. Инженер видит каждый набор изменений до объединения.

Ошибку можно откатить

Код хранится в системе контроля версий. Неудачная попытка не должна сразу попадать пользователям или менять производственные данные.

Задачу можно разделить

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

Что бизнес может взять из кейса

Похожий подход применим не только к коду. Он полезен для задач, где есть большой однотипный хвост и чёткая проверка результата:

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

Для каждого сценария нужны тестовая копия, ограниченные права, журнал и человек, который принимает итог. Если агент сразу работает в производственной базе и может необратимо менять данные, схема Asana уже не воспроизводится.

Где сравнение кейса вводит в заблуждение

Нельзя переносить соотношение сроков и стоимости на любую компанию. Предыдущая пятилетняя оценка была внутренним планом Asana, а 12 тысяч долларов учитывают модель и инфраструктуру, но не равны полной стоимости всей инженерной организации.

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

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

Как запустить узкий пилот

Выберите один накопившийся процесс и опишите:

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

Сначала прогоните небольшой набор и сравните результат с ручной работой. Только после этого увеличивайте объём или число параллельных агентов.

Для проектирования такого контура подходят AI-системы для бизнеса. Если сначала нужно доказать сам продуктовый сценарий, разумнее начать с MVP, а не строить большую инфраструктуру заранее.

Источник и ограничения

OpenAI: кейс двухнедельной миграции Asana, 18 августа 2026 года. Сроки, оценки стоимости и устройство процесса приведены по совместному клиентскому кейсу OpenAI и Asana. Публикация не является независимым аудитом и не обещает повторение результата в другом проекте.