We zijn in 2 weken van Enzyme overgestapt. Het had vijf jaar moeten duren.

We hebben onlangs AI gebruikt om jaren engineeringwerk in ongeveer één sprint te voltooien. Hier lees je hoe en waarom het onze manier van denken over wat mogelijk is heeft veranderd.

Het vijfjarenprobleem

In 2022 wilden we de frontend-testsuite van Asana migreren van Enzyme, onze verouderde testbibliotheek, naar React Testing Library (RTL). Enzyme had de community-ondersteuning verloren, werkte niet goed met nieuwere versies van React en stimuleerde tests die nauw gekoppeld waren aan implementatiedetails in plaats van wat gebruikers daadwerkelijk zien en doen. RTL duwde ons naar een beter model: testgedrag, geen interne zaken.

De migratie boekte jarenlang gestage vooruitgang. Er zijn verschillende projecten met meerdere ingenieurs en een looptijd van meerdere jaren aan toegewezen. Productteams werkten aan de onderdelen waarvoor zij verantwoordelijk waren. Al dat werk was belangrijk. Maar in het tempo dat we gingen, hadden we nog ongeveer vijf jaar nodig om het af te maken.

Dus stelden we een opzettelijk onredelijk Doel: wat als we de hele migratie in één week zouden voltooien.

We kwamen in de buurt. Het kostte Engineering ongeveer anderhalve week. Enzyme is nu volledig uit de codebase verdwenen.

Zo ging het eigenlijk

De aanpak was bijna gênant eenvoudig. We gebruikten de Codex van OpenAI met grensmodellen voor extra hoog redeneren, waarbij we maximaal vier agents tegelijk uitvoerden, elk gericht op een andere map. We zorgden ervoor dat de machine niet sliep, lieten de agents de hele dag en nacht draaien en controleerden elke ochtend en avond de voortgang en openstaande pull-aanvragen.

Hier is de volledige prompt:

/doel We willen de repo migreren van Enzyme-tests naar tests in de stijl van de React Testing Library. Volg bestaande normen en beste praktijken in de codebase. Migreer alle bestanden in/directory die Enzyme gebruiken om de React Testing Library te gebruiken. Test je wijzigingen met [testopdracht]. Over het algemeen is er een voorkeur om eerst bestanden te migreren die gemakkelijk te converteren zijn.

Vijf zinnen. Dat was het.

We probeerden ook meer uitgebreide opstellingen: het werk opsplitsen in bijgehouden tickets, de agent een lopend notitiesbestand laten bijhouden, hem vragen om subagenten te genereren om verder te paralleliseren, een veel gedetailleerdere prompt schrijven over RTL-conventies. Bijna alles maakte het erger. Eenvoud won.

Waarom een prompt van vijf zinnen genoeg was

Dit is het deel dat er het meest toe doet, en het is hetzelfde idee waarover OpenAI onlangs schreef in Harness engineering: de kwaliteit van de output van een agent hangt sterk af van de kwaliteit van de omgeving die je hem geeft.

Onze codebase had al jarenlange goede smaak in zich — de oorspronkelijke beslissing om RTL te gebruiken, goed ontworpen testhelpers, duidelijke conventies, echte voorbeelden om uit te putten. Het model had het niet nodig dat we dat allemaal uitlegden; het was er al om gelezen te worden. We gaven gewoon het Doel op en lieten de agent zijn gang gaan.

De taak zelf had ook de juiste vorm om dit te laten werken: een duidelijke, verifieerbare definitie van gereed (geen Enzyme meer), en snelle feedbackloops — typechecking, linting, tests, CI — die fouten onmiddellijk konden opsporen. Goed harnas, goed gedefinieerd probleem, minimale begeleiding vereist.

Wat in de weg stond

Het grootste deel van de wrijving was niet de schuld van het model — het was onze schuld:

• Sommige recent geschreven interne documenten en agentbegeleiding wezen nog steeds naar Enzyme als het voorkeurspatroon, waardoor de agent actief in de verkeerde richting werd gestuurd. Verouderde documentatie is niet langer alleen een kleine ergernis; het is misleidend trainingsmateriaal voor elke medewerker die het leest.

• Langzame, onbetrouwbare tools (een lint-stap die af en toe meer dan tien minuten duurde, discrepanties tussen CI en lokale controles) waren waar we het meest moesten ingrijpen. De medewerker was zelden het knelpunt — onze eigen infrastructuur was dat.

Het harnas is nu het product

Een van de duidelijkere lessen uit dit project: AI neemt de behoefte aan technische smaak niet weg, maar versterkt deze. Schone voorbeelden en duidelijke afspraken in de codebase leverden een schone, goed gevormde output op. Ook onhandige patronen werden gekopieerd. Hetzelfde gold voor onze documenten — verouderde richtlijnen werden een risico op een manier die het nooit helemaal was toen alleen mensen het lazen.

De bemoedigende keerzijde is dat dit ook in de andere richting werkt. Goede voorbeelden verspreiden zich. Duidelijke documenten sturen agenten correct. Investeren in het "harnas" — de documenten, conventies en feedbacklussen rond de code — loont bij elke toekomstige migratie, niet alleen bij deze.

Wat is het volgende

We zijn optimistisch over wat dit betekent voor Asana en weten dat het ook verontrustend kan zijn — een groot deel van de identiteit van de engineering zit vast in het handmatig schrijven van code. Ik hoop dat het ons de vrijheid geeft om meer te geven om vakmanschap, niet minder, en om ambitieuzer te zijn over de Backlog van langdurige migraties, herschrijvingen en prestatieproblemen waarvan we stilletjes hebben aangenomen dat ze altijd jaren zullen duren.

Niet elk van die problemen zal van jaren naar een week ineenstorten. Maar sommige wel. De vraag die het waard is om te stellen, is niet alleen "gebruiken we hier AI?" Het is "hebben we eigenlijk geprobeerd om hier in het weekend een agent op te richten en gekeken naar wat er op maandag terugkwam?"

Een paar extra details, voor de nieuwsgierigen:

• De hele migratie kostte ongeveer anderhalve week aan technische tijd, verdeeld over twee agendaweken.

• Het gebruik van het model kostte ongeveer $ 11.000, met nog eens $ 1.000 aan infrastructuur

• Om die $ 12.000 in perspectief te plaatsen (eenvoudige rekensom): het werk leverde uiteindelijk voordelen op die verder gingen dan de oorspronkelijke raamwerkmigratie zelf. Onderweg hebben we ook de testdekking verbeterd, slechte tests verholpen en de verouderde testinfrastructuur opgeruimd. We schatten dat het handmatig voltooien van die volledige omvang ongeveer $ 6 miljoen aan volledig belaste technische inzet zou hebben gekost.

• We boekten onderweg een paar onverwachte successen, waaronder het opruimen van een nog ouder testraamwerk van vóór Enzyme waarvan we waren vergeten dat het nog steeds in delen van de codebase op de loer lag.

Dit bericht maakt deel uit van een voortdurende samenwerking en partnerschap tussen Asana en OpenAI om te onderzoeken hoe Codex groter en ambitieuzer engineeringwerk kan uitvoeren.