Asana перетворила міграцію, яку оцінювали щонайменше у п’ять років і приблизно $6 млн роботи, на двотижневий проєкт із витратами близько $12 000. Для цього команда запустила до чотирьох агентів Codex паралельно. Але головний урок кейсу — не «ШІ зробив усе сам»: інженер двічі на день перевіряв прогрес і переглядав кожну запропоновану зміну.
Розбираємо, чому саме ця задача підійшла агентам, як був організований процес і що можна безпечно повторити у власній команді.
Який технічний борг накопичився в Asana
Команда Asana мала стару систему тестування на Enzyme. Інструмент роками використовували для React-компонентів, але з часом він перетворився на перешкоду для оновлень і спрощення кодової бази. Потрібно було переписати велику кількість тестів та прибрати застарілу залежність.
Раніше компанія оцінювала таку роботу щонайменше у п’ять років інженерного часу. Орієнтовна вартість персоналу могла сягнути $6 млн. Ці цифри не означають, що один розробник мав п’ять років безперервно змінювати тести. Вони показують сумарний обсяг дрібної, повторюваної роботи, яку важко пріоритизувати поруч із новими функціями.
Технічний борг часто живе саме так: кожна окрема зміна здається не терміновою, але вся система поступово ускладнює релізи, оновлення бібліотек і роботу нових співробітників.
Що зробила команда з Codex
Інженер Asana описав завдання промптом із п’яти речень. Потім запустив до чотирьох агентів Codex у паралельних копіях кодової бази. Кожен агент отримував окрему частину міграції, вносив зміни й перевіряв тести.
Проєкт зайняв близько півтора тижня безпосередньої інженерної роботи та два календарні тижні. Модель і необхідна інфраструктура коштували близько $12 000. За даними OpenAI, це приблизно у 500 разів менше за попередню кадрову оцінку.
Втім, порівнювати $12 000 і $6 млн як два гарантовані прайси не можна. $6 млн були оцінкою традиційного сценарію, а $12 000 — фактичними витратами конкретного експерименту з певною кодовою базою, тестами та інженером, який добре розумів систему.
Як виглядав паралельний процес
- Задачу звузили до чіткої міграції. Визначення готовності було простим: Enzyme прибрано, тести переписано, набір перевірок проходить.
- Код поділили на незалежні частини. Агенти працювали у різних копіях, тому не перезаписували зміни одне одного.
- Дали короткі інструкції. За словами команди, прості настанови працювали краще за складну систему правил.
- Прогрес перевіряли двічі на день. Інженер помічав зациклення, невдалий напрямок або конфлікт із практиками репозиторію.
- Кожну зміну переглянула людина. Результат не потрапляв у код лише тому, що тести стали зеленими.
Цей підхід схожий не на одного надзвичайно швидкого програміста, а на маленьку команду виконавців із досвідченим технічним керівником. Докладніше про керування кількома агентами ми писали в матеріалі OpenAI Codex — єдиний робочий простір для ШІ-агентів.
Чому ця задача добре підійшла ШІ-агентам
Міграція Enzyme мала чотири властивості, які важливі для агентної автоматизації.
- Робота була повторюваною. Багато тестів потрібно було перетворити за схожою логікою.
- Результат можна перевірити. Тести, збірка й пошук залишкових імпортів давали об’єктивний сигнал.
- Задачу легко ділити. Окремі набори файлів могли обробляти різні агенти.
- Існувало чітке завершення. Старої залежності більше немає, а поведінка збережена.
Натомість нечітка задача на кшталт «зробіть архітектуру кращою» не має однозначного тесту й створює забагато рішень зі складними наслідками. Там паралельність може лише швидше розмножити суперечливі зміни.
Як повторити підхід у своїй команді
1. Виберіть обмежений борг
Почніть із оновлення API, перейменування, міграції тестів, заміни застарілого шаблону або додавання типів. Не починайте з ядра платежів чи повного перепроєктування продукту.
2. Запишіть визначення готовності
Складіть короткий список: які залежності мають зникнути, які тести пройти, які файли не можна змінювати та які метрики не повинні погіршитися.
3. Підготуйте автоматичні перевірки
Агенту потрібен швидкий зворотний зв’язок: юніт-тести, лінтер, перевірка типів, збірка й пошук заборонених імпортів. Якщо тести нестабільні, спочатку виправте їх.
4. Розділіть роботу без перетинів
Кожному агенту дайте окремий пакет, директорію або групу тестів. Використовуйте окремі гілки чи робочі копії. Межі відповідальності мають бути очевидними.
5. Встановіть ритм перевірки
Не чекайте кінця тижня. Переглядайте проміжні pull request, витрати, помилки й повторювані проблеми щонайменше раз або двічі на день.
6. Зливайте невеликими порціями
Маленьку зміну легше перевірити, відкотити й порівняти з попередньою поведінкою. Великий фінальний pull request нівелює більшу частину переваг паралельної роботи.
Який промпт дати агенту для пілота
Промпт не повинен бути довгим регламентом, але має зафіксувати межі й перевірки. Для першого проходу підійде така структура:
Мета: заміни застарілий API у директорії packages/example.
Не змінюй публічну поведінку й файли поза цією директорією.
Після кожної групи змін запусти тести, лінтер і перевірку типів.
Якщо тест падає з невідомої причини, зупинися й опиши проблему.
Підготуй невеликий окремий commit із переліком змінених файлів.Важливо не копіювати цей текст механічно. Команда має додати власні команди тестування, заборонені зони та критерії приймання. Ще краще — дати один приклад уже виконаної вручну міграції, щоб агент бачив очікуваний стиль.
Пілот завершується не тоді, коли агент створив багато коду, а коли інженер підтвердив: поведінка збережена, зміни зрозумілі, витрати виміряні, а процес можна повторити.
Як оцінити бюджет до запуску
Вартість кейсу Asana не є тарифом Codex. OpenAI не розкрила точну конфігурацію моделі, кількість токенів і вартість внутрішньої інфраструктури. Тому планувати «наша міграція теж коштуватиме $12 000» небезпечно.
Краще провести пілот на 1–5% репозиторію та виміряти:
| Показник | Що рахувати |
|---|---|
| Витрати моделі | Кредити або токени на одну прийняту зміну |
| Час інженера | Постановка задачі, review, виправлення й злиття |
| Частка прийнятих змін | Скільки патчів проходять перевірку без повного переписування |
| Регресії | Помилки після злиття та час на їх виправлення |
| Швидкість | Кількість якісно мігрованих файлів за день |
Після пілота екстраполюйте не лише токени, а й людський контроль. Для огляду сучасних моделей, які можуть стояти за різними робочими режимами, дивіться наш матеріал про GPT‑5.6 Sol, Terra і Luna.
Де паралельні агенти створюють ризик
Найбільша загроза — конфлікти, які не видно в одному pull request. Два агенти можуть окремо зробити правильні зміни, але разом порушити контракт між модулями. Інший ризик — тести перевіряють стару реалізацію, а не потрібну поведінку, тому «зелений» результат закріплює помилку.
Не варто віддавати агентам без щільного контролю зміни в авторизації, платежах, криптографії, міграціях даних або публічних API. Там потрібні окремий план відкату, поетапний реліз, моніторинг і профільний review.
Також важливо захистити секрети й виробничі дані. Якщо команда працює з API, корисно розрізняти звичайне вимкнення зберігання та корпоративні режими захисту — ми пояснили це у статті про Zero Data Retention OpenAI.
Головний урок кейсу Asana
Результат став можливим не лише завдяки моделі. Asana поєднала вузьку повторювану задачу, надійні тести, паралельні ізольовані середовища й досвідченого інженера, який контролював рішення. Без будь-якого з цих елементів цифри могли бути зовсім іншими.
Починайте не з кількості агентів, а з якості перевірки. Якщо команда може чітко описати готовий результат і швидко побачити помилку, Codex здатен суттєво скоротити рутинну міграцію. Якщо критерії розмиті, агенти лише прискорять накопичення нового технічного боргу.
Офіційні джерела
- OpenAI: Asana clears a five-year engineering backlog with Codex
- OpenAI: актуальна тарифна сітка Codex
