Przeprowadziliśmy migrację z Enzyme w 2 tygodnie. Powinno to zająć pięć lat.
Niedawno użyliśmy AI, aby ukończyć lata pracy inżynieryjnej w czasie około jednego sprintu. Oto, jak to zrobiliśmy i dlaczego zmieniło to nasze myślenie o tym, co jest możliwe.
Problem pięcioletni
W 2022 roku postanowiliśmy przeprowadzić migrację pakietu testów frontendowych Asany z Enzyme, naszej przestarzałej biblioteki testowej, do React Testing Library (RTL). Enzyme straciło wsparcie społeczności, nie współpracowało dobrze z nowszymi wersjami Reacta i zachęcało do tworzenia testów ściśle powiązanych ze szczegółami implementacji, a nie z tym, co użytkownicy faktycznie widzą i robią. RTL skłoniła nas do zastosowania lepszego modelu: testowania zachowań, a nie elementów wewnętrznych.
Przez lata migracja przebiegała w sposób ciągły. Przydzielono do tego kilka projektów, nad którymi pracowało wielu inżynierów przez wiele lat. Zespoły produktowe zajmowały się tymi obszarami, za które były odpowiedzialne. Cała ta praca miała znaczenie. Ale w tempie, w jakim postępowaliśmy, do zakończenia pozostało nam jeszcze około pięciu lat.
Postawiliśmy więc cel, który był celowo nierealny: co by było, gdybyśmy ukończyli całą migrację w ciągu jednego tygodnia.
Byliśmy blisko. Praca inżynierów zajęła około półtora tygodnia. Enzyme zniknął teraz całkowicie z bazy kodu.
Jak to faktycznie wyglądało
Podejście było niemal żenująco proste. Użyliśmy Codex OpenAI z modelami Frontier o bardzo wysokim poziomie rozumowania, uruchamiając do czterech agentów jednocześnie, z których każdy był skierowany do innego katalogu. Nie pozwoliliśmy maszynie zasnąć, pozwoliliśmy agentom działać przez cały dzień i noc, a każdego ranka i wieczora sprawdzaliśmy postępy do przeglądu i otwieraliśmy pull requesty.
Oto cały prompt:
/cel Chcemy przeprowadzić migrację repozytorium z testów Enzyme do testów w stylu React Testing Library. Postępuj zgodnie z istniejącymi normami i najlepszymi praktykami w bazie kodu. Przenieś wszystkie pliki w/directory, które używają Enzyme, do korzystania z biblioteki React Testing Library. Przetestuj zmiany za pomocą [polecenia testowego]. Ogólnie rzecz biorąc, najpierw migruj pliki łatwe do konwersji.
Pięć zdań. I to wszystko.
Próbowaliśmy również bardziej wyrafinowanych konfiguracji: podziału pracy na śledzone zgłoszenia, prowadzenia przez agenta pliku z bieżącymi notatkami, prośby o utworzenie subagentów w celu dalszej paralelizacji, napisania znacznie bardziej szczegółowego polecenia dotyczącego konwencji RTL. Prawie wszystko pogorszyło sytuację. Prostota zwyciężyła.
Dlaczego prompt składający się z pięciu zdań był wystarczający
To jest najważniejsza część i jest to ta sama idea, o której OpenAI pisało niedawno w Harness engineering: jakość wyników agenta w dużym stopniu zależy od jakości środowiska, które mu przekazujesz.
Nasza baza kodów miała już w sobie lata dobrego gustu – pierwotna decyzja o przyjęciu RTL, dobrze zaprojektowane pomocniki testowe, jasne konwencje, prawdziwe przykłady, z których można czerpać. Model nie potrzebował, żebyśmy to wszystko wyjaśniali; wszystko to już tam było do odczytania. Po prostu podaliśmy cel i pozwoliliśmy agentowi działać.
Samo zadanie również miało odpowiedni kształt, aby to zadziałało: przejrzysta, weryfikowalna definicja ukończenia (koniec z Enzyme) i szybkie pętle informacji zwrotnej – sprawdzanie typów, linting, testy, CI – które mogły natychmiast wykryć błędy. Dobre ujarzmienie, dobrze zdefiniowany problem, minimalna konieczność prowadzenia.
Co stanęło na drodze
Większość problemów nie była winą modelu – była nasza:
Niektóre niedawno napisane dokumenty wewnętrzne i wytyczne dla agenta nadal wskazywały na Enzyme jako preferowany wzorzec, aktywnie kierując agenta w niewłaściwym kierunku. Nieaktualna dokumentacja nie jest już tylko drobną uciążliwością; jest to wprowadzający w błąd materiał szkoleniowy dla każdego agenta, który go czyta.
Powolne, zawodne narzędzia (etap lint, który czasami zajmował ponad dziesięć minut, niezgodności między CI a kontrolami lokalnymi) to obszary, w których stwierdziliśmy, że najbardziej potrzebna jest nasza interwencja. Agent rzadko był wąskim gardłem — to nasza własna infrastruktura była nim.
Teraz produktem jest harness
Jedna z bardziej wyraźnych lekcji płynących z tego projektu: sztuczna inteligencja nie eliminuje potrzeby posiadania dobrego gustu inżynierskiego, tylko ją wzmacnia. Czyste przykłady i jasne zasady w bazie kodu dały czysty, dobrze ukształtowany wynik. Skopiowane zostały również niezręczne wzorce. To samo dotyczyło naszej dokumentacji – nieaktualne wytyczne stały się obciążeniem w sposób, w jaki nigdy nie były nim, gdy czytali je tylko ludzie.
Z drugiej strony, zachęcające jest to, że działa to również w drugą stronę. Dobre przykłady się rozprzestrzeniają. Przejrzysta dokumentacja prawidłowo kieruje agentów. Inwestowanie w „uprząż” – dokumentację, konwencje i pętle informacji zwrotnych otaczające kod – opłaca się przy każdej przyszłej migracji, nie tylko przy tej.
Co jest następne?
Jesteśmy optymistami, jeśli chodzi o to, co to oznacza dla Asany, i wiemy, że może to również wywoływać niepokój — duża część tożsamości inżynierów jest związana z ręcznym pisaniem kodu. Mam nadzieję, że dzięki temu będziemy mogli bardziej skupić się na rzemiośle, a nie mniej, i że staniemy się bardziej ambitni w kwestii backlogu długotrwałych migracji, przepisywania kodu i problemów z wydajnością, co do których po cichu zakładaliśmy, że zawsze będą zajmować lata.
Nie każdy z tych problemów zmniejszy się z lat do tygodnia. Ale niektóre tak. Pytanie, które warto zadać, to nie tylko „czy używamy tutaj sztucznej inteligencji?” To „czy rzeczywiście próbowaliśmy skierować na to agenta w weekend i sprawdziliśmy, co wróciło w poniedziałek?”
Kilka dodatkowych szczegółów dla ciekawskich:
Cała migracja zajęła około półtora tygodnia pracy inżynierów, rozłożonej na dwa tygodnie kalendarzowe.
Koszt korzystania z modelu wyniósł około 11 tys. USD, a kolejny 1 tys. USD przeznaczono na infrastrukturę
Aby nadać perspektywę tym 12 tysiącom dolarów (przeliczenie na serwetce): praca ostatecznie przyniosła korzyści wykraczające poza samą pierwotną migrację struktury. Po drodze poprawiliśmy również pokrycie testami, naprawiliśmy słabe testy i uporządkowaliśmy starszą infrastrukturę testową. Szacujemy, że ręczne ukończenie tego pełnego zakresu oznaczałoby około 6 mln USD całkowitego nakładu pracy inżynierów.
Po drodze odnieśliśmy kilka dodatkowych sukcesów, w tym uporządkowaliśmy jeszcze starszą strukturę testową sprzed Enzyme, o której istnieniu zapomnieliśmy, a która nadal czaiła się w niektórych częściach bazy kodu.
Ten post jest częścią trwającej współpracy i partnerstwa między Asaną a OpenAI, w ramach którego badamy, w jaki sposób Codex może podjąć się większych, bardziej ambitnych prac inżynieryjnych.