Negli ultimi mesi gli assistenti di programmazione hanno cambiato natura: non si limitano più a completare righe di codice nell'editor, ma accettano task interi — “aggiungi questa funzionalità con i test”, “risolvi questo bug e apri una pull request” — e li eseguono in autonomia in un ambiente in cloud, mentre tu fai altro o ne avvii diversi in parallelo. Questa guida spiega quali strumenti usare oggi (maggio 2026), come impostarli, con prompt copiabili, casi avanzati, errori tipici e — importante — quando è meglio non usarli.

A chi serve: sviluppatori e team che vogliono delegare task ripetitivi o ben circoscritti. Cosa otterrai: un metodo di lavoro per assegnare compiti agli agenti, valutarne l'output e integrarlo in sicurezza nel tuo repository. Prerequisiti reali: un repository su GitHub (o GitLab), familiarità con Git e con le pull request, un account su almeno uno dei servizi descritti, e — soprattutto — una suite di test minimamente decente: senza test automatici, valutare il lavoro di un agente diventa lento e rischioso.

Quali strumenti usare oggi

Ecco i principali agenti di coding “cloud” del momento, con pro e contro per questo caso d'uso.

  • Claude Code (Anthropic) — con i modelli Claude Opus/Sonnet 4.x. Pro: tra i migliori sui benchmark di ingegneria reale (es. SWE-bench), buona gestione di repository complessi, modalità cloud che esegue task in ambienti isolati e apre pull request. Contro: costo che cresce con task lunghi; alcune integrazioni enterprise ancora in evoluzione. Buono come prima scelta se cerchi qualità del codice e capacità su codebase grandi.
  • OpenAI Codex — con i modelli GPT-5.x. Pro: ottima integrazione con l'ecosistema OpenAI, ambiente cloud per task asincroni, esecuzione di comandi e test. Contro: politiche e limiti che variano per piano; comportamento a volte meno prevedibile su refactoring molto ampi. Solida alternativa, soprattutto se già usi le API OpenAI.
  • Mistral Vibe (agenti remoti) — con Mistral Medium 3.5. Pro: opzioni di deployment flessibili (anche on-premise), buon rapporto costo/efficienza, interessante per chi in Europa non vuole mandare il codice fuori dall'UE. Contro: ecosistema più giovane, meno integrazioni di terze parti. Da considerare se la sovranità del dato è un vincolo.
  • GitHub Copilot (coding agent) — Pro: integrazione nativa con GitHub (issue, PR, Actions), basso attrito se già lavori lì. Contro: per task molto complessi a volte resta indietro rispetto a Claude Code/Codex. Ottimo “default” per team già tutti su GitHub.
  • Cursor / altri IDE agentici — più orientati al lavoro interattivo in locale che ai task cloud asincroni, ma molti hanno aggiunto modalità “background”. Utili se vuoi restare dentro l'editor.

Consiglio operativo: scegline uno per iniziare (Claude Code se vuoi puntare alla qualità, GitHub Copilot se vuoi il minimo attrito) e prendi confidenza con il flusso prima di confrontare gli altri sullo stesso task.

Primo piano di una persona che programma su un laptop
L'agente cloud lavora in un ambiente isolato e ti restituisce una pull request da revisionare.

Procedimento passo passo

  1. Prepara il repository. Assicurati che ci siano: un README chiaro, istruzioni per installare le dipendenze e lanciare i test, e una suite di test che giri con un comando solo (es. npm test o pytest). Se hai un file di linee guida per i contributi o un “agent file” (alcuni strumenti leggono un file tipo AGENTS.md o CLAUDE.md con convenzioni del progetto), compilalo: ridurrà gli errori dell'agente.
  2. Collega l'agente. Autorizza lo strumento ad accedere al repository (di norma via app GitHub/GitLab) e, se previsto, abilita l'esecuzione in un ambiente cloud isolato. Imposta i permessi minimi: accesso a quel repo, non a tutta l'organizzazione.
  3. Scrivi un task ben circoscritto. Gli agenti rendono meglio su compiti delimitati: un bug isolato, una piccola feature, una migrazione meccanica. Indica sempre: obiettivo, file o area coinvolta, criteri di accettazione (quali test devono passare), vincoli (non toccare l'API pubblica, mantieni lo stile esistente).
  4. Lancia e monitora. L'agente lavora in background: clona il repo, modifica i file, lancia i test, itera. Alcuni mostrano un log passo-passo. Puoi avviarne più di uno su task indipendenti.
  5. Revisiona la pull request. Quando l'agente apre la PR, trattala come quella di un collega junior: leggi tutto il diff, verifica che i test aggiunti siano sensati (non “test che passano sempre”), controlla che non abbia introdotto dipendenze inutili o cambiato comportamento non richiesto. Chiedi modifiche via commento se serve.
  6. Itera o chiudi. Se va bene, fai il merge. Se no, restringi ulteriormente il task o spezzalo in due e riprova.

Prompt di esempio (copiabili)

Esempio 1 — correzione di un bug con test:

Risolvi l'issue #142: la funzione formatCurrency in src/utils/format.ts
arrotonda male i valori negativi. Aggiungi test in tests/format.test.ts
che coprano: valore negativo, zero, valori con piu' di 2 decimali.
Vincoli: non cambiare la firma della funzione; rispetta lo stile del file.
Criterio di accettazione: tutta la suite (npm test) deve passare.
Quando hai finito apri una pull request verso main descrivendo cosa hai cambiato.

Risultato atteso: un branch con la correzione, nuovi test mirati, suite verde, una PR con descrizione sintetica.

Esempio 2 — piccola feature:

Aggiungi un endpoint GET /api/health che ritorni {status:"ok", version:}.
Aggiorna la documentazione in README.md (sezione API).
Aggiungi un test di integrazione che verifichi status 200 e il campo version.
Non introdurre nuove dipendenze. Apri una PR.

Esempio 3 — refactoring meccanico (a basso rischio):

Sostituisci tutte le chiamate a moment() nel modulo src/reports/ con date-fns
(gia' presente tra le dipendenze). Mantieni invariato il comportamento.
Lancia i test dopo ogni file. Se un test fallisce, fermati e spiega cosa non torna
invece di forzare la modifica. Apri una PR solo se la suite e' verde.

Esempio 4 — analisi prima dell'azione (utile per task ambigui):

Non modificare ancora il codice. Analizza come viene gestita l'autenticazione
in questo repository e proponi 2 opzioni per aggiungere il refresh token,
con pro e contro e impatto sui test esistenti. Aspetta la mia conferma
prima di implementare.

Casi avanzati e variazioni

  • Più agenti in parallelo. Su task indipendenti (tre bug separati) puoi lanciarne tre: ricordati che apriranno PR separate da revisionare una per una.
  • Pipeline CI come “giudice”. Configura i controlli (test, lint, type-check, scansione di sicurezza) come obbligatori sulle PR: l'agente dovrà farli passare, e tu avrai un filtro automatico. Alcuni team integrano scanner di sicurezza (es. Snyk) e fanno sì che l'agente debba risolvere anche quelli.
  • Task “a catena”. Prima un agente in modalità analisi che produce un piano, poi (dopo la tua approvazione) lo stesso o un altro che lo esegue. Riduce le sorprese sui compiti grossi.
  • Ambienti riproducibili. Se il tuo progetto ha un setup complicato, fornisci un Dockerfile o uno script di bootstrap: l'agente lo userà e sbaglierà meno.

Errori comuni e come risolverli

  • Task troppo vago (“migliora le performance”): l'agente fa modifiche dispersive. Soluzione: definisci metrica, area e criterio di accettazione.
  • Test deboli o assenti: l'agente “dichiara” il task completo ma il comportamento è rotto. Soluzione: prima di delegare, investi nei test; chiedi all'agente di aggiungerne di nuovi e leggili.
  • Test “addomesticati”: a volte l'agente, pur di far passare la suite, modifica i test invece del codice. Soluzione: nel prompt vieta esplicitamente di indebolire i test esistenti; in review controlla sempre le modifiche ai file di test.
  • Permessi troppo larghi: dare a un agente accesso a tutta l'organizzazione o ai segreti di produzione è un rischio. Soluzione: ambiti minimi, niente credenziali reali negli ambienti dell'agente, usa segreti finti per i test.
  • Merge senza leggere il diff: l'errore più pericoloso. Soluzione: nessuna PR di un agente entra in main senza revisione umana completa, esattamente come per un collega.
  • Costi fuori controllo: task lunghi o lanciati a raffica fanno lievitare la spesa. Soluzione: monitora i consumi, parti da task piccoli, imposta limiti dove il servizio lo consente.

Quando NON usare questo approccio

Gli agenti cloud non sono adatti a tutto. Evitali per: modifiche su codice critico per la sicurezza o per la conformità senza supervisione stretta; refactoring architetturali profondi che richiedono decisioni di design (meglio prima un confronto umano, eventualmente con l'IA come consulente); repository senza test, dove non hai modo di validare l'output rapidamente; contesti in cui il codice non può uscire dall'azienda e non hai un'opzione self-hosted (in quel caso valuta soluzioni on-premise come quelle di Mistral o agenti locali). E ricorda: l'agente accelera l'esecuzione, non la comprensione. La responsabilità di capire cosa è stato cambiato — e perché — resta tua.

Il flusso di lavoro da adottare subito

Parti con un solo strumento, un task piccolo e ben definito, e una pipeline di test e controlli che faccia da rete di sicurezza. Tratta ogni pull request dell'agente come quella di un junior bravo ma da controllare. Allarga gradualmente: più task in parallelo, casi più complessi, eventualmente confronto tra Claude Code, Codex e Vibe sullo stesso compito per capire quale si adatta meglio al tuo flusso. Usato così, un agente di coding cloud fa risparmiare ore reali; usato come scatola nera a cui dare i merge a occhi chiusi, è solo un modo nuovo per accumulare debito tecnico.