Di Kwame Boateng
La programmazione assistita dall’IA viene spesso descritta come una versione più veloce della programmazione a coppie. Ora questo paragone è troppo riduttivo. Quando un agente può esaminare un repository, modificare diversi file, eseguire strumenti, generare un’anteprima e aprire una pull request, il problema centrale della collaborazione non è più semplicemente «Sa scrivere codice?». È «Le persone possono vedere, esaminare, approvare e in seguito ricostruire ciò che è successo?»
È per questo che il cambiamento progettuale più importante nei team software assistiti da agenti potrebbe essere il passaggio dai prompt privati agli spazi di lavoro visibili. Slack Code, per esempio, viene descritto come una combinazione di canali di progetto con agenti di programmazione, audit dei diff del codice, anteprime HTML in tempo reale, flussi di feedback e approvazione, archiviazione automatica e log di audit. Anche l’app Copilot di GitHub ha aggiunto un riquadro «Il mio lavoro» per organizzare issue e pull request tra diversi progetti. Queste funzionalità indicano un principio pratico: il lavoro di un agente dovrebbe assomigliare meno a una risposta opaca e più a un insieme di modifiche che attraversa un processo di produzione controllato.
La chat non è il registro del lavoro
Una conversazione con un agente può essere utile per esplorare un’idea, ma è un sistema di registrazione poco affidabile. Dettagli importanti possono essere sepolti in un thread lungo: quali file sono cambiati, quali comandi sono stati eseguiti, quali ipotesi ha formulato l’agente, che cosa ha rifiutato un revisore e se il risultato finale differisce dalla proposta iniziale.
Uno spazio di lavoro persistente rende questi dettagli consultabili. Dovrebbe collegare la richiesta a uno specifico repository o progetto, conservare il piano dell’agente, mostrare le azioni degli strumenti e le modifiche ai file, collegare test e anteprime e registrare chi ha approvato il risultato. L’interfaccia esatta può variare—un issue tracker, una pull request, un canale di collaborazione o una console per agenti—ma le informazioni dovrebbero restare disponibili anche dopo la fine della sessione.
Questo è importante per normali ragioni ingegneristiche, non solo per motivi di conformità. Se un bug compare due settimane dopo, a un team serve più del diff finale. Potrebbe aver bisogno di conoscere il requisito originale, il piano generato, le prove fornite dai test, i commenti del revisore e se una persona ha accettato esplicitamente un compromesso rischioso. Un registro persistente abbrevia quell’indagine.
Cinque livelli di lavoro visibile
I team che adottano agenti di programmazione possono trattare ogni modifica come un piccolo fascicolo consultabile. Cinque livelli sono particolarmente utili:
- Intento: l’issue, i criteri di accettazione, i vincoli e l’ambito richiesto.
- Piano: l’approccio proposto dall’agente prima che modifichi i file. Per un’attività non banale, questo è un punto di controllo per l’approvazione, non un elemento decorativo.
- Diff: le aggiunte, eliminazioni, modifiche alle dipendenze, modifiche alla configurazione e risorse generate esatte.
- Prove: risultati dei test, output del linting, controlli di sicurezza, schermate e un’anteprima attiva o distribuibile, quando pertinente.
- Registro delle decisioni: commenti dei revisori, modifiche richieste, approvazione, rifiuto, rollback o attività successive.
Lo scopo non è costringere ogni modifica a passare attraverso un comitato pesante. Un refuso e una modifica al flusso di pagamento non dovrebbero avere controlli identici. L’obiettivo è rendere il livello di scrutinio proporzionale al potenziale impatto.
Le approvazioni dovrebbero essere legate alle azioni
«Human in the loop» è un’espressione troppo vaga per costituire un controllo utile. Una persona potrebbe approvare un piano senza vedere il diff risultante, oppure approvare una modifica al codice senza accorgersi che l’agente ha modificato anche un file di deployment. Flussi di lavoro migliori specificano che cosa consente l’approvazione.
Per esempio, un team potrebbe consentire a un agente di leggere un repository ed eseguire automaticamente test locali, richiedere un’approvazione prima della scrittura al di fuori di un branch designato e richiedere un’approvazione separata prima del merge o del deployment. Un agente potrebbe proporre una migrazione del database, ma non essere autorizzato a eseguirla in produzione. L’approccio proposto dagli Emirati Arabi Uniti per classificare quali attività gli agenti possono completare e quali possono soltanto raccomandare riflette questo schema più ampio: l’autonomia dovrebbe essere assegnata per attività, non presunta a livello globale.
Anche le approvazioni devono avere un ambito e una scadenza. Un’approvazione per «aggiornare il testo della landing page» non dovrebbe autorizzare silenziosamente un nuovo pacchetto di analytics. Un piano approvato ieri non dovrebbe coprire automaticamente un diff sostanzialmente modificato oggi. L’interfaccia dovrebbe rendere visibili questi confini.
Le anteprime trasformano la revisione in un’ispezione
La revisione del codice è spesso più semplice quando le persone possono esaminare il risultato invece di dedurlo dai file sorgente. Un’anteprima HTML in tempo reale può rivelare spaziature errate, stati mancanti, controlli inaccessibili o una modifica involontaria nella navigazione che un revisore potrebbe trascurare in un diff testuale.
Le anteprime non dimostrano che qualcosa sia corretto. Dovrebbero affiancare, non sostituire, i test e la revisione del codice sorgente. Ma creano un oggetto comune di discussione: un revisore può indicare una schermata, uno stato o un’interazione specifici e lasciare un feedback associato alla modifica proposta.
Questo è particolarmente prezioso quando alla revisione partecipano persone non specializzate. Un product manager potrebbe non essere in grado di valutare una modifica al framework, ma potrebbe essere la persona giusta per confermare che il flusso di lavoro rispetti il requisito. Un designer può convalidare una regressione visiva. Uno specialista della sicurezza può concentrarsi sulle autorizzazioni e sulla gestione dei dati. Lo spazio di lavoro assistito dall’agente può indirizzare ogni domanda alla persona più adatta a rispondere.
I diff hanno bisogno di contesto, non solo di colori
Il familiare diff rosso e verde rimane essenziale, ma le modifiche generate dagli agenti possono essere abbastanza ampie da sopraffare un revisore. I team dovrebbero chiedere agli agenti di mantenere ristretti i commit o i gruppi di modifiche, spiegare perché è cambiato ogni file sostanziale e identificare separatamente i file generati o dei vendor.
Tra i suggerimenti utili per la revisione figurano:
- Quale comportamento visibile all’utente è cambiato?
- Quali file sono stati modificati esclusivamente per supportare l’implementazione?
- Quali supposizioni ha fatto l’agente sul comportamento esistente?
- Quali test sono stati aggiunti, modificati o non eseguiti?
- Questa modifica potrebbe influire sulle autorizzazioni, sulla conservazione dei dati, sulla fatturazione o sulle API esterne?
Queste domande trasformano la revisione da una richiesta vaga come «dacci un’occhiata» in un esame ripetibile. Aiutano inoltre a far emergere una modalità comune di fallimento: una funzionalità plausibile accompagnata da un aggiornamento incompleto dei test o da una modifica accidentale della configurazione.
Archiviare il ragionamento che conta
Preservare ogni token di ogni conversazione con un modello non è automaticamente utile. Le cronologie lunghe possono essere costose da archiviare e difficili da cercare, mentre la ricerca sulla compattazione del contesto avverte che i riepiloghi possono perdere informazioni importanti. Un audit trail pratico dovrebbe quindi preservare gli artefatti rilevanti per le decisioni, invece di salvare indiscriminatamente tutto.
Come minimo, conserva la richiesta, il piano approvato, il diff finale, i risultati degli strumenti e dei test, il riferimento all’anteprima o al deployment, le decisioni dei revisori e qualsiasi eccezione concessa. Se un agente ha utilizzato fonti esterne o recuperato documenti interni, registra i riferimenti alle fonti pertinenti e il momento in cui hanno orientato la modifica. Per il lavoro ad alto rischio, può essere giustificato conservare l’intero log delle interazioni e dell’esecuzione.
Rendi i documenti evidenti rispetto a eventuali manomissioni quando la posta in gioco lo richiede e definisci le regole di conservazione prima che si verifichi una crisi. Un audit trail che scompare quando un canale viene archiviato — o che non è in grado di distinguere un risultato modificato dall’originale — non sosterrà un’indagine seria.
Cosa cambia per le carriere nel software
La competenza emergente non consiste semplicemente nello scrivere prompt migliori. Consiste nel progettare un lavoro che un’altra persona possa ispezionare e considerare affidabile. Gli sviluppatori dovranno sentirsi a proprio agio nello specificare i criteri di accettazione, scomporre le attività, esaminare diff su larga scala, creare test significativi e decidere dove un agente debba fermarsi e chiedere.
I professionisti di prodotto e design avranno un ruolo maggiore nella revisione delle anteprime e nella chiarificazione dell’intento. Gli ingegneri QA possono contribuire a definire i gate di approvazione e i casi di errore. I responsabili dell’ingegneria dovranno misurare la produttività senza premiare l’assunzione invisibile di rischi. Gli technical writer e gli specialisti delle operations possono contribuire rendendo durature le decisioni, le eccezioni e i runbook.
Un esercizio utile consiste nel prendere una funzionalità di routine e tracciarne la catena delle evidenze: richiesta, piano, branch, diff, test, anteprima, approvazione, rilascio e rollback. Poi chiediti dove un futuro collega sarebbe costretto a tirare a indovinare. Ogni supposizione è candidata a uno workspace migliore, a un’autorizzazione più chiara o a un documento più duraturo.
Una semplice regola operativa
Lascia che gli agenti si muovano rapidamente all’interno di un percorso visibile e reversibile. Assegna loro uno workspace definito, limita le azioni sensibili, richiedi l’approvazione nei passaggi significativi, associa le evidenze alla modifica e conserva la decisione finale. L’obiettivo non è rallentare l’automazione finché non assomigli alla programmazione manuale. È rendere la velocità compatibile con la responsabilità.
Nello sviluppo assistito da agenti, il miglior collaboratore non è il sistema che produce più codice operando in isolamento. È il sistema il cui lavoro può essere compreso, messo in discussione, approvato, annullato e da cui si può imparare.
