Недавно мы использовали ИИ, чтобы завершить инженерную работу, на которую ушли годы, примерно за один спринт. Мы расскажем, как это произошло и почему это изменило наше представление о возможном.
Ещё в 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 и локальными проверками) — вот где, как мы обнаружили, нам нужно было вмешаться больше всего. Узким местом редко был агент — это была наша собственная инфраструктура.
Один из самых очевидных уроков этого проекта: ИИ не устраняет необходимость в инженерном вкусе, а усиливает её. Чистые примеры и чёткие правила в базе кода дали чистый, хорошо структурированный результат. Неудачные шаблоны тоже копировались. То же самое относилось и к нашим документам: устаревшие инструкции стали обузой, чего не было, когда их читали только люди.
Обратная сторона заключается в том, что это работает и в другом направлении. Хорошие примеры распространяются. Чёткая документация правильно направляет агентов. Инвестиции в «инфраструктуру» — документацию, соглашения и циклы обратной связи, связанные с кодом, — окупаются при каждой будущей миграции, а не только при этой.
Мы с оптимизмом смотрим на то, что это значит для Asana, и понимаем, что это также может вызывать беспокойство — для многих разработчиков написание кода вручную является важной частью их идентичности. Я надеюсь, что это позволит нам больше, а не меньше, заботиться о мастерстве и проявлять больше амбиций в отношении бэклога длительных миграций, переписывания кода и проблем с производительностью, которые, как мы молчаливо предполагали, всегда будут занимать годы.
Не все из этих проблем можно решить за неделю, а не за годы. Но некоторые — да. Вопрос, который стоит задать, — это не просто «используем ли мы здесь ИИ?» Вопрос в том, «попробовали ли мы на самом деле поручить это агенту на выходных и посмотрели ли, что он сделал к понедельнику?»
Вся миграция заняла около полутора недель инженерных работ, распределённых на две календарные недели.
Стоимость использования модели составила примерно 11 000 долларов, а расходы на инфраструктуру — ещё 1000 долларов.
Чтобы представить эти 12 000 долларов в перспективе (прикидка на салфетке): в конечном итоге работа принесла выгоды, выходящие за рамки первоначальной миграции фреймворка. Попутно мы также улучшили охват тестирования, исправили некачественные тесты и очистили устаревшую инфраструктуру тестирования. По нашим оценкам, завершение всего объёма работ вручную потребовало бы около 6 млн долларов США при полной загрузке инженеров.
По ходу дела мы обнаружили несколько неожиданных преимуществ, в том числе очистку ещё более старого фреймворка тестирования, существовавшего до Enzyme, о котором мы забыли и который всё ещё присутствовал в некоторых частях кодовой базы.
Эта публикация является частью продолжающегося сотрудничества и партнёрства между Asana и OpenAI, в рамках которого изучается, как Codex может взять на себя более крупные и амбициозные инженерные задачи.