Як Asana прибрала Enzyme за два тижні: Codex, паралельні агенти й контрольований migration factory

Asana роками переносила frontend test suite з Enzyme на React Testing Library. Enzyme втратив активну підтримку, погано узгоджувався з новішими версіями React і стимулював тести, прив’язані до implementation details. Проблема була добре зрозумілою, але економіка ручної міграції була поганою: великий обсяг однотипних змін конкурував із продуктовою розробкою, а завершення відкладалося роками.

У серпні 2026 Asana описала інший operating model: замість того щоб дробити migration на сотні дрібних backlog tickets, команда сформулювала коротку ціль, дала агентам інструменти перевірки та розклала codebase на паралельні робочі області. Це важлива відмінність між «AI пише код» і migration factory: модель не просто генерує patch, а повторює керований цикл `inspect → transform → test → fix → propose change` багато разів.

OpenAI повідомляє, що work expected to take about five years був завершений приблизно за два календарні тижні; Asana оцінювала попередній staffing plan приблизно у $6 млн, тоді як model + infrastructure cost склав близько $12 тис. Це сильний сигнал для класу великих механічних migrations, але не ліцензія множити будь-який backlog на 500× і називати це ROI.

Trigger — рішення закрити конкретний migration target з чітким end state: Enzyme має зникнути з repository, а test behavior — залишитися коректним. Input — repository snapshot, existing tests, target testing conventions, reference examples, package/build configuration, lint/test commands і правила contribution workflow. Asana зазначає, що стартовий prompt був лише приблизно з п’яти речень; складність переносилася не в багатотомний prompt, а в harness, кодову базу та executable checks.

AI stage — repository exploration, пошук залежних tests, rewrite, локальне виконання перевірок, remediation failures і підготовка proposed changes. Integrations — source control, isolated working copies, test runner, package manager, lint/type checks, CI і pull-request review. Output — не «відповідь у чаті», а verified candidate change з diff, test evidence і human-reviewable provenance.

• Trigger → конкретний migration goal із measurable done-state;
• Input → codebase + target conventions + executable validation;
• AI → inspect, rewrite, test, repair, package change;
• Integrations → isolated worktrees/copies, Git, tests, CI, PR review;
• Output → reviewable change set, а не автономний production deploy.

Репродукований workflow: `scope partition → isolated agent workspace → inspect target files → transform tests → run deterministic checks → self-repair → open candidate diff → human review → merge → regression suite`. До чотирьох агентів можуть працювати паралельно, але кожен отримує disjoint або явно координований scope, щоб не перетворити concurrency на merge-conflict generator.

Autonomy A4 тут виправдана тим, що агент довго виконує багатокрокову технічну роботу й самостійно проходить локальні цикли виправлення. Водночас це не A5: інженер перевіряє прогрес, review-ить запропоновані зміни й зберігає final merge authority. Для production reproduction краще додати branch protection, required checks і заборону direct-to-main writes, навіть якщо конкретний vendor story не описує кожен із цих controls.

Human review не повинен бути церемонією. Reviewer перевіряє behavioral equivalence, test intent, accidental deletion, hidden coupling, snapshot inflation, accessibility semantics і coverage gaps. Якщо людина дивиться лише на зелений CI, вона просто перетворює агентну помилку на красиво автоматизовану помилку.

Типові failure modes: агент мігрує syntax, але змінює semantics; переписує flaky test так, що він перестає ловити регресію; створює дублікати helpers; конфліктує з іншим агентом; не бачить hidden dependency; тест проходить локально, але падає в full suite; timeout стається після успішного commit/push і retry дублює роботу. Для цього потрібні idempotent task IDs, scoped directories, deterministic command set, full-suite gate і reconciliation перед повторним запуском.

Control plane має відокремлювати execution authority від merge authority. Agent token не потребує production deploy, secrets адміністратора чи unrestricted repository scope. Корисний мінімум: allowlisted commands, sandbox/worktree isolation, dependency-install policy, egress limits, maximum runtime/cost budget, diff-size threshold, protected paths і автоматична ескалація при змінах у security-sensitive або build-system файлах.

Parallelism масштабує не лише throughput, а й failure surface. Перед запуском N агентів потрібна partition strategy: directory ownership, dependency graph або queue з lock на overlapping files. Після завершення — integration pass, який повторно запускає checks уже на об’єднаній гілці. Інакше чотири локально зелені агенти можуть створити один глобально червоний repository.

Такий agentic migration не обов’язково є постійним 24/7 workflow. Найкраща частота — project-driven: framework migrations, API upgrades, test rewrites, dependency deprecations, codemods, large-scale lint/type remediation. Scalability визначається не кількістю токенів, а тим, наскільки задача decomposable і наскільки дешево перевірити correctness.

Cost model: model tokens/compute + isolated runtime + CI minutes + artifact storage + observability + human review + rework from failed transformations. $12K у Asana — reported cost конкретного project, а не price list для «п’яти років engineering». Для власного pilot рахуйте `cost per verified migrated test/file` і `review minutes per accepted change`, а не cost per generated token.

KPI: accepted-change rate, regression escape rate, full-suite pass rate, review rework, migrated units/day, percentage of files requiring manual rewrite, conflict rate між agents, p95 task duration, cost per verified unit і post-merge defect rate. Найважливіший показник — verified end state: legacy framework реально видалений, behavior збережений, а не просто створено багато PR.

Offline eval dataset формується з representative migration slices: прості component tests, async behavior, mocks, context/providers, accessibility queries, tests із нестандартними helpers, known flaky cases і intentionally failing examples. Для кожного slice фіксуються expected invariants: які dependencies мають зникнути, які user-observable behaviors зберегтися, які checks обов’язкові. Deterministic graders перевіряють build, types, tests, lint, forbidden imports і dependency graph; human grader оцінює semantics та maintainability.

Rollout: `20–50 low-risk files → one directory → several disjoint directories with two agents → four-agent parallel wave → full integration sweep`. Promotion gate — zero critical regressions, bounded reviewer rework і стабільний cost per accepted change. Якщо model version, prompt, test harness або repository conventions змінюються, critical suite запускається знову. Production incident або escaped regression мінімізується до reproduction fixture й стає permanent regression test.

• Gate 1 → deterministic test/lint/type/build PASS;
• Gate 2 → no forbidden legacy imports and expected dependency reduction;
• Gate 3 → human semantic review for representative/high-risk diffs;
• Gate 4 → merged-branch integration run after parallel waves;
• Rollback → revert bounded migration batch, not entire modernization program.

Потрібні mature repository, deterministic tests, repeatable local/CI environment, чіткий target style, branch/PR discipline і reviewers, які розуміють domain behavior. Найкраще підходить компаніям із великим накопиченим mechanical tech debt: framework migration, API deprecation, repetitive test modernization, schema refactor або broad code hygiene.

Не починайте з найкритичнішого monolith rewrite. Виберіть migration, де correctness відносно добре machine-checkable, створіть 30–100 representative fixtures, дайте агенту bounded branch і виміряйте accepted output. Після цього масштабуйте parallelism. Якщо acceptance потребує читати думки архітектора, а tests не ловлять більшість помилок, ваш «agent factory» буде фабрикою review debt.

Практичний 80/20: хороший harness, executable checks, partitioning і merge gates дають більше, ніж нескінченне полірування prompt. Саме це й робить кейс Asana цікавим: коротка інструкція працювала тому, що навколо неї був repository з перевірками й люди, які зберігали authority.