Per gran parte della storia umana, abbiamo valutato la qualità del codice tramite code review: qualcuno legge ciò che hai scritto e si assicura che sia pulito, accurato, veloce, comprensibile e ben testato. Per gli agenti, questo approccio non scala bene; c'è semplicemente troppo codice perché qualcuno possa leggerlo. Di conseguenza, sempre più controlli di qualità devono avvenire nell'harness, nell'ambiente e nel sistema operativo attorno all'agente. Io leggo e rivedo ancora il codice, ma scelgo con cura dove mi sento a mio agio con i vincoli come controllo.
La qualità del software ora dipende dai vincoli che imposti attorno ai tuoi agenti.
La lista di Guillermo è un buon test per capire se puoi permetterti di saltare la lettura. Nota che ogni "sì" è in realtà un'affermazione su quanto siano bassi i rischi: nessun utente, codice usa-e-getta, prototipo. Quando i rischi salgono, qualcuno deve leggere il codice. Se non sei tu su ogni diff, allora devono essere i vincoli.
I vincoli definiscono ciò che il sistema può fare lanciando test e vincoli deterministici contro le proposte di un agente. È impostando e mantenendo questi vincoli che costruiamo loop che forniscono in modo affidabile software di produzione di alta qualità, anche quando gli agenti creano centinaia di migliaia o milioni di modifiche ogni singolo giorno.
Chiamiamo questi vincoli quality gate, e assumono molte forme.
Includono test unitari convenzionali, property test e test di accettazione. Includono il mutation testing, dove generiamo variazioni del codice, le eseguiamo contro gli stessi test e ci assicuriamo che le persone non stiano introducendo bug che ci sfuggono. Sono metriche sulla qualità del codice, come la complessità ciclomatica e la lunghezza delle righe, che aiutano a mantenere le cose leggibili.
Due persone possono essere in disaccordo sul fatto di leggere o meno il codice e concordare comunque sul meccanismo. Guillermo lo legge. Bob non ne legge nulla. Entrambi stanno descrivendo un percorso a ostacoli: la differenza è solo se un umano si trova al suo interno (non approvo le altre opinioni di Bob).
I vincoli giocano anche un ruolo importante su quali proposte il sistema accetterà e applicherà come modifiche al codice. Quando una proposta di modifica passa dall'interprete che esegue l'agente al controller dell'agente e poi alla produzione, abbiamo fatto abbastanza controlli su di essa per essere fiduciosi che sia sicura da distribuire e che l'impatto del suo cambiamento sia ben all'interno dell'ambito dell'agente.
Un agente può proporre qualsiasi cosa. I tuoi vincoli decidono se una proposta è abbastanza sicura, corretta, circoscritta e utile perché tu e il tuo team possiate distribuirla.
Questo modello offre molto, ma lascia fuori anche molti pezzi, e vale la pena riflettere su queste omissioni oggi. Un problema è l'autonomia; gli agenti potrebbero applicare bene le loro intenzioni, ma potrebbero fallire quando mancano informazioni o quando ciò che cercano di fare è ambiguo. Questo vale sia per il compito stesso che per il modo in cui viene parametrizzato dall'harness, dall'ambiente e da altri componenti.
Molte delle ragioni per cui gli umani non riescono a distribuire ottimo codice sono condivise con ciò che gli agenti potrebbero fare: ambienti fragili che non reggono allo stress guidato da script, build non deterministiche, permessi mancanti e test deboli. Questo motiva un ambiente migliore che dia agli agenti feedback affidabili, consenta modalità di errore a basso impatto e renda più facile costruire progressivamente il successo.
L'ambiente che cerchiamo è uno in cui un agente può fare lavoro reale, ricevere feedback di cui può fidarsi e fallire senza fare troppi danni.
L'altro problema importante è la fiducia. Non possiamo affidare ciecamente le nostre intenzioni a qualcosa di intelligente e robusto come un agente moderno senza verificarne la correttezza. Partiamo dalla fiducia, ma deve essere duramente guadagnata.
Alcuni vincoli modellano il lavoro prima che inizi. Altri danno feedback mentre l'agente lavora. Altri decidono se il suo output può attraversare il confine della produzione.
Ci sono molti modi per modellare come mettere una struttura di verifica attorno a un sistema.
Nella mia esperienza, aiuta avere un insieme più ampio, ma scelto intenzionalmente, di controlli per i tuoi vincoli invece di affidarsi esclusivamente ai test unitari. L'idea è che ogni controllo abbia una responsabilità distinta che può spaziare dalla sicurezza dei tipi e dalle prestazioni alla scansione di sicurezza in fase avanzata. Le persone possono anche definire i propri vincoli, incluse regole architetturali che strumenti di linting come ESLint possono applicare. Molti di questi strumenti hanno hook integrati che possono essere usati per coinvolgere agenti, o umani, quando le cose si rompono.
Per ora, gran parte della differenza tra output utile dell'agente e spazzatura dipende ancora dalle competenze del team che gestisce il loop.
L'IA ci offre generazione di codice ad alto volume e grande velocità, ma questo può anche significare che diventa più difficile per gli umani rivedere ogni singola modifica. Devi invece essere intenzionale su dove dirigere la loro attenzione. Se metti un controllo umano in un sistema che altrimenti si muove a velocità meccanica, non sorprenderti se questo incide sulla produttività. L'attenzione umana è scarsa e preziosa, quindi dovremmo indirizzarla proattivamente verso quei problemi più sfumati che richiedono il nostro giudizio. Gli umani a valle dovrebbero essere coinvolti solo quando i guardrail automatici dei vincoli si rompono.
La "code review" umana in futuro apparirà molto diversa
La correttezza è una dimensione importante, ma potresti preoccuparti anche di altre, come manutenibilità, prestazioni, sicurezza, efficienza e comprensibilità. Proprio come la correttezza si decompone in molti tipi di segnale, così fa il resto della qualità. E mentre conta quanti vincoli abbiamo in atto, conta ancora di più se sono abbastanza impegnativi da soddisfare il nostro standard di qualità e di prontezza alla produzione.
La qualità del software non è una metrica singola. Pensala come una raccolta di segnali di importanza variabile per te e il tuo team.
La contropressione può essere implementata attraverso molti strumenti: compilatori che rifiutano codice non valido, test che falliscono, policy di sicurezza che bloccano cattive pratiche, CI che rifiuta il deploy. Idealmente esiste in tutto il loop, non come una singola revisione alla fine di tutto il lavoro.
La mappa di Dex Horthy dello stesso loop, tratta da "Why Software Factories Fail". La casella verde è la sua tesi secondo cui, al momento, la revisione umana deve tornare nel loop piuttosto che essere sostituita da esso.
Vincoli e contropressione permettono agli agenti di intercettare il lavoro scadente prima che diventi un problema
Cosa succede se non possiamo applicare il vincolo perché il volume delle modifiche è più alto di quanto i nostri strumenti possano gestire? Finiamo per costruire una coda e affidarci a un sistema di verifica che si muove a velocità umana. Per scalare, vogliamo spingere quanto più possibile nel loop di verifica durante tutto il processo e non aspettare fino alla fine. Se possiamo scalare all'interno dei nostri controlli automatizzati, possiamo aumentare la velocità e il throughput dell'intero sistema di consegna. Se esauriamo lo spazio nel loop di verifica, dobbiamo fare una di diverse cose.
Primo, possiamo scalare il nostro sistema di verifica e creare più capacità per vincolare e respingere le modifiche in arrivo. Secondo, possiamo ridurre il ritmo con cui gli agenti generano nuove modifiche così che la verifica possa recuperare il volume di lavoro. Terzo, possiamo abbassare il nostro standard di qualità così che la verifica non respinga con la stessa forza che altrimenti potrebbe. Da una prospettiva di scalabilità, dobbiamo essere pronti a fare tutte queste cose. Allo stesso tempo, non dovremmo fermarci senza renderci conto che potremmo effettivamente ottenere di più allentando i vincoli in alcune direzioni. Forse possiamo aumentare la velocità delle modifiche generate dagli agenti fornendo sciami di agenti sviluppatori o fabbriche di software automatizzate che creano modifiche senza aspettare che ognuna venga revisionata da noi.
E in alcuni punti potremmo voler dare loro più libertà, purché manteniamo vincoli più stretti in altri. Fornendo vincoli più stretti dove ci importa di più, possiamo massimizzare il nostro throughput senza sacrificare la qualità. In queste decisioni, le opzioni sono molte. La più ovvia è il trade-off tra diverse dimensioni della qualità. Come abbiamo sottolineato, la sicurezza è molto importante, ma abbiamo anche dovuto scegliere tra fornire sicurezza e consegnare un prodotto in tempo. C'è uno spettro che va dall'attenzione all'innovazione a un'estremità all'attenzione alla qualità all'altra. Da qualche parte lungo il percorso, dobbiamo fare scelte su dove vogliamo posizionarci in quello spettro.
Vogliamo inviare feedback chiari dall'ambiente e dal sistema ai nostri agenti o team, così che le persone possano concentrarsi sulle preoccupazioni più soggettive di gusto, intento e architettura. Se possiamo aiutare gli umani a rimanere nel range sicuro dei vincoli, possiamo evitare che debbano lavorare duramente per capire dove le cose sono andate storte.
La qualità del software include più della sola correttezza. La qualità del software significa anche manutenibilità, buone prestazioni, sicurezza, efficienza ed essere facile da capire. Tutti i vincoli che ci aiutano a rispettare questi standard e a mantenere fluente la nostra produzione creano contropressione nella nostra pipeline di consegna.
Dobbiamo prendere decisioni deliberate su dove applicare vincoli forti e dove rimuoverli o allentarli. Applica vincoli forti dove servono entrambi questi obiettivi. Non mantenerli se non servono all'uno o all'altro. Sii pronto ad alzare o abbassare gli standard come il caso richiede. E ricorda che questi vincoli in diversi punti del sistema software sono ciò che rende applicabile la qualità del software.
Dovremmo applicare vincoli forti dove serviranno meglio questo duplice scopo e considerare di rimuovere o allentare i vincoli che non servono bene nessuno dei due scopi. Dovremmo anche essere pronti ad alzare o abbassare gli standard di qualità secondo necessità. In effetti, questi vincoli in vari punti del nostro sistema software sono ciò che dà i denti alla qualità. In molti casi, possiamo creare più contropressione e più vincoli implementando nuovi strumenti o rafforzando strumenti già in atto. Tutte queste cose possono essere usate per respingere la maggior parte delle richieste di modifica. Vogliamo costruirle in tutta la pipeline.
Non vogliamo aspettare la fine della pipeline, quando il nostro sistema CI si limiterà a dirci che non possiamo fare deploy senza risolvere i problemi. Vogliamo usare questi segnali il prima possibile, attraverso ogni possibile percorso. Il vincolo ultimo in questo sistema è quello che imponiamo a noi stessi: sostenere le decisioni e le azioni che abbiamo intrapreso per costruire il sistema e per gestirlo. Ma come tutti gli altri vincoli, dobbiamo fare trade-off ponderati su quanto vogliamo che il nostro stesso giudizio freni, faccia contropressione e agisca come controllo finale.
La qualità sta nei vincoli che mettiamo attorno ai nostri agenti. Quindi, mentre pensi alla qualità per le tue app, prendi questa dichiarazione del problema e crea il tuo piano guidato dai vincoli.
A proposito di qualità, gli agenti stanno scrivendo il tuo codice. Sonar ti dà i quality gate per renderlo distribuibile. Esegue lo stesso controllo completo su ogni commit: analisi approfondita cross-file, una mappa di dove vive il rischio e un quality gate che tiene ogni umano e agente allo stesso standard.
Questo articolo è stato valutato scritto al 100% da umani da Pangram 4.
