Nous avons migré hors d'Enzyme en deux semaines. Cela aurait dû prendre cinq ans.
Nous avons récemment utilisé l'IA pour terminer des années de travail d'ingénierie en un sprint environ. Voici comment et pourquoi cela a changé notre façon de penser ce qui est possible.
Le problème des cinq ans
En 2022, nous avons entrepris de migrer la suite de tests front-end d'Asana d'Enzyme, notre bibliothèque de tests vieillissante, vers React Testing Library (RTL). Enzyme avait perdu le soutien de la communauté, ne fonctionnait pas bien avec les nouvelles versions de React et encourageait les tests étroitement liés aux détails de l'implémentation plutôt qu'à ce que les utilisateurs voient et font réellement. RTL nous a poussés vers un meilleur modèle : tester le comportement, et non les éléments internes.
La migration a progressé régulièrement pendant des années. Plusieurs projets de plusieurs années, impliquant plusieurs ingénieurs, ont été mis en place à cet effet. Les équipes produit se sont attaquées aux aspects dont elles étaient responsables. Tout ce travail était important. Mais au rythme où nous avancions, il nous restait encore environ cinq ans pour terminer.
Nous nous sommes donc fixé un objectif délibérément déraisonnable : et si nous terminions toute la migration en une semaine ?
Nous y sommes presque parvenus. Il a fallu environ une semaine et demie de temps d'ingénierie. Enzyme a maintenant complètement disparu du code source.
Comment cela s'est réellement passé
L'approche était d'une simplicité presque embarrassante. Nous avons utilisé Codex d'OpenAI avec des modèles de pointe au raisonnement extra-élevé, en exécutant jusqu'à quatre agents à la fois, chacun pointant vers un répertoire différent. Nous avons empêché la machine de se mettre en veille, laissé les agents fonctionner toute la journée et toute la nuit, et effectué un contrôle chaque matin et chaque soir pour évaluer la progression et ouvrir les demandes d'extraction (pull requests).
Voici l'intégralité de l'instruction :
/goal Nous voulons migrer le dépôt des tests Enzyme vers des tests de style React Testing Library. Respecte les normes et les bonnes pratiques existantes dans le codebase. Migre tous les fichiers dans/directory qui utilisent Enzyme pour utiliser la bibliothèque React Testing Library. Testez vos modifications avec [test command]. En général, privilégiez la migration des fichiers faciles à convertir en premier.
Cinq phrases. C'était tout.
Nous avons également essayé des configurations plus sophistiquées : diviser le travail en tickets suivis, demander à l'agent de tenir un fichier de notes, lui demander de générer des sous-agents pour une parallélisation plus poussée, rédiger une invite beaucoup plus détaillée sur les conventions RTL. Presque toutes ces tentatives ont empiré les choses. La simplicité a gagné.
Pourquoi une instruction de cinq phrases était suffisante
C'est la partie la plus importante, et c'est la même idée qu'OpenAI a récemment évoquée dans Harness engineering : la qualité des résultats d'un agent dépend fortement de la qualité de l'environnement que vous lui fournissez.
Notre base de code avait déjà été façonnée par des années de bon goût : la décision initiale d'adopter RTL, des aides aux tests bien conçues, des conventions claires, de vrais exemples sur lesquels s'appuyer. Le modèle n'avait pas besoin que nous expliquions tout cela ; c'était déjà là, prêt à être lu. Nous avons simplement fourni l'objectif et laissé l'agent s'exécuter.
La tâche elle-même avait également la forme adéquate pour que cela fonctionne : une définition claire et vérifiable de ce qui est accompli (plus d'Enzyme), et des boucles de rétroaction rapides (vérification de type, linting, tests, CI) qui pouvaient détecter les erreurs immédiatement. Un bon environnement, un problème bien défini, un accompagnement minimal requis.
Les obstacles
La plupart des frictions n'étaient pas dues au modèle, mais à nous :
Certains documents internes et des conseils aux agents récemment rédigés indiquaient encore qu'Enzyme était le modèle privilégié, orientant activement l'agent dans la mauvaise direction. La documentation obsolète n'est plus seulement un désagrément mineur ; c'est un support de formation trompeur pour tous les agents qui la lisent.
C'est au niveau des outils lents et peu fiables (une étape de lint qui prenait parfois plus de dix minutes, des incohérences entre l'intégration continue et les vérifications locales) que nous avons constaté que nous devions intervenir le plus. L'agent était rarement le frein : c'était notre propre infrastructure.
Le harnais est désormais le produit
L'une des leçons les plus claires de ce projet : l'IA n'élimine pas le besoin de goût en matière d'ingénierie, elle l'amplifie. Des exemples propres et des conventions claires dans le code source ont produit un résultat propre et bien structuré. Les modèles maladroits ont également été copiés. Il en allait de même pour nos documents : les conseils obsolètes sont devenus un handicap, alors qu'ils ne l'étaient jamais vraiment lorsque seuls des humains les lisaient.
Le revers de la médaille, encourageant, est que cela fonctionne également dans l'autre sens. Les bons exemples se propagent. Des documents clairs orientent correctement les agents. Investir dans le « harnais » (la documentation, les conventions et les boucles de rétroaction entourant le code) est payant pour toutes les migrations futures, pas seulement pour celle-ci.
Et maintenant ?
Nous sommes optimistes quant aux conséquences pour Asana, et nous savons que cela peut aussi être déstabilisant : une grande partie de l'identité des ingénieurs est liée à l'écriture manuelle du code. J'espère que cela nous permettra de nous consacrer davantage à l'artisanat, et non l'inverse, et d'être plus ambitieux quant au backlog de migrations de longue date, de réécritures et de problèmes de performance dont nous avons toujours supposé, en silence, qu'ils prendraient des années.
Tous ces problèmes ne passeront pas de plusieurs années à une semaine. Mais certains le seront. La question qu'il convient de se poser n'est pas seulement : « Utilisons-nous l'IA ici ? » C'est : « Avons-nous vraiment essayé de confier cette tâche à un agent pendant un week-end et avons-nous examiné ce qu'il nous a renvoyé le lundi ? »
Quelques détails supplémentaires, pour les curieux :
L'ensemble de la migration a nécessité environ une semaine et demie de temps d'ingénierie, répartie sur deux semaines calendaires.
L'utilisation du modèle a coûté environ 11 000 $, plus 1 000 $ pour l'infrastructure
Pour mettre ces 12 000 $ en perspective (calcul rapide) : le travail a finalement apporté des avantages au-delà de la migration du cadre initial elle-même. En cours de route, nous avons également amélioré la couverture des tests, corrigé les tests défectueux et nettoyé l'infrastructure de test existante. Nous estimons que terminer l'ensemble de ce travail manuellement aurait représenté environ 6 millions de dollars en effort d'ingénierie à plein temps.
Nous avons obtenu quelques victoires inattendues en cours de route, notamment le nettoyage d'un cadre de test encore plus ancien, antérieur à Enzyme, dont nous avions oublié qu'il se cachait encore dans certaines parties du code.
Cet article fait partie d'une collaboration et d'un partenariat continus entre Asana et OpenAI, qui explorent comment Codex peut entreprendre des travaux d'ingénierie plus importants et plus ambitieux.