Roo Code: l'agente di programmazione locale dentro l'editor

#Cos'è

Tra il completamento del codice, che prevede la riga successiva mentre scrivi, e l'agente autonomo, che lavora da solo in un container senza supervisione continua, esiste una categoria intermedia: l'agente nell'editor. Vede il tuo progetto aperto, comprende la struttura ad albero dei file e le loro dipendenze, propone modifiche che approvi prima che vengano scritte sul disco ed esegue comandi nel tuo terminale con il tuo consenso esplicito ogni volta. Roo Code appartiene a questa famiglia, insieme a progetti come Cline, di cui condivide in larga misura la filosofia.

Il vantaggio rispetto a un assistente conversazionale è che non serve più fare copia e incolla: le modifiche arrivano sotto forma di diff nei file interessati. Il vantaggio rispetto a un agente autonomo è che rimani coinvolto a ogni passaggio, il che conta tanto più quanto più piccolo è il modello. Il progetto, pubblicato con licenza Apache 2.0, aveva superato le 20.000 stelle su GitHub dal suo lancio a fine 2024, un ritmo di adozione rapido in una categoria diventata molto competitiva — prima dell'annuncio di cessazione descritto in dettaglio di seguito.

#L'estensione è dismessa da maggio 2026: cosa cambia

È l'informazione più importante di questa guida, e quella che molti tutorial ancora online non menzionano. Matt Rubens, il fondatore, ha annunciato il 21 aprile 2026 la cessazione di Roo Code: ultima release il 15 maggio 2026, repository GitHub successivamente archiviato, bloccato in sola lettura, senza più alcuna correzione, nemmeno di sicurezza. Una verifica diretta del repository lo conferma: stato archiviato, ultimo commit datato 15 maggio 2026. Il team si è interamente dedicato a Roomote, un agente cloud controllato da Slack, ritenendo che l'editor di codice non rappresenti più, a suo giudizio, il futuro del lavoro con un agente IA.

#Le modalità, e perché sono una buona idea

La particolarità di Roo Code è la separazione delle personalità. Sono integrate per impostazione predefinita cinque modalità: Code, per scrivere e modificare con accesso completo agli strumenti; Ask, un assistente tecnico che risponde in dettaglio ma non modifica nulla (solo lettura e MCP); Architect, un pianificatore le cui autorizzazioni di scrittura si limitano ai file markdown, pensato per progettare prima di agire; Debug, orientato alla diagnosi sistematica con accesso completo; e Orchestrator, chiamato anche «Boomerang Mode», che suddivide un'attività complessa e la delega alle altre modalità. È comunque possibile definirne altre, con le proprie istruzioni e le proprie autorizzazioni.

Con un modello locale, è più di una semplice comodità. Una modalità Ask senza il permesso di scrivere elimina la categoria di incidenti in cui un modello troppo piccolo modifica un file per eccesso di zelo. Limitare i permessi in base alla modalità è il mezzo principale per rendere un piccolo modello utilizzabile senza rischi ed è, tra l'altro, ciò che avvicina maggiormente Roo Code a una buona pratica generale di sicurezza per gli agenti: dare a ogni ruolo solo ciò di cui ha bisogno, mai di più.

#Collegarlo a un modello locale

1. 01
   Rendere disponibile il modello tramite un server

   Ollama o qualsiasi punto di accesso compatibile con OpenAI. Per un uso individuale, Ollama è più che sufficiente.
2. 02
   Scegliere Ollama come fornitore nell'estensione

   Inserire il nome o il tag del modello. L'indirizzo di base predefinito è http://localhost:11434; una chiave API è necessaria solo se il tuo server Ollama ne richiede una.
3. 03
   Regolare la finestra di contesto al posto giusto

   È l'insidia più documentata: per impostazione predefinita, Roo Code si basa sul valore num_ctx definito nel Modelfile del modello Ollama, non su un valore specifico dell'estensione. Il contesto va quindi aumentato in Ollama (tramite il Modelfile o una variabile d'ambiente), non nelle impostazioni di Roo Code.
4. 04
   Iniziare in modalità Ask

   Porre tre domande sul progetto prima di consentire qualsiasi modifica, usando una modalità con soli permessi di lettura, fornisce una valutazione onesta di ciò che il modello comprende realmente del codice.

#Quale modello, davvero

Un modello di medie dimensioni orientato al codice supera quasi sempre un modello generalista più grande in questo esercizio, perché durante l'addestramento ha visto più formati rigorosi e diff, anziché prosa generale. La differenza si vede soprattutto nella capacità di produrre un diff che si applica al primo tentativo, senza errori di contesto o di numero di riga — un dettaglio tecnico che conta di più, in pratica, della qualità generale delle risposte del modello.

• Cline: l'altro agente di editing a confronto
• Aider: la stessa idea, nel terminale
• Far revisionare il proprio codice da un modello locale

#Orchestrator: suddividere un compito complesso

La modalità Orchestrator, chiamata anche Boomerang Mode nella documentazione ufficiale, cambia il modo di affrontare un compito troppo grande per un singolo passaggio. Anziché chiedere direttamente «aggiungi l'autenticazione alla mia applicazione», descrivi l'obiettivo a Orchestrator, che lo suddivide in sottocompiti e li delega alle modalità specializzate: Architect per definire il piano, Code per l'implementazione, Debug se un test fallisce durante il lavoro.

1. 01
   Descrivere l'obiettivo, non i passaggi

   Fornire a Orchestrator il risultato atteso anziché l'elenco dei file da modificare; è proprio questa suddivisione che la modalità deve produrre.
2. 02
   Attendere che ogni sottoattività restituisca il risultato prima di avviare la successiva

   La modalità attende il risultato di una delega prima di avviare la successiva, offrendo così punti di pausa naturali per rileggere ciò che è stato appena fatto.
3. 03
   Tenere d'occhio la modalità attiva in ogni fase

   L'interfaccia indica quale modalità è attiva in un dato momento; un passaggio inatteso alla modalità Code durante un'attività che dovrebbe limitarsi alla sola lettura è il segnale da tenere sotto controllo in via prioritaria.

Con un modello locale, questa suddivisione ha un costo diretto e misurabile: ogni sottoattività delegata comporta una nuova chiamata al modello, quindi una nuova generazione completa con il proprio tempo di caricamento del contesto. Orchestrator vale la pena per un'attività realmente articolata, con più file e più aspetti distinti da gestire; per una modifica semplice, aggiunge scambi senza apportare nulla di concreto, e l'uso diretto della modalità Code rimane sensibilmente più rapido per raggiungere esattamente lo stesso risultato finale.

#Usarlo bene

Compiti circoscritti

« Aggiungi questo parametro e propagalo nelle tre funzioni che lo chiamano », non « migliora questo modulo ». Più la richiesta è precisa, meno il modello ha spazio per interpretare a modo suo, ed è proprio questo margine di interpretazione a generare la maggior parte dei diff deludenti.

Un repository pulito

Lavorare su un ramo dedicato con un albero di lavoro pulito rende ogni diff leggibile a colpo d'occhio e ogni errore annullabile con il revert di un commit, senza dover districare le modifiche dell'agente dalle tue modifiche in corso.

Rileggere ogni diff

Un modello locale produce regolarmente modifiche plausibili che compilano, superano una revisione rapida e tuttavia non fanno ciò che volevi realmente. La compilazione non è una prova di correttezza, ma soltanto dell'assenza di errori di sintassi.

Diffidare dei contenuti esterni

Un ticket, un file di documentazione di una dipendenza o un commento già presente nel codice può contenere un'istruzione destinata all'agente piuttosto che a te — vedi la sezione sicurezza qui sotto per capire cosa cambia concretamente.

#Risoluzione dei problemi: i blocchi più comuni

La maggior parte dei blocchi con un modello locale deriva da tre cause riconoscibili e facili da distinguere, da verificare sistematicamente prima di attribuire il problema alla qualità intrinseca del modello stesso.

In tutti e tre i casi, la prima domanda da porsi non è «quale modello migliore scegliere», ma «quali contesto e permessi ha effettivamente ricevuto il modello quando ha risposto». Un contesto troncato produce esattamente gli stessi sintomi visibili di un modello sottodimensionato, ma il costo della diagnosi e la soluzione sono molto diversi una volta identificata la vera causa.

#Il rischio specifico di un agente che legge il tuo progetto

Un agente di modifica del codice consulta, per sua natura, contenuti che non hai scritto tu stesso: un README di una dipendenza di terze parti, un ticket incollato nella conversazione, un commento già presente nel repository clonato da un'altra fonte. Nulla impedisce a uno di questi contenuti di veicolare un'istruzione destinata al modello anziché a te — è il principio stesso della prompt injection, spiegato nella guida dedicata qui sotto, e un agente dotato di un terminale e di accesso in scrittura è un bersaglio ben più interessante per questo tipo di attacco rispetto a un semplice chatbot senza strumenti.

È proprio qui che le modalità di Roo Code smettono di essere una semplice comodità organizzativa e diventano una misura di sicurezza concreta. Una modalità Ask, limitata alla lettura, semplicemente non può eseguire l'istruzione nascosta in un ticket, anche se l'ha letta e anche se il modello sottostante si è lasciato influenzare da essa. La protezione non deriva da un modello più intelligente capace di riconoscere la trappola, ma da un insieme di permessi che rende tecnicamente impossibile eseguire l'istruzione, indipendentemente da ciò che il modello ha deciso di fare.

• Prompt injection: l'esecuzione in locale non ti protegge
• Fonte: documentazione ufficiale delle modalità di Roo Code
• Fonte: configurazione ufficiale del fornitore Ollama
• Fonte: repository ufficiale di Roo Code su GitHub, stato archiviato
• Fonte: resoconto della chiusura di Roo Code e delle alternative (stampa specializzata)

#FAQ