L'IA per sviluppatori: agenti di programmazione, costi e deleghe sicure

Come farlo

1. 1Prima di affidargliela, scrivi o indica la verifica: il test che fallisce, oppure il comando e il suo output atteso.
2. 2Dagli l'attività con il prompt di questa pagina, indicando i file che può modificare e quelli che non può toccare.
3. 3Lascia che esegua da solo la verifica e incolli l'output finale.
4. 4Rivedi il diff come la pull request di un collega; una verifica superata apre la revisione, non la chiude.

Integrato in

• ChatGPT · Codex
• Claude · Claude Code

Prompt da copiare

Attività: [modifica].
Finito significa: [test o comando] passa e stampa [output atteso]. Eseguilo prima di finire e incolla il risultato.
Puoi modificare: [percorsi]. Non modificare: [percorsi], le dipendenze o i test.
Se non riesci a farlo passare, fermati e spiega perché invece di aggirare la verifica.

Dove va storto

• A volte gli agenti fanno passare un test indebolendolo. Vieta di modificare i test e controlla il diff per accorgertene.
• Un'attività troppo grande per una sola verifica è troppo grande per una sola delega. Dividila.

Come farlo

1. 1Scegli quello più vicino al tuo codice: Codex Cloud, l'agente cloud di Copilot su GitHub o Claude Code sul web.
2. 2Assicurati che il suo ambiente possa installare le tue dipendenze ed eseguire i tuoi test; senza queste due cose, l'agente tira a indovinare.
3. 3Invia attività piccole e indipendenti, ognuna con la propria verifica, come nell'attività qui sopra.
4. 4Fai leggere prima ogni pull request a un revisore automatico, poi rivedila tu.

Integrato in

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

Prompt da copiare

In questo repository: [attività].
Contesto: [dove nel codice, issue collegata].
Finito quando: [test o comando] passa nel tuo ambiente; metti il suo output nella descrizione della pull request.
Mantieni la pull request sotto le [n] righe modificate. Se ne servono di più, fermati e proponi come dividerla.

Dove va storto

• I test che richiedono segreti o servizi che non hai configurato vengono saltati o falliscono. Un'esecuzione verde senza di essi dimostra poco.
• Più agenti su codice correlato producono pull request in conflitto. Tieni le attività parallele in aree separate.

Come farlo

1. 1Metti i comandi di build, test e lint nel file di istruzioni che il tuo agente legge all'inizio di ogni sessione; la documentazione di ogni agente indica qual è il file.
2. 2In Claude Code, aggiungi hook che eseguono il formatter e i test dopo ogni modifica, così l'agente vede cosa fallisce e lo corregge.
3. 3Fai rivedere ogni pull request da un bot: attiva «Automatic review» in Codex, oppure richiedi Copilot come revisore.
4. 4Quando l'agente fa lo stesso errore due volte, trasformalo in un test o in una regola nel file di istruzioni.

Integrato in

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

Prompt da copiare

Leggi questo repository e scrivi il file di istruzioni per gli agenti di programmazione:
1. I comandi esatti per installare, fare la build, testare, eseguire il lint e formattare.
2. La struttura del progetto in 10 righe o meno.
3. Le convenzioni che qui i nuovi arrivati sbagliano, con un esempio per ciascuna.
4. Cosa un agente non deve mai fare qui, per esempio modificare le migrazioni o i file generati.
Elenca solo i comandi che hai eseguito con successo; segna gli altri come «non verificato».

Dove va storto

• Un file di istruzioni con comandi che non funzionano più insegna all'agente a ignorarlo. Rieseguili quando cambia la configurazione.
• Anche i bot di revisione sbagliano con sicurezza. Tratta i loro commenti come suggerimenti.

Come farlo

1. 1Elenca ciò che incolli più spesso nelle chat, come issue, log di errore, documentazione o lo schema. Collega prima quelli.
2. 2Aggiungi il server MCP ufficiale per ciascuno, con un token che può solo leggere. In Gemini CLI, un'estensione può includere il server MCP e la sua configurazione.
3. 3Dagli un'attività che li richiede e controlla che abbia chiamato quello giusto.
4. 4Ogni qualche settimana, rimuovi i server che non usi più.

Integrato in

• Gemini CLI · Extensions

Prompt da copiare

Prima di modificare qualsiasi cosa: leggi la issue [id] nel tracker, trova l'errore nei log e controlla la documentazione di [libreria].
Riporta cosa ti ha detto ciascuna fonte e quale file secondo te è responsabile.
Non scrivere in nessuno strumento collegato.

Dove va storto

• Una pagina web, una issue o un documento possono contenere testo scritto per pilotare l'agente. Non dare accesso in scrittura agli strumenti che leggono contenuti dall'esterno.
• I token nei file di configurazione trapelano. Usa l'archivio dei segreti del client o le variabili d'ambiente, mai il repository.

Come farlo

1. 1Controlla cosa paghi già: i piani di ChatGPT includono Codex, e i piani a pagamento di Claude includono Claude Code.
2. 2Annota il consumo di token di alcune sessioni tipiche, dove il tuo agente lo mostra.
3. 3Calcola il costo di quel consumo sulla nostra pagina dei prezzi API e confrontalo con l'abbonamento.
4. 4Per l'automazione e la CI, usa chiavi API con un limite di spesa, così un loop non può far lievitare il conto.

Integrato in

• ChatGPT · Codex
• Claude · Claude Code

Prompt da copiare

Ecco il mio consumo in [n] sessioni tipiche: [token in input e in output]. Lavoro circa [giorni] giorni a settimana.
Stima il mio costo mensile a token con questi prezzi: [incolla dalla pagina dei prezzi API].
Confrontalo con un abbonamento da [prezzo] al mese. Mostra i calcoli così posso verificarli.

Dove va storto

• Anche gli abbonamenti hanno limiti di utilizzo. Raggiungerne uno a metà attività costa tempo; controlla il limite, non solo il prezzo.
• Il modello pesa sul conto più di qualsiasi altra cosa. Confronta con il modello che usi davvero.

Come farlo

1. 1Esegui /init nel repository: analizza la codebase e scrive un CLAUDE.md iniziale, oppure suggerisce miglioramenti a quello che hai già.
2. 2Tieni le regole del team, come i comandi di build e di test e gli standard di codice, in ./CLAUDE.md e fanne il commit. Le tue preferenze personali vanno in ~/.claude/CLAUDE.md per tutti i progetti, o in CLAUDE.local.md per questo.
3. 3Rimanda ai documenti lunghi invece di incollarli: @path/to/file importa un altro file all'avvio.
4. 4Ogni volta che Claude sbaglia la stessa cosa due volte, aggiungi la riga che l'avrebbe evitato.

Prompt da copiare

Leggi questo repository e migliora CLAUDE.md. Tienilo sotto le 60 righe:
1. I comandi esatti per fare la build, i test e il lint.
2. La struttura in poche righe.
3. Le convenzioni che qui un nuovo arrivato sbaglia.
4. File e cartelle da non modificare mai.
Rimuovi tutto ciò che non è più vero. Segna come «non verificato» i comandi che non hai eseguito.

Dove va storto

• Tutto ciò che sta in CLAUDE.md viene caricato a ogni sessione e occupa contesto. Sposta i dettagli in file che CLAUDE.md importa.
• Istruzioni non più vere sono peggio di nessuna istruzione. Ricontrolla i comandi quando cambia la configurazione.

Dalla documentazione ufficiale: Claude Code docs: How Claude remembers your project

Come farlo

1. 1Premi Shift+Tab finché la barra di stato non mostra «plan mode on», oppure inizia il prompt con /plan.
2. 2Descrivi la modifica e cosa non deve cambiare. Claude può comunque eseguire comandi per esplorare, ma non modifica file mentre pianifica.
3. 3Leggi il piano come una nota di progettazione: un file sbagliato, un caso mancante, una modifica troppo grande. Chiedi correzioni finché non va bene, poi approvalo.
4. 4Prima di un'altra attività non collegata, riparti da zero con /clear.

Prompt da copiare

/plan Modifica [cosa] in modo che [obiettivo]. Vincoli: [cosa non deve cambiare].
Elenca i file che toccherai, l'ordine delle modifiche, il test che dimostra ogni passo e tutto ciò su cui hai dubbi. Non modificare nulla finché non approvo.

Dove va storto

• Il segnale d'allarme è un piano che tocca più file di quanti ti aspettavi. Chiedi perché prima di approvare.
• Plan mode esegue comunque comandi per esplorare. Non rende sicuro eseguire il codice di un repository che non conosci.

Dalla documentazione ufficiale: Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

Come farlo

1. 1Apri /permissions per vedere ogni regola e da quale file di impostazioni proviene.
2. 2Metti le regole del team in .claude/settings.json e fanne il commit. Le regole personali vanno in ~/.claude/settings.json o .claude/settings.local.json.
3. 3Le regole vengono controllate in quest'ordine: deny, poi ask, poi allow, quindi una sola regola deny prevale su qualsiasi allow.
4. 4Cambia modalità con Shift+Tab: acceptEdits approva le modifiche ai file nella directory di lavoro. bypassPermissions disattiva le richieste di conferma e i controlli di sicurezza; la documentazione dice di usarla solo in container o VM isolati senza accesso a internet.

Prompt da copiare

Guarda i comandi che hai eseguito in questa sessione. Proponi regole di permesso per .claude/settings.json: consenti i comandi di sola lettura e di test che usiamo ogni giorno, nega tutto ciò che legge segreti o cancella fuori dal progetto, e per tutto il resto lascia che venga chiesta conferma. Spiega ogni regola in una riga.

Dove va storto

• Una regola allow che corrisponde a qualsiasi comando equivale a nessuna richiesta di conferma. Consenti comandi esatti.
• Una volta fatto il commit, le regole in .claude/settings.json valgono per tutto il team. Rivedile come se fossero codice.

Dalla documentazione ufficiale: Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

Come farlo

1. 1Tra attività non collegate, /clear avvia una nuova conversazione con il contesto vuoto.
2. 2In un'attività lunga, /compact con un'indicazione su cosa concentrarsi, per esempio «/compact mantieni il piano e il test che fallisce», riassume quello che è venuto prima.
3. 3Affida le ricerche ampie a un subagent: ognuno lavora nella propria finestra di contesto, così alla tua sessione torna solo la sua risposta.
4. 4Claude Code compatta anche da solo quando si avvicina al limite; se compatti tu al momento giusto, conservi ciò che scegli.

Integrato in

• Claude Code · Subagents

Prompt da copiare

/compact Mantieni: l'obiettivo, il piano, i file modificati finora e il test che fallisce ancora. Scarta l'esplorazione.

Dove va storto

• /clear dimentica la conversazione. Tutto ciò che ti servirà di nuovo va prima messo in CLAUDE.md.
• La risposta di un subagent è tutto ciò che ricevi. Chiedigli percorsi dei file e numeri di riga, non solo conclusioni.

Dalla documentazione ufficiale: Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

Come farlo

1. 1Avvia ogni sessione con claude --worktree <name> (o -w). Crea un git worktree in .claude/worktrees/<name>/ sul branch worktree-<name>.
2. 2Aggiungi .claude/worktrees/ a .gitignore, come consiglia la documentazione.
3. 3Dai a ogni sessione un'attività con il proprio controllo, così puoi rivederle una alla volta.
4. 4Rivedi ogni branch e fanne il merge come per qualsiasi altra pull request.

Prompt da copiare

Stai lavorando in un worktree sul branch worktree-[nome]. Attività: [una modifica]. Finita quando: [test o comando] passa. Fai commit solo su questo branch; non fare merge né rebase di altri branch.

Dove va storto

• Ogni worktree è una cartella a sé, quindi dipendenze e output della build non sono condivisi. Esegui l'installazione in ciascuno.
• Due attività che toccano gli stessi file vanno comunque in conflitto quando fai il merge, worktree o no.

Dalla documentazione ufficiale: Claude Code docs: Run parallel sessions with worktrees

Come farlo

1. 1Premi Esc due volte con il prompt vuoto, oppure digita /rewind (funzionano anche /checkpoint e /undo).
2. 2Scegli il punto prima che le cose andassero storte e ripristina la conversazione, il codice o entrambi.
3. 3Conosci i limiti: i file modificati da comandi della shell come rm, mv o cp non vengono ripristinati, e nemmeno le modifiche fatte fuori da Claude Code o in un'altra sessione.
4. 4Fai un commit prima dei passi rischiosi. I checkpoint servono a recuperare in fretta dentro una sessione, non sostituiscono git.

Prompt da copiare

Prima di iniziare, fai il commit dello stato attuale con il messaggio «checkpoint prima di [attività]». Poi [attività]. Chiedimi conferma prima di qualsiasi comando che cancella o sposta file.

Dove va storto

• Rewind non riporta indietro un file cancellato da un comando. Solo git lo fa.
• Nemmeno le modifiche che hai fatto a mano nel frattempo vengono registrate. Fanne il commit prima di usare rewind.

Dalla documentazione ufficiale: Claude Code docs: Checkpointing · Claude Code docs: Commands

Come farlo

1. 1claude -p "..." funziona in modo non interattivo. --output-format json o stream-json produce un output che uno script può analizzare.
2. 2Esce con 0 in caso di successo e con un valore diverso da zero in caso di errore, così la CI può comportarsi di conseguenza.
3. 3Aggiungi --bare in CI per esecuzioni che non dipendono dalla configurazione locale.
4. 4Per le pull request, /install-github-app configura Claude Code GitHub Actions (solo repository su github.com); poi menziona @claude in un commento di una pull request o di una issue.

Prompt da copiare

claude -p "Leggi il diff rispetto a main. Elenca ogni modifica che aggiunge una dipendenza, tocca l'autenticazione o cambia una migrazione del database, in JSON: {\"files\": [], \"reason\": \"\"}. Restituisci una lista vuota se non ce ne sono." --output-format json

Dove va storto

• Uno script gira con i permessi che gli dai. Dai alla CI il minimo indispensabile.
• /install-github-app funziona solo con repository su github.com.

Dalla documentazione ufficiale: Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

Come farlo

1. 1Esegui /init nella CLI per scrivere un AGENTS.md iniziale nella cartella corrente.
2. 2Metti le indicazioni personali in ~/.codex/AGENTS.md e le regole del progetto nel repository. Una sottocartella può avere il proprio file; vincono i file più vicini a dove lavora Codex.
3. 3Tieni i file brevi: la loro dimensione complessiva ha un limite, 32 KiB per impostazione predefinita.
4. 4Aggiungi una sezione «## Code Review Rules»: le revisioni di Codex su GitHub la seguono.

Prompt da copiare

Leggi questo repository e scrivi AGENTS.md:
1. I comandi esatti per installare, fare la build, i test e il lint.
2. La struttura in poche righe.
3. Le convenzioni che qui un nuovo arrivato sbaglia.
4. Una sezione «## Code Review Rules» con ciò che un revisore deve sempre segnalare.
Elenca solo i comandi che hai eseguito con successo; segna gli altri come «non verificato».

Dove va storto

• I file lunghi ti remano contro: la dimensione complessiva ha un limite di 32 KiB per impostazione predefinita.
• Un file in una sottocartella che contraddice quello nella radice senza dirlo confonde le persone quanto Codex. Scrivi cosa sovrascrive.

Dalla documentazione ufficiale: Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

Come farlo

1. 1Nella CLI, /permissions cambia la modalità e /status mostra la policy di approvazione e le cartelle scrivibili attive.
2. 2«Ask for approval», l'impostazione predefinita consigliata, modifica ed esegue comandi dentro lo spazio di lavoro e si ferma prima di andare oltre.
3. 3«Approve for me» mantiene la stessa sandbox ma invia le richieste di approvazione a una revisione automatica invece che a te.
4. 4«Full access» rimuove i limiti sul file system e sulla rete. La documentazione aggiunge un'avvertenza; riservalo ad ambienti che puoi buttare via.

Prompt da copiare

Prima di iniziare, esegui /status e dimmi la policy di approvazione e le cartelle scrivibili. Poi [attività]. Chiedi prima di qualsiasi comando che richiede la rete o scrive fuori da questo repository.

Dove va storto

• Con «Approve for me» nessuna persona legge le singole richieste. Usalo dove un'azione sbagliata si annulla con poco.
• «Full access» vale per l'intera macchina, non solo per il repository.

Dalla documentazione ufficiale: Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

Come farlo

1. 1codex exec "..." funziona in modo non interattivo e usa per impostazione predefinita una sandbox di sola lettura.
2. 2Aggiungi --sandbox workspace-write quando deve modificare file; --full-auto è deprecato.
3. 3--json emette un flusso JSON Lines di eventi, per gli script che hanno bisogno di ogni passo.
4. 4In GitHub Actions, openai/codex-action@v1 esegue codex exec al posto tuo.

Prompt da copiare

codex exec "Leggi le modifiche dal tag [v1.2.0]. Scrivi note di rilascio raggruppate in Aggiunto, Modificato e Corretto: una riga per modifica, con parole che un utente capisce, senza hash dei commit."

Dove va storto

• Le guide più vecchie usano ancora --full-auto. È deprecato; usa --sandbox workspace-write.
• Un'attività che legge soltanto deve restare in sola lettura, anche in CI.

Dalla documentazione ufficiale: Codex docs: Non-interactive mode · Codex docs: GitHub Action

Come farlo

1. 1/review nella CLI rivede il tuo working tree. codex review fa lo stesso senza la chat, rispetto a un branch di base, a un commit o alle modifiche non ancora committate.
2. 2Su GitHub, commenta @codex review in una pull request.
3. 3Attiva le revisioni automatiche in «Personal preferences» nelle impostazioni di Codex; così non serve nessun commento.
4. 4Scrivi le regole del tuo team in una sezione «## Code Review Rules» di AGENTS.md.

Integrato in

• Codex · Codex code review

Prompt da copiare

## Code Review Rules
- Segnala qualsiasi modifica all'autenticazione o ai permessi.
- Segnala le migrazioni del database senza un modo per tornare indietro.
- Segnala le nuove dipendenze e indica se servono.
- Ignora la formattazione; se ne occupa il linter.

Dove va storto

• Le revisioni su GitHub segnalano solo i problemi P0 e P1. L'assenza di commenti non significa che il design sia giusto.
• Una revisione è un secondo parere, non un'esecuzione dei test. Tieni i test.

Dalla documentazione ufficiale: Codex docs: CLI commands · Codex docs: GitHub integration

Come farlo

1. 1Crea un ambiente con i repository, le dipendenze, gli strumenti e le impostazioni di accesso che servono alle attività. I nuovi ambienti registrano uno script di installazione e una skill di avvio.
2. 2Imposta l'accesso a internet per ogni ambiente: solo i gestori di pacchetti, domini scelti o tutto.
3. 3Avvia le attività da ChatGPT, dall'estensione per l'IDE per i lavori più lunghi o dal terminale con codex cloud exec; --attempts 1-4 chiede più tentativi da confrontare.
4. 4Code Review e le integrazioni con GitHub e Linear girano ancora sul vecchio Codex Cloud (Legacy), che OpenAI prevede di dismettere.

Integrato in

• Codex · Codex Cloud

Prompt da copiare

codex cloud exec --attempts 3 "Attività: [modifica]. Contesto: [file]. Finita quando [test] passa in questo ambiente. Tieni il diff sotto le [n] righe."

Dove va storto

• Un accesso a internet senza limiti permette a un'attività di raggiungere qualsiasi sito, comprese pagine scritte per pilotarla. Consenti solo ciò che serve al lavoro.
• Se manca lo script di installazione, i test potrebbero non essere stati eseguiti. Controlla che un'attività li abbia eseguiti davvero.

Dalla documentazione ufficiale: Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

Come farlo

1. 1Imposta il modello e lo sforzo di ragionamento predefiniti in ~/.codex/config.toml (model e model_reasoning_effort). La CLI e l'estensione per l'IDE lo condividono.
2. 2Crea un profilo come file a sé, ~/.codex/<name>.config.toml, e avvialo con --profile <name>.
3. 3Aggiungi server MCP con codex mcp add <name> -- <command>; ognuno diventa una tabella [mcp_servers.<name>], e /mcp elenca quelli attivi.
4. 4/status mostra cosa è attivo, e codex resume --last riprende l'ultima sessione in questa cartella.

Prompt da copiare

Leggi ~/.codex/config.toml e il .codex/config.toml di questo progetto. Dimmi il modello, lo sforzo di ragionamento, la sandbox e i server MCP attivi, da quale file proviene ciascuno, e qualsiasi conflitto.

Dove va storto

• Le impostazioni di progetto si caricano solo per i progetti attendibili. Se una sembra ignorata, controlla prima questo.
• Ora i profili sono file separati. Le guide che mettono [profiles.name] dentro config.toml non sono aggiornate.

Dalla documentazione ufficiale: Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands