De Kwame Boateng
Programarea asistată de inteligența artificială este adesea descrisă drept o versiune mai rapidă a programării în pereche. Acum, comparația este prea limitată. Când un agent poate inspecta un depozit de cod, modifica mai multe fișiere, rula instrumente, genera o previzualizare și deschide un pull request, problema centrală a colaborării nu mai este pur și simplu „Poate să scrie cod?”. Este „Pot oamenii să vadă, să verifice, să aprobe și, ulterior, să reconstituie ce s-a întâmplat?”
Acesta este motivul pentru care cea mai importantă schimbare de design în echipele software asistate de agenți ar putea fi trecerea de la prompturi private la spații de lucru vizibile. Slack Code, de exemplu, este descris ca reunind canale de proiect cu agenți de programare, auditarea diferențelor de cod, previzualizări HTML live, fluxuri de feedback și aprobare, arhivare automată și jurnale de audit. Aplicația Copilot de la GitHub a adăugat, de asemenea, un panou „My work” pentru organizarea problemelor și a pull request-urilor în cadrul proiectelor. Aceste funcții indică un principiu practic: activitatea unui agent ar trebui să semene mai puțin cu un răspuns opac și mai mult cu un set de modificări care trece printr-un proces de producție controlat.
Chatul nu este registrul activității
O conversație cu un agent poate fi utilă pentru explorarea unei idei, dar este un sistem slab de evidență. Detalii importante se pot pierde într-un fir lung: ce fișiere s-au modificat, ce comenzi au fost rulate, ce presupuneri a făcut agentul, ce a respins un evaluator și dacă rezultatul final diferă de prima propunere.
Un spațiu de lucru persistent face aceste detalii verificabile. Ar trebui să conecteze solicitarea la un depozit de cod sau proiect specific, să păstreze planul agentului, să afișeze acțiunile instrumentelor și modificările fișierelor, să conțină linkuri către teste și previzualizări și să înregistreze cine a aprobat rezultatul. Interfața exactă poate varia—un sistem de urmărire a problemelor, un pull request, un canal de colaborare sau o consolă pentru agenți—dar informațiile ar trebui să rămână disponibile și după încheierea sesiunii.
Acest lucru contează din motive obișnuite de inginerie, nu doar pentru conformitate. Dacă apare o eroare două săptămâni mai târziu, o echipă are nevoie de mai mult decât diferența finală. Poate avea nevoie să cunoască cerința inițială, planul generat, dovezile testării, comentariile evaluatorului și dacă un om a acceptat explicit un compromis riscant. O evidență persistentă scurtează această investigație.
Cinci niveluri ale activității vizibile
Echipele care adoptă agenți de programare pot trata fiecare modificare ca pe un mic dosar de caz, care poate fi inspectat. Cinci niveluri sunt deosebit de utile:
- Obiectiv: problema, criteriile de acceptare, constrângerile și domeniul solicitat.
- Plan: abordarea propusă de agent înainte de modificarea fișierelor. Pentru o sarcină care nu este trivială, acesta este un punct de verificare pentru aprobare, nu un element decorativ.
- Diferență: adăugirile, ștergerile, modificările dependențelor, editările configurației și resursele generate, toate în forma exactă.
- Dovezi: rezultatele testelor, rezultatele lintării, verificările de securitate, capturile de ecran și o previzualizare live sau care poate fi implementată, acolo unde este relevant.
- Registrul deciziei: comentariile evaluatorilor, modificările solicitate, aprobarea, respingerea, revenirea la o versiune anterioară sau activitatea ulterioară.
Ideea nu este să oblige fiecare modificare să treacă printr-un comitet greoi. O greșeală de scriere și o modificare a fluxului de plată nu ar trebui să aibă controale identice. Ideea este ca nivelul de verificare să fie proporțional cu impactul potențial.
Aprobările ar trebui legate de acțiuni
„Omul în buclă” este prea vag pentru a fi un control util. O persoană ar putea aproba un plan fără să vadă diferența rezultată sau ar putea aproba o modificare de cod fără să observe că agentul a modificat și un fișier de implementare. Fluxurile de lucru mai bune precizează ce permite aprobarea.
De exemplu, o echipă ar putea permite unui agent să citească un depozit de cod și să ruleze automat teste locale, să solicite aprobare înainte de a scrie în afara unei ramuri desemnate și să solicite o aprobare separată înainte de îmbinare sau implementare. Un agent ar putea propune o migrare a bazei de date, dar să nu aibă permisiunea de a o executa în producție. Abordarea propusă de EAU pentru clasificarea sarcinilor pe care agenții le pot finaliza în raport cu cele pe care le pot doar recomanda reflectă acest tipar mai larg: autonomia ar trebui atribuită pe sarcini, nu presupusă la nivel global.
Aprobările au nevoie, de asemenea, de un domeniu de aplicare și de o dată de expirare. O aprobare pentru „actualizarea textului paginii de destinație” nu ar trebui să autorizeze în mod tacit adăugarea unui nou pachet de analiză. Un plan aprobat ieri nu ar trebui să acopere automat o diferență modificată substanțial astăzi. Interfața ar trebui să facă vizibile aceste limite.
Previzualizările transformă verificarea în inspecție
Verificarea codului este adesea mai ușoară când oamenii pot inspecta rezultatul, în loc să-l deducă din fișierele sursă. O previzualizare HTML live poate scoate la iveală spațieri incorecte, stări lipsă, controale inaccesibile sau o modificare neintenționată a navigării, pe care un evaluator ar putea să o treacă cu vederea într-o diferență textuală.
Previzualizările nu reprezintă o dovadă a corectitudinii. Ele ar trebui să fie alături de teste și de verificarea sursei, nu să le înlocuiască. Dar creează un obiect comun pentru discuție: un evaluator poate indica un anumit ecran, o anumită stare sau interacțiune și poate lăsa feedback atașat modificării propuse.
Acest lucru este deosebit de valoros atunci când în verificare sunt implicați și nespecialiști. Un manager de produs poate să nu fie capabil să evalueze o modificare a frameworkului, dar poate fi persoana potrivită pentru a confirma că fluxul corespunde cerinței. Un designer poate valida o regresie vizuală. Un specialist în securitate se poate concentra pe permisiuni și pe gestionarea datelor. Spațiul de lucru asistat de agenți poate direcționa fiecare întrebare către persoana cea mai potrivită pentru a răspunde.
Diferențele au nevoie de context, nu doar de culori
O diferență familiară, cu roșu și verde, rămâne esențială, dar modificările generate de agenți pot fi suficient de ample pentru a copleși un evaluator. Echipele ar trebui să le ceară agenților să păstreze commiturile sau grupurile de modificări restrânse, să explice de ce s-a modificat fiecare fișier substanțial și să identifice separat fișierele generate sau furnizate de terți.
Întrebările utile pentru evaluare includ:
- Ce comportament vizibil pentru utilizator s-a schimbat?
- Ce fișiere au fost modificate doar pentru a sprijini implementarea?
- Ce presupuneri a făcut agentul cu privire la comportamentul existent?
- Ce teste au fost adăugate, modificate sau nu au fost rulate?
- Ar putea această modificare să afecteze permisiunile, păstrarea datelor, facturarea sau API-urile externe?
Aceste întrebări transformă evaluarea dintr-o solicitare vagă de tipul „aruncă o privire” într-o examinare repetabilă. De asemenea, ele ajută la scoaterea la iveală a unei erori frecvente: o funcționalitate plauzibilă însoțită de actualizarea incompletă a testelor sau de o modificare accidentală a configurației.
Arhivați raționamentul care contează
Păstrarea fiecărui token din fiecare conversație cu un model nu este automat utilă. Istoriile lungi pot fi costisitoare de stocat și dificil de căutat, iar cercetările privind compactarea contextului avertizează că rezumatele pot pierde informații importante. Prin urmare, o pistă practică de audit ar trebui să păstreze artefactele relevante pentru decizii, nu să salveze totul fără discernământ.
Cel puțin, păstrați cererea, planul aprobat, diff-ul final, rezultatele instrumentelor și testelor, referința pentru previzualizare sau implementare, deciziile evaluatorilor și orice excepție acordată. Dacă un agent a folosit surse externe sau a preluat documente interne, înregistrați referințele relevante la surse și momentul în care acestea au influențat modificarea. Pentru activitățile cu risc ridicat, păstrarea interacțiunii și a jurnalului complet de execuție poate fi justificată.
Faceți înregistrările evidente în cazul modificărilor neautorizate acolo unde miza o impune și definiți regulile de păstrare înainte de apariția unei crize. O pistă de audit care dispare atunci când un canal este arhivat — sau care nu poate face distincția între un rezultat modificat și cel original — nu va susține o investigație serioasă.
Ce schimbă acest lucru pentru carierele din software
Competența emergentă nu constă doar în redactarea unor prompturi mai bune. Ea constă în proiectarea unei activități pe care o altă persoană o poate inspecta și în care poate avea încredere. Dezvoltatorii vor trebui să se simtă confortabil în a defini criterii de acceptare, a descompune sarcini, a evalua diff-uri la scară largă, a construi teste relevante și a decide unde un agent trebuie să se oprească și să întrebe.
Profesioniștii din produs și design vor avea un rol mai important în evaluarea previzualizărilor și clarificarea intenției. Inginerii QA pot contribui la definirea etapelor de aprobare și a cazurilor de eșec. Managerii de inginerie vor trebui să măsoare capacitatea de livrare fără a recompensa asumarea unor riscuri invizibile. Redactorii tehnici și specialiștii în operațiuni pot contribui făcând ca deciziile, excepțiile și ghidurile operaționale să fie durabile.
Un exercițiu util este să luați o funcționalitate obișnuită și să-i cartografiați lanțul de dovezi: cerere, plan, ramură, diff, teste, previzualizare, aprobare, lansare și revenire. Apoi întrebați-vă unde un viitor coleg ar fi obligat să ghicească. Fiecare presupunere este un candidat pentru un spațiu de lucru mai bun, o permisiune mai clară sau o înregistrare mai durabilă.
O regulă operațională simplă
Lăsați agenții să se miște rapid într-un spațiu vizibil și reversibil. Oferiți-le un spațiu de lucru definit, restricționați acțiunile sensibile, solicitați aprobare la limite importante, atașați dovezi modificării și păstrați decizia finală. Obiectivul nu este să încetiniți automatizarea până când aceasta seamănă cu programarea manuală. Este să faceți viteza compatibilă cu responsabilitatea.
În dezvoltarea asistată de agenți, cel mai bun colaborator nu este sistemul care produce cel mai mult cod în mod izolat. Este sistemul a cărui activitate poate fi înțeleasă, contestată, aprobată, anulată și folosită pentru a învăța.
