AI scrie codul, seniorii își asumă release-ul — pipeline-ul nostru de review

„Construim cu AI” poate însemna două lucruri foarte diferite. Poate însemna că ajunge mai repede în producție cod pe care nu l-a citit nimeni cu adevărat. Sau poate însemna că AI-ul face cea mai mare parte din scris, în timp ce review-ul, testarea și responsabilitatea rămân unde au fost dintotdeauna — la ingineri cu experiență.

Noi facem a doua variantă. Articolul ăsta arată cum arată asta pe un proiect real: o pereche de aplicații native, una în Swift pentru iOS și una în Kotlin pentru Android, unde agenții AI fac o mare parte din muncă și totuși fiecare schimbare trece pe la un inginer senior înainte să ajungă la utilizatori. Nu putem numi clientul sau proiectul, dar putem arăta pipeline-ul.

Contextul: două aplicații native, un singur comportament

Clientul are nevoie de două aplicații native care să se comporte identic. Să scrii fiecare funcționalitate de două ori, de mână, e lent, iar cele două versiuni tind să se îndepărteze una de alta: o regulă de validare care există pe iOS, dar nu și pe Android, un caz limită tratat doar pe o platformă.

Așa că am împărțit munca după ce face fiecare participant cel mai bine:

1. Un developer construiește funcționalitatea pe iOS, asistat de AI.
2. Un agent o portează în Android nativ, unu la unu.
3. Un al doilea agent verifică portarea.
4. Cele două aplicații sunt testate în paralel.
5. Un inginer senior face review și testare la final — și își asumă release-ul.

Pasul 1 — iOS: un developer cu AI și un pull request normal

Fiecare funcționalitate pornește pe iOS. Developerul lucrează cu Claude Code: AI-ul scrie prima variantă a implementării și a testelor, developerul o conduce, o corectează și o testează pe un iPhone real. Rezultatul trece printr-un pull request normal, cu teste obligatorii în CI și review de senior înainte de merge.

Schimbarea de iOS ajunsă în main e cel mai important artefact din tot pipeline-ul. Nu mai e „o descriere a unei funcționalități” — e o implementare care funcționează, verificată și testată, și devine specificația pentru Android.

Pasul 2 — Android: un agent portează schimbarea, 1:1

Când pull request-ul de iOS intră în main, lansăm un agent prin harness-ul nostru intern. Sarcina lui e îngustă și bine definită: să implementeze aceeași schimbare în aplicația Android nativă, unu la unu — aceleași ecrane, aceleași stări, aceeași validare, aceeași tratare a erorilor, aceleași cazuri limită.

„Unu la unu” nu înseamnă să traduci Swift linie cu linie în Kotlin. Comportamentul trebuie să fie identic; codul trebuie să fie Android idiomatic. Ciclul de viață, permisiunile, munca în background și navigarea urmează regulile Android, nu pe cele de iOS. O sarcină îngustă și bine specificată ca asta e exact locul unde agenții sunt puternici: specificația e completă, verificată și executabilă.

Pasul 3 — un al doilea agent verifică portarea

Agentul care portează nu își verifică singur munca. Un agent separat de review, cu context nou și altă instrucțiune — găsește ce e greșit — citește schimbarea de Android în comparație cu originalul de iOS. Caută tipurile de probleme pe care le introduce de obicei o portare:

• Comportament care diferă pe tăcute — un caz limită tratat pe iOS, dar pierdut pe Android, o valoare implicită diferită, o stare de eroare lipsă.
• Idiomuri de platformă pierdute la traducere — tipare de iOS forțate pe Android, unde ciclul de viață, firele de execuție sau modelul de permisiuni funcționează altfel.
• Teste care trec fără să testeze nimic — aserțiuni mereu adevărate, mock-uri care golesc testul de sens.
• Scurtături la securitate și date — date sensibile în loguri, validare relaxată, stocare mai puțin sigură decât pe iOS.

Problemele găsite se corectează în schimbare înainte ca vreun om să-și petreacă timpul pe ea.

Pasul 4 — testare în paralel, comparativ

Apoi cele două aplicații sunt testate în paralel și comparativ: aceleași scenarii rulează pe aplicația de iOS și pe cea de Android, iar rezultatele se compară. Întrebarea nu e doar „merge Android?”, ci „se comportă Android exact ca iOS?”. Testarea se face pe iPhone-uri și telefoane Android reale, prin build-uri TestFlight și Google Play Internal Testing, nu doar în simulatoare.

Pasul 5 — inginerul senior, la final

Nimic nu ajunge la utilizatori până când un inginer senior nu l-a verificat și testat. Indiferent cine — sau ce — a scris codul, seniorul verifică de fiecare dată aceleași lucruri:

• Arhitectură și design — se potrivește schimbarea cu arhitectura aplicației sau adaugă complexitate care va costa mai târziu?
• Securitate și date — autentificare, permisiuni, date sensibile, input nesigur.
• Teste reale — verifică testele comportamentul care contează sau doar trec?
• Pe dispozitiv — funcționează efectiv în aplicație, pe un telefon real?

Agenții fac review-ul seniorului mai rapid, pentru că o bună parte din zgomot a dispărut deja. Nu îl înlocuiesc. Seniorul e cel care spune „asta se lansează” — și cel care răspunde pentru asta.

Ce am învățat

• O implementare verificată e cel mai bun prompt. Portarea pornind de la o schimbare de iOS aflată deja în main și testată merge mult mai bine decât implementarea pornind de la o descriere scrisă.
• Agenții să verifice agenți — cu altă instrucțiune. Agentul care a scris codul e cel mai slab reviewer al lui. Un al doilea agent, pus să caute probleme, prinde altă categorie de greșeli.
• Compară, nu doar testa. Pentru două aplicații native, „ambele trec testele” e mai slab decât „ambele se comportă la fel în aceleași scenarii”.
• Un om la final, mereu. AI-ul schimbă cine scrie codul. Nu schimbă cine răspunde pentru el.

---

Vrei să construiești așa — cu viteza AI și responsabilitatea unui senior? Vezi cum abordăm dezvoltarea de produse AI sau citește cum am construit agenți Claude pentru o firmă de construcții.