Cosa distingue un agente CLI di coding da un altro
Chiedi a un agente CLI di coding di sistemare un test che fallisce e non ti risponderà con un suggerimento. Legge l’output del test, apre il file, modifica una riga, rilancia il test e ti riporta il risultato una volta che passa. Quel ciclo è il prodotto, non la finestra di chat.
Il modello dentro il ciclo si prende la maggior parte dell’attenzione, ed è anche la parte che cambia più in fretta: i vendor ne inseriscono di nuovi ogni pochi mesi, e diversi agenti ti lasciano scegliere quale usare. Quello che resta fermo è l’harness costruito attorno al modello — quali tool può raggiungere, come gestisce il contesto, cosa può eseguire senza chiedere, e dove girano quei comandi. Due agenti con lo stesso modello possono comportarsi in modo molto diverso per questo motivo. L’harness è ciò che stai davvero scegliendo.
Come funziona il ciclo agentico
Togli il branding e ogni agente CLI di coding gira lo stesso ciclo:
- Il modello riceve la tua richiesta più tutto il contesto che l’harness ha assemblato: file aperti, output recente della shell, istruzioni di progetto.
- Invece di limitarsi a scrivere testo, il modello può emettere una tool call: “esegui questo comando shell”, “scrivi questi byte in questo file”, “cerca questo pattern”.
- L’harness esegue davvero quella chiamata, sul tuo filesystem o sulla tua shell reali, e riporta il risultato nel contesto del modello.
- Il modello legge il risultato e decide cosa fare dopo: chiamare un altro tool, o risponderti.
Questo si ripete finché il modello decide che il task è finito. Non gli serve un piano completo prima di agire: esegue un comando, legge cosa è successo e si adatta — ed è anche per questo che un agente può consumare decine di tool call su un task che si è rivelato semplice.
Niente di tutto questo richiede una nuova architettura di modello. Serve un modello bravo a scegliere quale tool chiamare e quando fermarsi, e un harness che gli dia tool che valga la pena chiamare.
Quali tool ha davvero a disposizione un agente di coding
La lista dei tool integrati è corta e poco sorprendente: leggere un file, scrivere o modificare un file, eseguire un comando shell, cercare nel codebase per nome file o per contenuto, e in molti agenti, recuperare un URL o guidare un browser. Refactoring, debugging, scrivere test, leggere uno stack trace: tutto questo è il modello che compone queste primitive, non una funzione separata costruita dal vendor.
Le decisioni di design che contano stanno nei dettagli. “Modificare un file” richiede una corrispondenza esatta di stringa con il contenuto attuale, più sicura e più facile da revisionare, oppure il modello può sovrascrivere l’intero file, più veloce e più facile da sbagliare? “Eseguire un comando shell” gira diretto, oppure dentro una sandbox che blocca l’accesso alla rete e le scritture fuori dal progetto? Metti lo stesso modello dietro risposte diverse a queste due domande e ottieni agenti che non si somigliano per niente.
Come gli agenti di coding gestiscono un contesto più grande della finestra
Un codebase vero non entra in una context window, e una sessione lunga produce molto più output dai tool di quanto chiunque incollerebbe mai in un prompt. Gli agenti combinano diverse tecniche per gestirlo:
- Lettura selettiva. L’agente cerca il file o la funzione rilevante invece di caricare l’intero repository — lo stesso istinto che hai tu quando fai
grepprima di farecat. - Compattazione. Quando la conversazione supera una soglia di dimensione, l’harness riassume i turni precedenti in una forma più corta e continua a lavorare da lì, scambiando dettaglio con spazio.
- Subagenti. Un task grande viene diviso in task più piccoli, ognuno inviato a una nuova chiamata del modello con solo il contesto che gli serve. Solo il risultato torna nella conversazione principale.
- Retrieval. Alcuni agenti indicizzano il codebase e usano lo stesso pattern di retrieval alla base del RAG per recuperare solo i chunk rilevanti per la domanda attuale. Altri saltano l’indice e si affidano solo alla ricerca.
La compattazione è quella che morde di più. Un dettaglio dall’inizio della sessione, come un flag menzionato una volta sola, può sparire dal riassunto. Se un agente inizia a ignorare qualcosa che gli hai detto un’ora prima, di solito è questa la causa, e una sessione nuova con i fatti chiave ripetuti risolve il problema.
Cosa può eseguire un agente di coding senza chiederti il permesso
L’harness decide fin dove arriva l’agente prima di fermarsi e chiedere. A un estremo, ogni modifica a un file e ogni comando shell aspettano la tua approvazione. Sicuro, e lento: l’agente ti interrompe di continuo. All’altro estremo, l’agente gira in un ambiente sandboxato senza nessuno a guardare, il che si adatta a lavoro in background come sistemare un test flaky e aprire una pull request mentre tu fai altro.
La maggior parte dell’uso quotidiano sta nel mezzo. Le azioni di sola lettura come cercare e aprire file avvengono automaticamente. Qualsiasi cosa distruttiva o rivolta verso l’esterno, come cancellare un file o fare push su un remote, aspetta un sì.
Questa è una policy imposta dall’harness, non una proprietà del modello. Lo stesso modello è prudente o spericolato a seconda di cosa può fare senza supervisione.
Come MCP dà nuovi tool a un agente di coding
I tool integrati coprono il filesystem e la shell, ma il lavoro vero spesso richiede altro: interrogare un database interno, o aprire un ticket nel tuo issue tracker. Il Model Context Protocol (MCP) è lo standard aperto che offre questo senza che ogni vendor di agenti scriva un’integrazione su misura per ogni servizio.
Un server MCP descrive i tool che offre e come chiamarli. Qualsiasi agente compatibile con MCP può connettersi, elencare quei tool e chiamarli esattamente come i propri tool integrati. L’agente non ha bisogno di codice specifico per il servizio: legge le descrizioni dei tool e decide quando sono utili, allo stesso modo in cui decide quando eseguire grep.
Il costo è il contesto. In molti agenti, le descrizioni dei tool di ogni server connesso occupano spazio nella finestra a ogni turno, quindi una dozzina di server che usi raramente rende più pesante ogni richiesta. Collega solo quelli che ti servono per il progetto.
Cosa fanno i file AGENTS.md e CLAUDE.md
Quasi ogni agente cerca un file di istruzioni in markdown alla radice del tuo repository e lo legge prima di fare qualsiasi altra cosa. AGENTS.md è la convenzione neutrale rispetto al vendor; alcuni strumenti usano un proprio nome, come CLAUDE.md. È dove scrivi ciò che il modello non può dedurre dal codice: quale comando esegue i test, e quali directory sono generate e non vanno toccate a mano. Qualsiasi cosa l’agente dovrebbe altrimenti indovinare, e indovinare male, va qui.
Molti agenti leggono anche file di istruzioni nelle sottodirectory, così un monorepo può avere un file alla radice più uno più specifico per ogni package. Se un file più profondo sovrascrive quello alla radice o si aggiunge ad esso varia da strumento a strumento, quindi controlla la documentazione di quello che usi.
Dieci righe in questo file evitano che l’agente debba riscoprire il tuo comando di test a ogni sessione.
Come confrontare gli agenti CLI di coding
Quando il ciclo e la lista dei tool sono gli stessi ovunque, le checklist di feature smettono di dirti molto. Queste quattro domande separano gli strumenti in modi che cambiano davvero la tua giornata:
| Domanda | Cosa significa per te |
|---|---|
| Dove gira: terminale, IDE, o background? | Un agente da terminale vive nella tua shell e lavora insieme a qualsiasi editor. Un agente da IDE si integra nella diff view e nella cronologia undo del tuo editor. Un agente in background lavora senza supervisione a partire da una descrizione del task e ti consegna una pull request, adatto più a lavoro di backlog ben definito che al debugging interattivo. |
| L’harness è open source o proprietario? | Un harness aperto come OpenCode o Aider può essere puntato su qualsiasi modello a cui hai accesso API, incluso uno che fai girare in locale con Ollama, e puoi leggere esattamente cosa fa. Un harness proprietario è di solito ottimizzato per i modelli del proprio vendor e richiede meno configurazione. |
| Come paghi: API a consumo o abbonamento? | La fatturazione a token traccia l’uso, quindi le sessioni autonome lunghe costano di più. Un abbonamento limita la spesa ma aggiunge limiti d’uso e ti lega ai modelli di un solo vendor. |
| Quanto è profonda la sandbox? | Alcuni agenti eseguono i comandi direttamente sulla tua macchina; altri girano sempre dentro un container o una VM, lo stesso tipo di isolamento che ti danno i container Docker. L’esecuzione diretta non richiede configurazione ed è la scelta più rischiosa per qualsiasi cosa lasciata attiva senza supervisione. |
Classifica la modalità, non il brand. Un vendor spesso distribuisce uno strumento da terminale, un’estensione per editor e una modalità cloud che apre pull request; sia Claude Code sia OpenAI Codex funzionano così. I default di permessi e sandbox cambiano tra queste modalità, quindi giudica quella che userai davvero.
Come scegliere un agente CLI di coding per il tuo workflow
Salta le classifiche. I punteggi dei benchmark si muovono ogni poche settimane e dicono poco sul tuo repository. Rispondi a due domande invece: vuoi l’agente nel terminale o nell’editor, e lo vuoi al lavoro senza supervisione in background o in un ciclo dove approvi ogni passo? Quelle risposte riducono il campo a due o tre candidati.
Poi scrivi un AGENTS.md per il tuo progetto, dai a ogni candidato lo stesso task reale dal tuo backlog, e tieni quello il cui diff faresti merge con il minor numero di modifiche.