Asana прибрала технічний борг за два тижні

Що саме зробила Asana

У кейсі йдеться не про дрібне автодоповнення коду, а про повне видалення Enzyme, застарілої тестової системи. Вона вже не була в активній підтримці й заважала модернізувати frontend-стек Asana. Саме такі залежності часто стають технічним боргом: бізнес бачить, що систему треба оновити, але команда відкладає роботу, бо вона надто велика для звичайного плану.

Попередній план Asana оцінювала щонайменше у п'ять років і приблизно $6 млн staffing-витрат. Після експерименту з Codex робота зайняла 1,5 тижня інженерного часу в межах двох календарних тижнів. Модельні та інфраструктурні витрати склали близько $12 тис.

Для керівника висновок простий: AI-агенти варто розглядати не лише як помічників для нових функцій, а як інструмент для розблокування відкладених змін у кодовій базі. У матеріалі прямо названі наступні напрями, які Asana тепер може перевіряти: інші міграції, переписування частин системи та проблеми продуктивності, які раніше здавалися проєктами на роки.

Як був організований процес

Codex не працював самостійно у продакшені. Команда дала коротке завдання з п'яти речень. До чотирьох coding agents працювали паралельно, кожен в окремій копії кодової бази. Інженер двічі на день перевіряв прогрес і переглядав кожну запропоновану зміну перед погодженням.

Це важлива деталь для бізнесу: економія виникла не через відмову від контролю, а через інший розподіл роботи. Агентам віддали масову, повторювану частину міграції. Людина залишила за собою перевірку, рішення й відповідальність за прийняття змін.

• Сформулювати завдання коротко: що треба видалити або змінити, який результат вважається завершеним.
• Запускати кілька агентів паралельно лише в окремих копіях кодової бази.
• Перевіряти прогрес регулярно, а не чекати фінального великого результату.
• Рев'ювати кожну запропоновану зміну перед прийняттям.
• Порівнювати фактичні витрати на моделі й інфраструктуру з попереднім staffing-планом.

Приклад формулювання для подібного завдання: Приберіть застарілу тестову систему з кодової бази. Працюйте в окремій копії. Запропонуйте зміни частинами. Не вважайте зміну завершеною без рев'ю інженера. Мета: повне видалення блокера для модернізації frontend-стеку.

Де це може спрацювати ще

Перший тип задачі вже показаний у кейсі: видалення застарілої тестової системи, яка блокує оновлення frontend-стеку. Другий можливий тип прямо названий у матеріалі: інші міграції. Це можуть бути великі переходи всередині кодової бази, де потрібно багато однотипних змін і де результат можна перевіряти частинами.

Третій тип із джерела: rewrites і performance problems. Переписування частини системи або робота з продуктивністю можуть бути кандидатами, якщо команда раніше відкладала їх через очікувану тривалість. Але сам матеріал додає обмеження: не кожен багаторічний проєкт скоротиться до тижнів.

Робоче формулювання для оцінки задачі: Це проєкт із великою кількістю повторюваних змін? Його можна розбити на окремі перевірювані частини? Інженер може переглянути кожну запропоновану зміну? Якщо так, варто протестувати агентний підхід.

Межі, помилки й перевірка результату

Кейс не доводить, що AI-агенти автоматично замінюють роки роботи в будь-якому проєкті. У джерелі прямо сказано: не кожен years-long project скоротиться до тижнів. Прийом гірше підходить там, де не можна ізолювати роботу, запустити зміни в окремій копії або забезпечити інженерне рев'ю кожної пропозиції.

Типова помилка керівника: дивитися лише на різницю між $12 тис. і $6 млн та пропустити операційну модель. У Asana були паралельні агенти, окремі копії кодової бази, дві щоденні перевірки прогресу й рев'ю кожної зміни. Без цих умов цифри з кейсу не переносяться автоматично.

• Перевірити, що застарілий компонент справді блокує модернізацію, а не просто здається незручним.
• Зафіксувати попередню оцінку часу й staffing-витрат, щоб мати з чим порівнювати експеримент.
• Переконатися, що команда може запускати агентів в окремих копіях кодової бази.
• Призначити інженера, який перевірятиме прогрес і рев'юватиме зміни.
• Не приймати результат лише тому, що агент завершив роботу. Фінальне рішення має залишатися за людьми.

Безпечне правило для бізнесу: AI-агенти можуть робити роботу швидше й дешевше, але право прийняти зміну не передається моделі.