Flux de lucru Codex și multi-agen: lucrați cu agenți fără a pierde controlul
· 7 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Prima dată când un agent de codificare remediază o eroare pentru dvs., reacția este aproape întotdeauna aceeași: un amestec de entuziasm și suspiciune. Frumos, sigur. Dar apoi te uiți la diferență și te întrebi: "Ok, dar ce anume s-a atins? Pot să am încredere în el? O să mai facă și mâine la fel?".
De acolo cred că începe partea interesantă. Nu atunci când agentul scrie o funcție, ci când devine suficient de capabil să preia lucrări întregi: citiți depozitul, creați un patch, rulați teste, deschideți un PR, reveniți după un comentariu de revizuire. Codex se mișcă tocmai în această direcție: lucru în fundal, arbori de lucru separat, browser integrat, automatizări, pluginuri, memorie și controale mai explicite ale permisiunilor.
Ideea este să nu ne imaginăm un viitor în care nimeni să nu mai citească cod. Ar fi un viitor teribil, precum și destul de naiv. Ideea este să vă dați seama cum să lucrați cu agenți care pot face multe fără a-i lăsa să facă totul.
Schimbarea obiceiului
Cu autocompletarea tradițională ai fost mereu la volan. AI-ul a sugerat o linie, ați decis. Cu un agent, însă, relația se schimbă: îi dai un scop și el parcurge mai mulți pași de unul singur.
Acest lucru este puternic, dar schimbă problema. Întrebarea nu mai este doar „modelul poate programa?”. Întrebarea devine:
- I-am dat o rază suficient de mică?
- știi cum să verifici rezultatul?
- Lucrez într-un mediu izolat?
- Revizuirea finală este încă umană și atentă?
Un flux de lucru sănătos arată mai mult așa decât o baghetă magică:
Sună mai puțin romantic decât „agentul construiește totul”, dar funcționează mult mai bine. Și așa funcționează echipele care sunt bune cu oamenii: sarcini clare, feedback rapid, responsabilitate explicită.
Promptul bun este aproape un bilet bun
Cel mai periculos prompt este cel vag, dar încrezător: „remediați pagina de facturi”, „îmbunătățiți arhitectura”, „curățați modulul de autentificare”. Acestea sunt cereri care sună productiv și generează diferențe uriașe. Dar apoi te trezești că faci arheologie.
Un prompt util este mai plictisitor. De exemplu: implementați exportul CSV pentru pagina de facturi, știind că tabelul este în app/(dashboard)/invoices/page.tsx, interogările sunt în src/server/invoices.ts și există deja un model similar în app/(dashboard)/reports.
Apoi adăugați constrângeri clare: nu modificați schema bazei de date, nu adăugați dependențe dacă un utilitar mic este suficient, păstrați stilul UI existent. Și închideți cu verificarea: npm test -- invoices și npm run build.
Acest tip de brief nu este pentru a „explica mai bine AI”. Servește mai presus de toate pentru a vă face mai clar ceea ce delegați. Dacă nu o poți nota în mod concret, poate că sarcina nu este încă pregătită pentru un agent.
Trei joburi pe care le deleg de bunăvoie
Prima este munca repetitivă, dar verificabilă: adăugarea de teste, migrarea apelurilor către un nou API intern, actualizarea importurilor, înlocuirea componentelor depreciate, remedierea erorilor TypeScript. Aici agentul poate economisi ore și riscul este controlabil.
Al doilea este munca de explorare: „găsește unde se calculează acest total”, „explicați-mi de ce acest test este fragil”, „reproduceți bug-ul și spuneți-mi ce fișiere par a fi afectate”. Chiar și atunci când nu produce un patch imediat, poate face recunoaștere utilă.
Al treilea este munca de întreținere recurentă: mici actualizări ale dependențelor, curățarea semnalizatoarelor vechi de caracteristici, rezumatul PR-urilor blocate, verificarea TODO uitate. Nu este plin de farmec, dar este exact genul de muncă care tinde să se adune.
Trei locuri de muncă pe care le păstrez uman
Deciziile legate de produse rămân umane. Dacă o modificare modifică modul în care un utilizator plătește, șterge date, vede prețuri sau înțelege o permisiune, vreau o persoană responsabilă.
Granițele de securitate merită, de asemenea, atenție umană: autentificare, roluri, jetoane, înregistrarea datelor sensibile, migrarea bazelor de date. Un agent poate ajuta la implementare, dar nu trebuie să fie singurul care ia decizii.
În sfârșit, păstrez tot ce necesită un gust arhitectural uman. Un agent poate propune un refactor, dar a înțelege dacă o abstracție este cu adevărat necesară sau dacă doar lustruim o problemă inexistentă rămâne o treabă.
Revizuirea nu este opțională
Tentația, când un agent este bun, este să ai încredere în verdele CI. Este de înțeles. Tot atunci încep problemele.
Mă uit întotdeauna la cel puțin cinci lucruri:
- Patch-ul rezolvă doar sarcina solicitată?
- A atins fișiere care nu aveau nicio legătură cu asta?
- Testele acoperă un comportament nou sau doar șansa fericită?
- Urmează codul tipare locale?
- Erorile sunt tratate ca în restul proiectului?
Când ceva nu este în regulă, feedback-ul trebuie să fie specific. „Remediază-l” este leneș. Mai bine: acest utilitar dublează parseMoney în src/lib/money.ts; reutilizați acea funcție, adăugați un test pentru cazul EUR și nu modificați API-ul public al modulului de facturare.
Agenții răspund mult mai bine la comentariile mici, verificabile. În mod curios, la fel și oamenii.
Balustrade merită efortul
Dacă un agent poate citi fișiere, scrie cod și executa comenzi, ar trebui tratat ca un proces puternic. Nu e nevoie de paranoia, ai nevoie de igienă.
Utilizați arbori de lucru sau ramuri separate. Așa că puteți compara diferențele, puteți arunca experimentele eșuate și nu amestecați munca agentului cu ceea ce făceai.
Limitați permisiunile. Comenzi precum rg, git diff, npm test și npm run build pot fi destul de gratuite. Implementările, migrarea bazelor de date, accesul la secrete și comenzile distructive trebuie să rămână explicite.
Reduceți accesul la rețea atunci când nu aveți nevoie de el. Pentru multe sarcini, documentația oficială, registrul pachetelor și serviciile interne specifice sunt suficiente. Mai puțină suprafață, mai puține surprize.
Urmăriți acțiunile. Când un patch ajunge în examinare, ar trebui să puteți reconstrui solicitările, comenzile executate, testele trecute și fișierele modificate. Nu pentru a crea birocrație, ci pentru a putea înțelege ce s-a întâmplat dacă ceva nu merge bine.
O modalitate ușoară de a începe ca o echipă
Dacă ar fi să introduc agenți într-o echipă mică, aș începe fără revoluții majore.
Aș crea o etichetă agent-ready pentru probleme cu domeniu clar. Aș adăuga un șablon cu context, constrângeri și comenzi de verificare. Aș cere PR mic, ideal sub câteva sute de rânduri. Aș avea nevoie de testare sau capturi de ecran pentru modificări vizibile. Și mai presus de toate aș păstra o persoană responsabilă de fuziune.
După două săptămâni m-aș uita la date: ce sarcini au fost cu adevărat accelerate, ce recenzii au fost grele, ce solicitări erau confuze, ce părți ale bazei de cod sunt prea fragile pentru a fi delegate.
Este o abordare mai puțin spectaculoasă decât „de azi vom face totul cu agenții”, dar este cea care îți permite să ajungi la a treia săptămână fără regrete.
Partea cea mai umană
Lucrul amuzant este că, cu cât agenții devin mai autonomi, cu atât abilitățile clasice redevin mai importante: scrierea unui bilet bun, efectuarea de mici tăieturi, crearea de teste, citirea diferențelor, comunicarea compromisurilor. Agentul îi accelerează pe cei care deja știu să lucreze bine. De asemenea, amplifică haosul celor care deleg prost.
Deci nu, nu văd fluxurile de lucru cu mai mulți agenți ca pe o scurtătură pentru a nu mai face inginerie. Le văd ca pe o modalitate de a transfera mai multă energie către părțile care contează: a decide ce să construiască, a se asigura că funcționează, a menține sistemul de înțeles.
Agenții pot face colegi asincroni grozavi. Dar un coleg asincron, pentru a fi util, are nevoie de context, limite și revizuire. La fel ca toți ceilalți.