Мы перешли с Enzyme за 2 недели. Это должно было занять пять лет.

Инженерная команда AsanaEngineering Team
7 августа 2026 г.
3 мин. на чтение
facebookx-twitterlinkedin
Инжиниринг Asana: в центре внимания

Недавно мы использовали ИИ, чтобы завершить инженерную работу, на которую ушли годы, примерно за один спринт. Мы расскажем, как это произошло и почему это изменило наше представление о возможном.

Проблема пяти лет

Ещё в 2022 году мы решили перенести набор тестов для фронтенда Asana из Enzyme, нашей устаревшей библиотеки тестирования, в React Testing Library (RTL). Enzyme потеряла поддержку сообщества, плохо работала с новыми версиями React и поощряла тесты, которые были тесно связаны связаны с деталями реализации, а не с тем, что пользователи действительно видят и делают. RTL подтолкнула нас к лучшей модели: тестировать поведение, а не внутренние механизмы.

В течение нескольких лет миграция уверенно продвигалась вперёд. Для этого было запущено несколько проектов, в которых несколько инженеров работали в течение года. Продуктовые команды занимались своими участками работы. Вся эта работа имела значение. Но при том темпе, с которым мы двигались, до завершения оставалось ещё примерно пять лет.

Поэтому мы поставили себе заведомо нереальную цель: что, если мы завершим всю миграцию за одну неделю?

Мы были близки к цели. Инженерные работы заняли около полутора недель. Теперь Enzyme полностью исчезла из кодовой базы.

Как это было на самом деле

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

Вот весь подсказчик:

/цель Мы хотим перенести репозиторий с тестов Enzyme на тесты в стиле библиотеки React Testing Library. Следуй существующим нормам и лучшим практикам в кодовой базе. Перенеси все файлы в/directory, которые используют Enzyme, на использование библиотеки React Testing Library. Протестируй изменения с помощью [test command]. В целом, в первую очередь перенесите файлы, которые легко преобразовать.

Пять предложений. Вот и всё.

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

Почему подсказки из пяти предложений было достаточно

Это самая важная часть, и это та же идея, о которой OpenAI недавно писала в Harness engineering: качество результатов агента в значительной степени зависит от качества среды, которую вы ему предоставляете.

Наша кодовая база уже была сформирована за годы хорошего вкуса: первоначальное решение о внедрении RTL, хорошо продуманные вспомогательные средства для тестирования, четкие соглашения, реальные примеры, на которые можно опираться. Модели не нужно было ничего объяснять; всё это уже было там, и её можно было прочитать. Мы просто указали цель и дали агенту возможность работать.

Сама задача также имела правильную форму, чтобы это сработало: четкое, верифицируемое определение готовности (больше никакого Enzyme) и быстрые циклы обратной связи — проверка типов, линтинг, тесты, CI — которые могли немедленно выявлять ошибки. Хорошая среда, четко определенная проблема, минимальная необходимость в руководстве.

Что помешало

Большинство проблем были не по вине модели, а по нашей:

  • В некоторых недавно написанных внутренних документах и руководствах для агентов Enzyme по-прежнему указывался как предпочтительный шаблон, что активно направляло агента в неправильное русло. Устаревшая документация — это уже не просто небольшая неприятность, а вводящий в заблуждение учебный материал для каждого агента, который его читает.

  • Медленные, ненадёжные инструменты (этап lint, который иногда занимал более десяти минут, несоответствия между CI и локальными проверками) — вот где, как мы обнаружили, нам нужно было вмешаться больше всего. Узким местом редко был агент — это была наша собственная инфраструктура.

Теперь продукт — это harness

Один из самых очевидных уроков этого проекта: ИИ не устраняет необходимость в инженерном вкусе, а усиливает её. Чистые примеры и чёткие правила в базе кода дали чистый, хорошо структурированный результат. Неудачные шаблоны тоже копировались. То же самое относилось и к нашим документам: устаревшие инструкции стали обузой, чего не было, когда их читали только люди.

Обратная сторона заключается в том, что это работает и в другом направлении. Хорошие примеры распространяются. Чёткая документация правильно направляет агентов. Инвестиции в «инфраструктуру» — документацию, соглашения и циклы обратной связи, связанные с кодом, — окупаются при каждой будущей миграции, а не только при этой.

Что дальше

Мы с оптимизмом смотрим на то, что это значит для Asana, и понимаем, что это также может вызывать беспокойство — для многих разработчиков написание кода вручную является важной частью их идентичности. Я надеюсь, что это позволит нам больше, а не меньше, заботиться о мастерстве и проявлять больше амбиций в отношении бэклога длительных миграций, переписывания кода и проблем с производительностью, которые, как мы молчаливо предполагали, всегда будут занимать годы.

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


Несколько дополнительных деталей для любопытных:

  • Вся миграция заняла около полутора недель инженерных работ, распределённых на две календарные недели.

  • Стоимость использования модели составила примерно 11 000 долларов, а расходы на инфраструктуру — ещё 1000 долларов.

  • Чтобы представить эти 12 000 долларов в перспективе (прикидка на салфетке): в конечном итоге работа принесла выгоды, выходящие за рамки первоначальной миграции фреймворка. Попутно мы также улучшили охват тестирования, исправили некачественные тесты и очистили устаревшую инфраструктуру тестирования. По нашим оценкам, завершение всего объёма работ вручную потребовало бы около 6 млн долларов США при полной загрузке инженеров.

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

Эта публикация является частью продолжающегося сотрудничества и партнёрства между Asana и OpenAI, в рамках которого изучается, как Codex может взять на себя более крупные и амбициозные инженерные задачи.