Il vero problema degli agenti AI non è il modello: è isolarli bene
Negli ultimi mesi la discussione sugli agenti AI per il coding si è concentrata quasi solo su quale modello usare: Claude, Codex, Gemini, modelli locali o cloud, contesto lungo, costi. È comprensibile, ma manca spesso un pezzo più operativo: dove facciamo lavorare questi agenti?
Un conto è usare l'AI come autocomplete. Un altro è lasciare un agente modificare file, lanciare test, eseguire comandi, installare dipendenze, fare commit o esplorare un'intera codebase. A quel punto il problema non è solo quanto è intelligente il modello, ma quanto è controllato l'ambiente a cui gli stiamo dando accesso.
Il rischio del repo principale
Il modo più semplice è anche il più fragile: aprire l'agente direttamente nella working directory principale e lasciarlo lavorare. Funziona, finché funziona. Un agente però può produrre in fretta modifiche su molti file, dipendenze aggiornate, test lanciati in modo distruttivo, configurazioni cambiate "per far passare" il task, diff difficili da rivedere e uno stato Git sporco. Se nel progetto ci sono variabili d'ambiente, credenziali locali o configurazioni sensibili, il margine di errore aumenta.
Il pattern più maturo: worktree + sandbox + review
Una soluzione sempre più ricorrente è separare l'agente dal repo principale con un worktree dedicato: git worktree add ../feature-ai-agent -b feature/ai-agent, e poi lanciare l'agente lì dentro. Non rende tutto sicuro per magia, ma cambia il modo di lavorare: il branch è separato, il diff è più facile da isolare, si possono far lavorare più agenti in parallelo, si può buttare via l'intero worktree se il risultato è scarso, e il merge nel ramo principale resta una decisione umana.
Worktree non vuol dire sandbox
Distinzione importante: un worktree separa stato di lavoro e branch, ma non isola processi, rete, filesystem esterno o credenziali. Se l'agente può eseguire comandi, serve anche ragionare su permessi e sandboxing. Non a caso la documentazione di Claude Code dedica spazio esplicito a sicurezza, permessi e sandbox: modalità read-only di default, approvazioni per azioni sensibili, restrizioni di scrittura, Bash tool sandboxed. Il setup prudente non è solo "branch separato", ma worktree/clone isolato, permessi minimi, nessuna credenziale reale se non indispensabile, rete limitata quando possibile, comandi distruttivi sempre da approvare e review del diff prima del merge.
Quando ha senso (e quando no)
Per generare uno snippet o correggere una funzione isolata, un setup completo con worktree e sandbox è eccessivo. Ma quando l'agente lavora su una codebase reale — file multipli, test, dipendenze, configurazioni — l'isolamento smette di essere burocrazia e diventa igiene tecnica. Il punto non è bloccare gli agenti, ma farli lavorare in modo che un errore sia contenuto, revisionabile e reversibile.
Il futuro degli agenti nel coding non dipenderà solo dai benchmark dei modelli, ma dalla qualità del workflow attorno. Voi come li gestite: direttamente nel repository principale, oppure con worktree, container, VM o sandbox dedicate?
📌 Questo articolo riassume una discussione su r/vibecodingitalia. Leggi il post originale.