Roo Code: el agente de código local en el editor

#Qué es

Entre el autocompletado de código, que predice la siguiente línea mientras escribes, y el agente autónomo, que trabaja solo en un contenedor sin supervisión continua, existe una categoría intermedia: el agente en el editor. Ve tu proyecto abierto, entiende el árbol de archivos y sus dependencias, propone modificaciones que validas antes de que se guarden en el disco y ejecuta comandos en tu terminal con tu aprobación explícita cada vez. Roo Code pertenece a esta familia, junto con proyectos como Cline, con el que comparte en gran medida la filosofía.

La ventaja frente a un asistente conversacional es que ya no hay que copiar y pegar: los cambios llegan en forma de diff a los archivos correspondientes. La ventaja frente a un agente autónomo es que sigues participando en cada paso, algo que importa aún más cuanto más pequeño es el modelo. El proyecto, publicado bajo licencia Apache 2.0, había superado las 20.000 estrellas en GitHub desde su lanzamiento a finales de 2024, un ritmo de adopción rápido en una categoría que se había vuelto muy competitiva, antes del anuncio de cese detallado a continuación.

#La extensión está descontinuada desde mayo de 2026: qué cambia

Esta es la información más importante de esta guía, y la que muchos tutoriales que siguen en línea no mencionan. Matt Rubens, el fundador, anunció el 21 de abril de 2026 el cese de Roo Code: última publicación el 15 de mayo de 2026 y repositorio de GitHub archivado después, bloqueado en modo de solo lectura, sin más correcciones, ni siquiera de seguridad. Una comprobación directa del repositorio lo confirma: estado archivado, último commit fechado el 15 de mayo de 2026. El equipo se ha volcado por completo en Roomote, un agente en la nube controlado desde Slack, al considerar que el editor de código ya no es, en su opinión, el futuro del trabajo con un agente de IA.

#Los modos y por qué son una buena idea

La particularidad de Roo Code es que separa las personalidades. Incluye cinco modos de forma predeterminada: Code, para escribir y modificar con acceso completo a las herramientas; Ask, un asistente técnico que responde en detalle pero no toca nada (solo lectura y MCP); Architect, un planificador cuyos permisos de escritura se limitan a los archivos markdown, pensado para diseñar antes de actuar; Debug, orientado al diagnóstico sistemático con acceso completo; y Orchestrator, también llamado «Boomerang Mode», que divide una tarea compleja y la delega a los otros modos. Sigue siendo posible definir otros modos, con sus propias instrucciones y sus propios permisos.

Con un modelo local, es más que una comodidad. Un modo Ask sin permiso para escribir elimina la categoría de incidentes en los que un modelo demasiado pequeño modifica un archivo por exceso de celo. Restringir los permisos por modo es la principal manera de hacer que un modelo pequeño sea utilizable sin riesgo y, de paso, es lo que más acerca a Roo Code a una buena práctica general de seguridad para agentes: dar a cada rol únicamente lo que necesita, nunca más.

#Conectarlo a un modelo local

1. 01
   Servir el modelo

   Ollama o cualquier punto de acceso compatible con OpenAI. Para uso individual, Ollama es más que suficiente.
2. 02
   Elegir Ollama como proveedor en la extensión

   Especificar el nombre o la etiqueta del modelo. La dirección base predeterminada es http://localhost:11434; una clave de API solo es necesaria si tu servidor Ollama la requiere.
3. 03
   Ajustar la ventana de contexto en el lugar adecuado

   Es el escollo más documentado: por defecto, Roo Code se ajusta al valor num_ctx definido en el Modelfile del modelo Ollama, no a un valor propio de la extensión. Por tanto, el contexto se aumenta desde Ollama (Modelfile o variable de entorno), no en los ajustes de Roo Code.
4. 04
   Comenzar en modo Ask

   Plantear tres preguntas sobre el proyecto antes de autorizar cualquier modificación, en un modo que solo tenga permisos de lectura, permite evaluar con honestidad lo que el modelo comprende realmente del código.

#¿Qué modelo, en realidad?

Un modelo de tamaño medio orientado al código casi siempre supera a un modelo generalista más grande en este ejercicio, porque durante su entrenamiento ha visto más formatos estrictos y diffs, en lugar de prosa general. La diferencia se aprecia sobre todo en la capacidad de producir un diff que se aplique a la primera, sin errores de contexto ni de número de línea: un detalle técnico que, en la práctica, importa más que la calidad general de las respuestas del modelo.

• Cline: el otro agente de edición, comparado
• Aider: la misma idea, en el terminal
• Hacer que un modelo local revise tu código

#Orchestrator: dividir una tarea compleja

El modo Orchestrator, también llamado Boomerang Mode en la documentación oficial, cambia la forma de abordar una tarea demasiado grande para resolverla de una sola vez. En lugar de pedir directamente «añade autenticación a mi aplicación», describes el objetivo a Orchestrator, que lo divide en subtareas y las delega a los modos especializados: Architect para elaborar el plan, Code para la implementación y Debug si una prueba falla durante el proceso.

1. 01
   Describir el objetivo, no los pasos

   Dar a Orchestrator el resultado esperado en lugar de la lista de archivos que hay que modificar; es precisamente ese desglose lo que debe producir el modo.
2. 02
   Esperar a que cada subtarea devuelva su resultado antes de iniciar la siguiente

   El modo espera el resultado de una delegación antes de lanzar la siguiente, lo que proporciona momentos naturales para detenerse y revisar lo que se acaba de hacer.
3. 03
   Mantener la vista puesta en el modo activo en cada paso

   La interfaz indica qué modo está activo en cada momento; un cambio inesperado al modo Code en una tarea que debería limitarse a la lectura es la señal que debes vigilar ante todo.

Con un modelo local, esta división tiene un coste directo y medible: cada subtarea delegada supone una nueva llamada al modelo y, por tanto, una nueva generación completa con su propio tiempo de carga del contexto. Orchestrator merece la pena para una tarea realmente compuesta, con varios archivos y distintos aspectos que abordar; para una modificación sencilla, añade idas y vueltas sin aportar nada concreto, y utilizar directamente el modo Code sigue siendo sensiblemente más rápido para alcanzar exactamente el mismo resultado final.

#Usarlo bien

Tareas acotadas

«Añade este parámetro y propágalo en las tres funciones que lo llaman», no «mejora este módulo». Cuanto más precisa sea la solicitud, menos margen tendrá el modelo para interpretarla a su manera, y precisamente ese margen de interpretación es el que produce la mayoría de los diffs decepcionantes.

Un repositorio limpio

Trabajar en una rama dedicada con un árbol de trabajo limpio permite leer cada diff de un vistazo y deshacer cada error revirtiendo un commit, sin tener que separar las modificaciones del agente de tus propios cambios en curso.

Releer cada diff

Un modelo local produce regularmente modificaciones plausibles que se compilan, pasan la revisión rápida y sin embargo no hacen exactamente lo que realmente querías. La compilación no es una prueba de corrección, solo indica la ausencia de errores de sintaxis.

Desconfiar del contenido externo

Un ticket, un archivo de documentación de una dependencia o un comentario ya presente en el código puede contener una instrucción destinada al agente en lugar de a ti — consulta la sección de seguridad a continuación para ver qué cambia concretamente.

#Solución de problemas: los bloqueos más comunes

La mayoría de los bloqueos con un modelo local provienen de tres causas reconocibles y fáciles de distinguir, que hay que verificar sistemáticamente antes de poner en duda la calidad intrínseca del modelo mismo.

En los tres casos, la primera pregunta que debes hacerte no es «¿qué modelo mejor puedo elegir?», sino «¿qué contexto y permisos recibió realmente el modelo en el momento en que respondió?». Un contexto truncado produce exactamente los mismos síntomas visibles que un modelo de capacidad insuficiente, pero el coste del diagnóstico y la solución son muy distintos una vez identificada la causa real.

#El riesgo propio de un agente que lee tu proyecto

Un agente de edición consulta, por naturaleza, contenido que no has escrito tú mismo: un README de una dependencia de terceros, un ticket pegado en la conversación o un comentario ya presente en un repositorio clonado desde otro lugar. Nada impide que alguno de estos contenidos incluya una instrucción dirigida al modelo en lugar de a ti: ese es precisamente el principio de la inyección de prompt, explicado en la guía dedicada a este tema que aparece a continuación, y un agente con un terminal y acceso de escritura es un objetivo mucho más interesante para este tipo de ataque que un simple chatbot sin herramientas.

Es precisamente ahí donde los modos de Roo Code dejan de ser una simple comodidad para organizarse y se convierten en una medida de seguridad concreta. El modo Ask, limitado a la lectura, sencillamente no puede ejecutar la instrucción oculta en un ticket, aunque la haya leído y aunque el modelo subyacente se haya dejado influir por ella. La protección no proviene de un modelo más inteligente que sepa reconocer la trampa, sino de un conjunto de permisos que hace técnicamente imposible ejecutar la instrucción, independientemente de lo que el modelo haya decidido hacer.

• Inyección de prompt: la ejecución local no te protege
• Fuente: documentación oficial de los modos Roo Code
• Fuente: configuración oficial del proveedor Ollama
• Fuente: repositorio oficial de Roo Code en GitHub, estado archivado
• Fuente: relato del cierre de Roo Code y de sus alternativas (prensa especializada)

#FAQ