AI per programmare: come delegare il lavoro agli agenti

Per chi guida un team di sviluppo, il punto di partenza è un'attività circoscritta su un branch isolato, con criteri di accettazione espliciti, controlli automatici e un revisore designato. L'autonomia può aumentare quando questo processo produce modifiche che si possono accettare con fiducia.

Il comportamento degli strumenti descritto qui è stato verificato sulla documentazione ufficiale disponibile online il 24 ottobre 2026. Le regole di delega e l'esempio dell'esportazione delle fatture sono un'analisi editoriale, non i risultati di una prova dei prodotti.

AI per programmare: che cos'è l'agentic coding?

Nella programmazione agentica, un sistema di AI si fa carico di una sequenza di attività di sviluppo, usando l'esito di ciascun passaggio per decidere il successivo. Esamina il codice del progetto, pianifica una modifica, interviene sui file, esegue comandi e test, legge i risultati e adatta l'azione seguente. Una sessione può fermarsi quando il lavoro è concluso, quando raggiunge un limite dei permessi o quando serve una decisione.

Anthropic descrive questo ciclo come raccolta del contesto, azione e verifica. Il passaggio decisivo consiste nel riportare l'esito di uno strumento nella decisione successiva: un test fallito diventa un elemento su cui basare una nuova modifica. Un semplice blocco di codice suggerito non offre questo ciclo. Il ciclo agentico di Claude Code.

Pensa a un'impresa incaricata di ristrutturare una stanza. Le istruzioni definiscono il risultato, le chiavi determinano dove può entrare e il sopralluogo finale stabilisce se il lavoro è accettabile. Consegnare più chiavi non rende corretta la ristrutturazione. Anche gli agenti di programmazione richiedono questa separazione tra istruzioni, accesso e verifica.

Un agente ha bisogno anche di un harness, il software che circonda il modello, gli mette a disposizione gli strumenti e gestisce il contesto di lavoro. Il modello propone le azioni; l'harness esegue le chiamate agli strumenti consentite e ne restituisce i risultati. Cambiare modello non modifica automaticamente le regole di accesso dell'ambiente.

Che cosa cambia rispetto al completamento automatico e alla chat?

La differenza è chi porta avanti il lavoro tra un passaggio e l'altro. Il completamento automatico suggerisce testo mentre scrivi. Una normale conversazione in chat può spiegare il codice o proporre una patch, lasciando a te il compito di copiarla, eseguirla e validarla. Un agente con accesso al repository e ai comandi può svolgere questi passaggi e controllarne l'esito.

Non è l'interfaccia a definire un agente: può funzionare sia in una finestra di chat sia in un terminale. Conta quali strumenti ha a disposizione, come usa i risultati delle azioni precedenti e quale autorità è stata concessa alla sessione.

Agentic coding e vibe coding: qual è la differenza?

L'agentic coding descrive il funzionamento dello strumento. Il vibe coding indica comunemente un modo di lavorare in cui si guida la creazione del software soprattutto attraverso prompt e osservazione del comportamento, talvolta controllando poco l'implementazione. Nella pratica i due concetti si sovrappongono, ma rispondono a domande diverse.

Puoi usare un agente esaminando ogni modifica e mantenendo test rigorosi. Puoi anche accettare il codice generato quasi senza controllarlo. Per un prototipo usa e getta, questa seconda scelta può essere un compromesso consapevole. Quando entrano in gioco dati dei clienti o pagamenti, capire l'implementazione resta parte della responsabilità sul software. La guida agli strumenti di vibe coding presenta il panorama più ampio delle piattaforme per creare applicazioni e degli strumenti di programmazione.

Che cosa possono fare gli strumenti di programmazione agentica?

Gli strumenti principali offrono un ciclo di azioni simile, attraverso ambienti di lavoro diversi. Le funzionalità documentate indicano che cosa puoi delegare; non dicono quanto lavoro senza supervisione il tuo repository possa sostenere.

Claude Code

Claude Code, l'agente di programmazione di Anthropic, può effettuare ricerche in un progetto, leggere e modificare file, eseguire comandi e lanciare test. La documentazione descrive un ciclo che cambia direzione in base a ciò che emerge dai risultati di ogni strumento. La correzione di un bug ben circoscritto è quindi un incarico naturale: indagare sul problema, modificare il codice interessato e verificarne il comportamento. Documentazione di Claude Code.

Il limite pratico è il contesto mancante o dimenticato. Anthropic documenta una finestra di contesto finita e la sua compattazione durante le sessioni lunghe. Conserva i vincoli permanenti nelle istruzioni del progetto e mantieni ogni modifica ben delimitata: una lunga conversazione non sostituisce un criterio di accettazione. La nostra guida alle buone pratiche per Claude Code approfondisce questo metodo di lavoro.

OpenAI Codex

OpenAI Codex, l'agente di programmazione di OpenAI, offre un'interfaccia a riga di comando (CLI) con cui esaminare un repository, pianificare una modifica, intervenire sui file ed eseguire comandi di sviluppo in locale. Include anche una procedura di revisione dedicata alle modifiche non ancora registrate in un commit, a un singolo commit o al confronto con un branch di base. Documentazione di Codex CLI.

Il limite pratico è l'ambiente di esecuzione. Un controllo che richiede un servizio non disponibile o un accesso alla rete bloccato non può fornire le prove previste. Segnalo come non verificato, poi ripetilo nell'ambiente adatto. Il confronto tra Codex e Claude Code aiuta a scegliere il prodotto; la configurazione dei permessi richiede una decisione a sé.

Cursor Agent

Cursor Agent, l'agente di programmazione integrato nell'editor Cursor, può cercare nel codice del progetto, modificare file ed eseguire comandi nel terminale. Si presta a un lavoro interattivo, in cui orienti la modifica mentre ne esamini lo sviluppo. Si tratta di azioni documentate, non della promessa che una funzionalità sarà corretta. Panoramica di Cursor Agent.

È importante capire quali azioni hanno effetto immediato: le normali modifiche ai file nell'area di lavoro vengono salvate su disco senza approvazione, mentre quelle ai file di configurazione hanno protezioni aggiuntive. Cursor avverte che un'applicazione con ricaricamento automatico può eseguire il codice modificato prima che tu lo abbia esaminato. Usa un ambiente di sviluppo con credenziali e dati adatti a questo comportamento. Sicurezza di Cursor Agent.

L'agente di programmazione di GitHub Copilot

L'agente di programmazione di GitHub Copilot, chiamato Copilot cloud agent nella documentazione attuale, può esplorare un repository, pianificare modifiche, intervenire sui file ed eseguire test e linter in un ambiente cloud temporaneo. Può preparare branch, commit e pull request. È un uso distinto dal ricevere suggerimenti nell'IDE o dal chiedere a Copilot di rivedere una pull request esistente. Copilot su GitHub.com.

Il limite pratico emerge nel passaggio alla revisione. GitHub avverte che le modifiche generate possono essere inesatte o insicure e richiedono revisione e test. Una sessione conclusa indica che c'è un lavoro da valutare, non che i criteri di accettazione siano stati soddisfatti. Indicazioni di GitHub per un uso responsabile.

Per i dettagli sui piani, consulta le nostre pagine sui prezzi di Claude Code, sui prezzi di Codex, sui prezzi di Cursor e sui prezzi di GitHub Copilot.

Per programmare con AI serve una specifica verificabile

Una specifica utile chiarisce che cosa deve restare invariato, oltre a ciò che deve cambiare. «Aggiungi l'esportazione in CSV» lascia aperte decisioni essenziali. Un agente può produrre un download funzionante applicando regole di accesso sbagliate.

Immagina un prodotto di fatturazione usato da organizzazioni clienti distinte. Vuoi consentire a un amministratore dell'account di esportare le fatture. Un incarico ben definito dovrebbe specificare:

• Risultato: un amministratore autorizzato può scaricare le fatture visibili con i filtri attualmente applicati.
• Regola di accesso: un'organizzazione non deve mai ricevere le fatture di un'altra, nemmeno attraverso una richiesta manipolata.
• Comportamento da preservare: i permessi e i filtri esistenti sulle fatture continuano a determinare l'accesso.
• Ambito: riutilizzare le convenzioni esistenti per autorizzazione ed esportazione; evitare refactoring o dipendenze estranei all'incarico.
• Prove: mostrare i casi di accesso consentito e negato, un tentativo di accesso ai dati di un'altra organizzazione, un risultato vuoto e i controlli esistenti pertinenti.
• Condizione di arresto: chiedere una decisione se la politica di accesso è ambigua o se la correzione richiede di modificare il comportamento della logica di autorizzazione condivisa.

Queste indicazioni lasciano aperte le scelte di implementazione, ma fissano il comportamento atteso del prodotto. Se durante il lavoro emerge una regola mancante, definiscila e aggiorna la specifica. Non lasciare che una scelta accidentale nell'implementazione diventi una regola implicita. La nostra guida allo sviluppo guidato dalle specifiche spiega come mantenere questo rapporto.

La documentazione sulle buone pratiche di Anthropic raccomanda di dare all'agente un modo per verificare il proprio lavoro. Nei suoi consigli basati sull'esperienza pratica, Armin Ronacher sottolinea l'importanza di strumenti rapidi e comprensibili e di log utili. La lezione operativa è rendere osservabili gli errori: un errore di autorizzazione leggibile aiuta l'agente a correggere il lavoro; un comando che resta bloccato offre poche indicazioni.

Permessi e sandbox impongono limiti diversi

I permessi regolano le azioni consentite; la sandbox ne limita la portata; le regole sui branch e sulla revisione disciplinano l'accettazione delle modifiche. Configura tutti questi controlli. Un prompt che dice «non toccare la produzione» non sostituisce la rimozione dell'accesso alla produzione.

Una politica di approvazione stabilisce quali azioni richiedono un'autorizzazione. Una sandbox impone confini di esecuzione sulle risorse, per esempio sui file scrivibili e sull'accesso alla rete in uscita. Nessuna delle due valuta se l'esportazione delle fatture rispetti le regole del tuo prodotto.

Controlla le impostazioni effettive di ogni strumento

Per Claude Code, Anthropic documenta l'isolamento del filesystem e della rete per i comandi eseguiti nella sandbox, inclusi i relativi sottoprocessi. Documenta anche un meccanismo per ritentare l'esecuzione fuori dalla sandbox. Prima di considerare quel confine inderogabile, esamina questa possibilità di uscita, i comandi esclusi e ciò che accade quando la sandbox non riesce ad avviarsi. Limitare le scritture non implica automaticamente che i file sensibili non possano essere letti. La sandbox di Claude Code.

Per Codex CLI, workspace-write con approvazioni on-request consente di lavorare nell'area di lavoro, mentre l'accesso alla rete da parte dei comandi è disattivato per impostazione predefinita, salvo abilitazione esplicita. La politica di approvazione e la modalità della sandbox sono impostazioni separate: disattivare le richieste di approvazione non rimuove di per sé la sandbox. Inoltre, la politica di rete dei comandi non governa da sola la ricerca web ospitata, le app o le connessioni MCP, che collegano l'agente a strumenti e servizi esterni. Esamina separatamente queste vie di accesso. Approvazioni e sicurezza in Codex.

Per Cursor Agent, i comandi del terminale richiedono approvazione per impostazione predefinita, mentre le modalità configurabili Run Modes sono descritte come protezioni che cercano di limitare il rischio senza costituire un confine di sicurezza rigido. La distinzione conta se prevedi di lasciare eseguire i comandi senza supervisione. Considera anche l'avvertenza sul ricaricamento automatico citata prima, oltre all'esecuzione nel terminale. Sicurezza di Cursor Agent.

Per GitHub Copilot cloud agent, GitHub documenta permessi limitati sui branch che impediscono il push diretto sul branch predefinito. Documenta inoltre un firewall attivo per impostazione predefinita e l'approvazione di un utente con accesso in scrittura prima dell'esecuzione dei workflow di Actions attivati dalle pull request dell'agente. I segreti generali di Actions a livello di repository e organizzazione non vengono trasmessi all'agente; quelli aggiunti espressamente all'ambiente copilot sì. Controlla che cosa inserisci in quell'ambiente. Le protezioni documentate da GitHub.

Adatta i limiti all'incarico

Per l'esportazione delle fatture, all'agente servono il codice sorgente, le dipendenze di sviluppo e fatture sintetiche. Non dovrebbero servirgli fatture reali dei clienti, credenziali del database di produzione o l'autorità per effettuare il deploy. Concedi solo l'accesso alle risorse necessario per riprodurre e verificare il comportamento.

Tratta i testi del repository, le pagine recuperate e il contenuto delle issue come input potenzialmente non affidabili. Si parla di prompt injection quando un contenuto malevolo tenta di deviare le azioni dell'agente. Un'istruzione nascosta in un documento non deve acquisire l'autorità dell'incarico che hai assegnato. Le indicazioni di sicurezza dei produttori riconoscono questo rischio; limitare le risorse accessibili ne riduce le possibili conseguenze. Il modello di sicurezza di Cursor.

Come fare la revisione: esamina il diff e le prove

Esamina il comportamento modificato e i controlli che dovrebbero dimostrarne la correttezza. Il riepilogo dell'agente è utile per orientarsi, ma non è il lavoro che stai approvando.

Parti dai criteri di accettazione. Per l'esportazione delle fatture, segui il percorso con cui viene identificata l'organizzazione della richiesta, verificata l'autorizzazione e applicato lo stesso limite nella query di esportazione. Poi esamina i test. Un test che usa soltanto i dati di un'organizzazione non può dimostrare la separazione tra organizzazioni.

Cerca quindi i punti in cui la patch potrebbe aver indebolito le verifiche: asserzioni eliminate, test ora saltati, mock più estesi, snapshot modificati o cambiamenti alla configurazione CI. Una suite di test può passare perché l'implementazione è migliorata oppure perché il controllo è diventato meno esigente. Il diff permette di capire quale delle due cose sia successa.

Da un checkout del repository con modifiche non ancora registrate in un commit, questi comandi Git consentono un'ispezione di base:

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

git status mostra anche i file non tracciati, il cui contenuto va esaminato separatamente. Questi comandi non eseguono i test dell'applicazione. Se il lavoro dell'agente è già stato registrato in commit, esamina l'intero diff della pull request, dalla base alla versione finale, ed esegui i controlli documentati dal repository in un ambiente pulito.

Un passaggio alla revisione utile include i comandi esatti eseguiti, i loro esiti, l'output significativo di successo o errore e ogni controllo che non è stato possibile effettuare. Dire «i test passano» senza indicare quali lascia al revisore il compito di indovinarne la copertura. Una configurazione dell'ambiente non riuscita impedisce di ottenere prove; non dimostra che il codice funzioni.

In 10 lezioni sull'agentic coding, Drew Breunig sostiene l'importanza di test sul comportamento del prodotto, intenzioni documentate e specifiche che evolvono con l'implementazione. Applicato a questo esempio, il controllo da mantenere nel tempo è che un cliente non possa esportare le fatture di un altro. La particolare funzione di supporto usata per far rispettare la regola può cambiare.

Una revisione automatica può fornire ulteriori segnalazioni, ma chi accetta la modifica deve comprenderne i passaggi critici. GitHub avverte esplicitamente che la revisione tramite AI può non rilevare alcuni problemi e produrre falsi positivi. Affida a un revisore umano la responsabilità dei comportamenti rilevanti per la sicurezza e della manutenibilità. I limiti della revisione secondo GitHub.

Chi può delegare di più e chi dovrebbe aspettare?

Delega di più quando il risultato atteso è chiaro, gli errori restano circoscritti e la revisione è gestibile. Quella che segue è una proposta di politica di sviluppo, non una garanzia sulle capacità offerta da un produttore.

Chi guida un team con una CI affidabile può iniziare subito. Parti da modifiche che seguono schemi già presenti. Assegna un responsabile a ogni pull request generata dall'agente e riduci la dimensione degli incarichi se diventa difficile valutarli durante la revisione. I controlli superati sono utili solo se coprono i comportamenti che contano.

Chi sta fondando un'azienda e costruisce un prototipo può delegare ampiamente l'implementazione in un ambiente usa e getta. Usa dati sintetici e accetta che il codice esplorativo possa essere sostituito. Prima di introdurre account dei clienti o trasferimenti di denaro, coinvolgi qualcuno in grado di valutare le regole di accesso, la gestione degli errori e le conseguenze operative.

Chi mantiene un sistema legacy poco conosciuto dovrebbe prima rafforzare le verifiche. Un agente può aiutare a indagare il comportamento e proporre test, ma il refactoring senza supervisione è un punto di partenza debole quando nessuno sa distinguere il comportamento voluto da quello accidentale. Chiarisci lo stato iniziale prima di ampliare l'autonomia.

Chi si trova già bene con il completamento automatico non deve cambiare approccio per ogni attività. Una modifica piccola ed evidente può essere più rapida da fare direttamente. Il costo della delega si giustifica quando c'è una sequenza significativa di indagine, modifica e verifica da affidare all'agente.

Dove si inceppa e quali promesse sono eccessive

Il ciclo si inceppa quando i risultati che lo guidano non permettono di distinguere una soluzione corretta da una soltanto plausibile. Un controllo superato può confermare la formattazione senza dire nulla sull'isolamento dei tenant, cioè sulla separazione dei dati di clienti diversi. Un test con mock può passare senza verificare l'integrazione usata dai clienti. Un riepilogo convincente può omettere un comando fallito.

Il contesto introduce un altro limite. L'agente può vedere la funzione pertinente senza cogliere il motivo di un vincolo insolito. Tieni le decisioni rilevanti vicino al lavoro, indica quale specifica fa fede e chiedi che le incertezze vengano esplicitate. La documentazione di Anthropic descrive come le sessioni lunghe gestiscono un contesto finito: non dare per scontato che un'istruzione impartita all'inizio della conversazione mantenga lo stesso rilievo per tutta una modifica estesa. Come funziona Claude Code.

Più agenti comportano anche più lavoro di coordinamento. Se sessioni separate modificano gli stessi file, la stessa interfaccia o lo stesso stato del database, un risultato corretto in locale può comunque entrare in conflitto con un'altra modifica. Usa checkout separati e assegna esplicitamente la responsabilità dell'integrazione. Inizia a parallelizzare le indagini indipendenti prima di farlo con implementazioni strettamente interdipendenti.

Il fallimento più ampio consiste nell'accettare una complessità che nessuno intendeva mantenere. Una nuova astrazione, una dipendenza o un processo in background diventano una tua responsabilità operativa, anche se generarli è stato facile. Chiediti se la modifica risolve l'incarico introducendo una quantità di nuovi meccanismi proporzionata al problema.

Che cosa non dimostrano i benchmark di agentic coding?

Un benchmark di programmazione, da solo, non dimostra quanto migliorerà la capacità del tuo team di consegnare software. Per applicare un risultato pubblicato dovresti conoscere le attività, il contesto del repository, gli strumenti, le regole sui nuovi tentativi e la definizione di successo. Una percentuale di produttività dichiarata da un fornitore non è una previsione per il tuo codice.

Nel tuo progetto pilota, registra il tempo trascorso fino all'accettazione di una modifica, l'impegno del revisore, il lavoro da rifare, i difetti scoperti dopo il merge e le sessioni bloccate. Confronta attività simili e conserva nel resoconto anche gli insuccessi. È una proposta di piano di misurazione; qui non si dichiara alcuna percentuale di miglioramento.

Amplia la delega quando diventa più facile portare a termine il lavoro accettato, senza un aumento inaccettabile del carico di revisione o dei difetti. Se produrre patch diventa più rapido ma capirle più difficile, riduci l'ambito e rafforza le verifiche.

Domande frequenti

Da dove iniziare lunedì

Scegli una piccola issue dal backlog con un comportamento riproducibile e assegna il revisore prima di avviare l'agente. Scrivi i criteri di accettazione, fornisci un ambiente di lavoro isolato e non concedere credenziali di produzione. Chiedi una patch accompagnata dalle prove necessarie per valutarla.

Dopo la revisione, registra che cosa ha gestito l'agente, dove è intervenuta una persona e quali controlli mancavano. Usa questi elementi per definire l'ambito dell'incarico successivo. Aumenta l'autonomia quando il processo di verifica lo giustifica.

Per consigli pratici sullo sviluppo con l'AI, iscriviti alla newsletter.