Il codice lo scrive un agente: chi ne controlla il lavoro?

Si può affidare un compito a un agente, attendere le modifiche nel repository e ricevere una bozza di pull request da esaminare. Ma insieme al codice si pone una domanda: il risultato soddisfa il compito e i test hanno individuato eventuali problemi importanti?

Il 4 febbraio 2026 GitHub ha annunciato l’anteprima pubblica di Claude e Codex come agenti di coding. L’azienda ha spiegato che è possibile assegnare agli agenti compiti tramite issue e pull request, per poi esaminare la bozza di PR che preparano. Ciò conferma che questo flusso di lavoro è entrato nell’interfaccia di sviluppo, ma non dimostra né un risparmio di tempo né un miglioramento della qualità del codice.

La questione, quindi, non è soltanto se un agente sia in grado di scrivere codice. Conta anche quale lavoro debba svolgere una persona attorno al compito delegato: definire i vincoli, seguire l’avanzamento e valutare il risultato.

La supervisione non è solo una revisione finale

In un preprint pubblicato su arXiv il 21 settembre 2026, i ricercatori propongono di considerare la supervisione di un agente di coding come un processo articolato in più fasi. Lo studio The Work Behind Delegation si basa su osservazioni e schemi dei flussi di lavoro di 19 sviluppatori esperti. Gli autori descrivono sette fasi di supervisione e applicano questo modello alle discussioni pubbliche degli sviluppatori su Reddit.

Tra gli approcci descritti dagli autori ci sono dedicare maggiore attenzione alla pianificazione, affidare parte delle attività di supervisione ad altri agenti e trasformare istruzioni ricorrenti in materiali riutilizzabili. Si tratta di un quadro analitico, non di una misurazione del tempo impiegato: lo studio non stabilisce quanto tempo gli sviluppatori dedichino al controllo né se questo processo sia più rapido del lavoro manuale. La pagina di arXiv indica che il preprint è in fase di revisione, quindi i suoi risultati vanno considerati preliminari.

Per la pratica può essere utile distinguere tre attività. La definizione del compito specifica l’obiettivo e i vincoli. Il monitoraggio aiuta a rilevare se l’agente si è discostato dall’intento. La verifica permette di valutare se il risultato sia accettabile alla luce dei requisiti, del codice e dei test. Il successo in una fase non garantisce quello nella successiva: una patch può sembrare plausibile, ma affrontare il compito sbagliato o richiedere modifiche sostanziali.

L’esperienza della community non è una statistica

In una discussione su r/LocalLLaMA, un partecipante ha scritto che la sua esperienza con modelli locali e agenti è stata deludente: a suo dire, doveva correggere i risultati e ricordare agli agenti di seguire le istruzioni. Altri partecipanti allo stesso thread hanno descritto un processo per loro più utile: limitare i compiti, procedere per fasi e controllare attentamente il codice. Sono osservazioni individuali degli utenti, non un test comparativo dei modelli né una misurazione della produttività dei team.

Queste opinioni diverse mostrano che l’esperienza può dipendere dal compito, dal modello, dall’ambiente e dal modo di lavorare. Tuttavia, una sola discussione non basta a stabilire quali pratiche siano più efficaci in media né quanto spesso si verifichino problemi. Il thread riguarda i modelli locali, quindi le sue osservazioni non andrebbero estese automaticamente a tutti gli strumenti basati su agenti.

La partecipazione umana, di per sé, non significa che delegare sia inutile. Uno sviluppatore può suddividere il compito, controllare le modifiche e chiarire i requisiti, pur restando responsabile del risultato finale. Ma senza conteggiare il tempo dedicato alla definizione del compito, alle correzioni e alla revisione, non si può dire se il carico complessivo di lavoro sia diminuito.

Una bozza di PR non è ancora una PR approvata

Nello scenario descritto da GitHub, si può assegnare un’issue a un agente e ricevere una bozza di pull request. Tra la sua creazione e l’approvazione restano da affrontare varie questioni: la modifica soddisfa i requisiti? Sono stati considerati i casi limite? I test sono sufficienti? La soluzione si adatta all’architettura del progetto?

Questi criteri non si possono ridurre a un’unica metrica. Il numero di modifiche create non equivale al numero di quelle utilizzabili, e il superamento dei test non conferma necessariamente tutte le proprietà importanti di una patch. Anche un risultato che sembra di buona qualità non dice, di per sé, quanto lavoro sia stato necessario per prepararlo e verificarlo.

Per valutare l’effetto complessivo occorre considerare l’intero ciclo: definizione del compito, attesa del risultato, revisione, correzioni e manutenzione successiva del codice. Le fonti considerate non forniscono un confronto complessivo di questo tipo.

Cosa si può concludere

Il preprint propone un modello per discutere la supervisione, mentre GitHub ha presentato un flusso di lavoro in cui si assegna un compito a un agente e si esamina la PR che prepara. La discussione su Reddit mostra che alcuni utenti descrivono sia difficoltà sia metodi di lavoro utili con i modelli locali. Nel loro insieme, questi materiali permettono di chiedersi come organizzare la verifica del codice delegato, ma non chiariscono quale sia l’effetto netto sulla produttività.

Non si può concludere che gli sviluppatori, nel complesso, siano già passati dalla scrittura del codice alla supervisione, che gli agenti generino inevitabilmente lavoro aggiuntivo o che aumentino la produttività del settore. Per sostenere affermazioni del genere servono misurazioni comparabili di tempi e qualità su compiti e team diversi.

Per un team, la domanda pratica è più concreta: quali modifiche può preparare autonomamente un agente, cosa bisogna verificare prima del merge e chi è responsabile di assicurarsi che il risultato risolva il problema iniziale? Delegare non elimina questo lavoro ingegneristico: cambia il punto in cui comincia e l’attenzione che richiede.