O aplicație vocală construită de o echipă de agenți

Chelar este o aplicație pentru cămară cu care vorbiți. Spuneți „am luat 5 role din beci și le-am pus în baie” și stocul se mută din beci în baie, pentru toată familia. Este construită aproape în întregime de agenți de programare. Nu un singur agent într-o conversație lungă, ci o echipă mică, cu roluri fixe, fiecare cu propriile reguli.

Rolurile

• Arhitect. Doar citire. Pentru tichetele care o cer, scrie o scurtă notă despre mecanism înaintea oricărui cod: cum funcționează fiecare scriere și fiecare reîncercare, ce trebuie să rămână adevărat când evenimentele sosesc de două ori sau în altă ordine și ce erori trebuie să arate testele.
• Implementator. Scrie întâi testele, pe propriul branch, în propria copie a repository-ului. Raportul lui leagă fiecare criteriu de acceptare de testul sau fluxul care îl dovedește și enumeră lucrurile de care nu este sigur.
• Verificator. Doar citire. Verifică codul față de standardele proiectului și față de tichet și compară capturile de ecran din CI cu macheta de design.
• Verificator de securitate. Doar citire, în paralel cu verificatorul. Doar reguli de acces, autentificare și confidențialitate.

Niciun verificator nu este vreodată sesiunea care a scris codul. O rundă de corecturi pornește un implementator nou, iar fiecare problemă găsită primește întâi un test care eșuează, apoi corectura.

Un tichet, de la început la sfârșit

1. Un tichet cu criterii de acceptare, decupat dintr-o specificație mai mare, cu dependențele legate.
2. Verificări înainte de start. De exemplu: orice ecran atins de tichet trebuie să existe deja pe macheta de design.
3. O etapă opțională de design, apoi implementatorul, apoi un pull request.
4. Ambii verificatori în paralel. Îndoielile rămase ale implementatorului ajung la amândoi, ca să le judece.
5. Runde de corecturi până nu mai rămâne nimic peste „low”, apoi CI-ul trebuie să fie verde și branch-ul la zi înainte de merge.

Rulează cel mult două tichete în același timp și doar când nu au în comun tabele, componente sau ecrane.

Cum au arătat trei săptămâni

De la primul commit, pe 3 octombrie, până pe 23 octombrie:

• 64 de tichete au trecut prin bucla de verificare, în 142 de runde de verificare.
• Doar 13 dintre ele (20%) au intrat în merge la prima verificare. Restul s-au întors cel puțin o dată; cele mai multe au avut nevoie de două runde, cel mai greu de cinci.
• Verificatorii au semnalat 49 de probleme grave sau critice și 25 de regresii înainte ca ceva să ajungă în branch-ul principal.
• Aproximativ 100 de pull request-uri integrate și circa 35.000 de linii de TypeScript și SQL.

Cifra de 80% este cea care contează pentru mine. Un agent care scrie cod este rapid și sigur pe el. Un al doilea agent, care nu l-a scris, cu o sarcină îngustă și tichetul în față, este ce face viteza utilizabilă.

Testele duc greul

Aproximativ 120 de fișiere de teste: teste unitare și de componente, plus teste de bază de date care verifică cine poate citi ce rânduri. Peste ele, 17 fluxuri end-to-end rulează în CI pe emulatoare Android, împărțite în două lanțuri paralele, fiecare cu propriul emulator și propriul backend local. Recunoașterea vocală este înlocuită în aceste rulări cu un stub: „aude” o singură propoziție fixă în română, așa că fluxul este testat fără să depindă de un microfon.

Fiecare merge în main aplică migrările bazei de date, publică funcțiile de server și construiește un pachet Android semnat.

Ce a mers prost

La început, mai multe ecrane au fost construite după o descriere scrisă sau o schiță aproximativă, nu după un design final. Agenții au făcut ce li s-a cerut, iar ecranele nu se potriveau cu restul aplicației.

Soluția a fost o regulă, nu un prompt mai bun: niciun tichet de interfață nu începe până nu există macheta lui de design, atât în aplicația de design, cât și ca o copie înghețată în repository. Verificatorii compară capturile de ecran din CI cu acea machetă, iar o diferență neexplicată se consideră o problemă găsită.

Greșelile repetate ajung într-un fișier de capcane, câte un rând fiecare. Implementatorii îl citesc înainte să scrie cod; verificatorii îl tratează ca pe un standard. Un rând din el: un mesaj de anulare care iese din ecran aplică o acțiune pe care nu a văzut-o nimeni, așa că orice are numărătoare inversă rămâne pe ecran sau se oprește.

Ce se aplică și în proiectele pentru clienți

Aceeași structură funcționează și în afara unei aplicații pentru gospodărie. Înainte ca un agent să scrie cod, se decide ce poate atinge, ce înseamnă „gata” în teste și cine verifică. Apoi munca este verificată de un alt agent și, la final, de un om.

Urmează în acest sistem: evaluarea prompturilor vocale pe înregistrări reale înainte de lansare. Deocamdată este un tichet, nu un rezultat.