🦘 Roo Code: el agente que convirtió el editor en un equipo de desarrollo (y que se apagó en mayo de 2026)

Hay una historia que conviene contar antes de cualquier análisis técnico: Roo Code fue, durante un tiempo, uno de los agentes de código más queridos dentro de VS Code. Tenía algo que Cline no tenía (modos personalizables), y algo que Cursor no tenía (BYOK real, sin suscripción). Pero el 15 de mayo de 2026, sus creadores lo apagaron. No fue una quiebra ni un cierre abrupto. Fue una decisión estratégica: el equipo decidió que el futuro de los agentes no estaba en el IDE, sino en la nube. Y aunque el repositorio sigue accesible y la extensión todavía se puede instalar, ya no recibe actualizaciones, ni parches de seguridad, ni adaptación a nuevas versiones de la API de VS Code. Este artículo es un análisis honesto de lo que fue, lo que hizo bien, y qué opciones tienes si estabas pensando en usarlo.

🔍 ¿Qué era exactamente Roo Code?

Roo Code era un agente de programación autónomo que vivía dentro de tu editor, principalmente VS Code. Nació como un fork de Cline —de hecho, durante un tiempo se llamó Roo Cline— y su objetivo era añadir capas de personalización que el proyecto original no ofrecía: modos especializados, perfiles de modelo por tarea, y un sistema de aprobación granular que te permitía decidir exactamente qué podía hacer el agente sin preguntar.

La diferencia clave con Cline era arquitectónica: mientras Cline te daba un agente general que intentaba hacerlo todo, Roo Code separaba el trabajo en modos con permisos distintos. El modo Architect solo podía leer y planificar. El modo Ask solo podía leer y responder preguntas. El modo Code tenía acceso completo. Y podías crear modos personalizados para lo que necesitaras: auditoría de seguridad, optimización de rendimiento, documentación.

¿Qué problema resolvía? El mismo que todos los agentes de código: automatizar trabajo de desarrollo. Pero Roo Code atacaba un problema específico que Cline no resolvía bien: el control. En Cline, si le pedías que arreglara un bug, podía lanzarse a reescribir archivos enteros sin que se lo pidieras. Roo Code, con sus modos separados, te permitía decir solo quiero que analices este problema sin riesgo de que el agente empezara a modificar código por su cuenta.

Roo Code Inc. anunció el cierre el 21 de abril de 2026 y apagó la extensión y el repositorio el 15 de mayo del mismo año. La versión final fue la 3.54.0. El equipo se movió a construir Roomote, un agente en la nube que se integra con Slack, GitHub y Linear, y que no vive en un IDE.

🧩 Funciones principales

• Modos especializados con permisos distintos: la característica que definía a Roo Code. Code (acceso completo), Architect (solo lectura más markdown), Ask (solo lectura), Debug (diagnóstico), y Orchestrator (delegación a otros modos sin acceso directo a herramientas). Cada modo tiene su propio conjunto de permisos y su propio modelo asignado.
• Modelos sticky por modo: cada modo recordaba el último modelo que usaste. Podías tener Gemini para Architect, Claude Sonnet para Code, y un modelo barato para Ask. Al cambiar de modo, Roo cambiaba de modelo automáticamente sin que tuvieras que seleccionarlo de nuevo.
• Modos personalizados: podías crear un número ilimitado de modos con sus propios permisos, instrucciones y modelos. Un modo para auditoría de seguridad que solo podía leer. Un modo para documentación que solo podía escribir markdown. Un modo para refactorización con acceso completo.
• Orchestrator Mode (Boomerang): un modo que no tenía acceso directo a herramientas, pero podía descomponer tareas complejas y delegar subtareas a otros modos usando la herramienta new_task. Recibía solo el resumen de cada subtarea, no el historial completo, lo que mantenía el contexto principal limpio.
• Control de aprobación granular: podías configurar aprobación automática por categoría: lectura, escritura, ejecución de comandos, navegador, MCP. Permitías que las ediciones rutinarias se hicieran sin interrupción, pero los comandos peligrosos requerían confirmación manual.
• BYOK multi-proveedor: funcionaba con OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, y modelos locales vía Ollama o LM Studio. Sin markup. Pagabas directamente al proveedor.
• MCP (Model Context Protocol): soporte completo para conectar herramientas externas. Podías integrar APIs, bases de datos, o servicios internos.
• Control de navegador: el agente podía abrir un navegador, navegar, hacer clic, escribir, y extraer datos. Útil para testing de frontend o investigación web.

✨ Lo que lo diferenciaba de otros

Roo Code no era el agente más potente. No era el más rápido. No tenía la mejor interfaz. Pero tenía algo que otros no: la separación entre pensar y hacer era real, no un prompt disfrazado.

• Los modos eran capas de seguridad, no solo cambios de prompt: en Cursor o Cline, cuando le pedías al agente que piense antes de actuar, era una sugerencia. En Roo Code, el modo Architect literalmente no podía editar archivos de código. Los permisos eran reales, aplicados a nivel de herramienta. Si querías que el agente no tocara nada mientras explorabas una idea, cambiabas a Ask y no había riesgo.
• La personalización era el producto: Roo Code no te decía cómo trabajar. Te daba las piezas para que construyeras tu flujo. Si querías un modo que solo pudiera editar archivos de test, lo creabas. Si querías un modo que solo pudiera leer documentación y responder preguntas, lo creabas. La flexibilidad era el punto.
• BYOK sin sorpresas: a diferencia de Cursor (suscripción fija) o Copilot (créditos mensuales), Roo Code te dejaba pagar exactamente lo que consumías. Si usabas modelos locales, el coste era cero. Si usabas modelos baratos, unos pocos euros al mes. No había subsidios ocultos ni cuotas que se agotaban.
• La comunidad lo quería: más de 3.400 forks en GitHub. Una comunidad activa que creaba modos, compartía configuraciones, y extendía el proyecto. Cuando Roo Code se apagó, la comunidad respondió inmediatamente con Zoo Code, un fork que continuó el desarrollo.

🎯 ¿Para qué se usaba en la práctica?

Roo Code brillaba en flujos de trabajo donde el control importaba más que la velocidad.

• Desarrollo con separación de fases: planificar en Architect, implementar en Code, diagnosticar en Debug. Cada fase con su modelo, sus permisos, y su contexto. Reducía los errores de lanzarse a codificar sin pensar.
• Auditoría y revisión de código: el modo Ask solo lectura era perfecto para analizar código sin riesgo de modificarlo. Podías preguntar qué hace esta función o si hay algún problema de seguridad aquí sin que el agente se sintiera tentado a arreglarlo.
• Proyectos con código sensible: la opción de usar modelos locales vía Ollama significaba que el código nunca salía de tu máquina. Para equipos con requisitos de compliance, era una capacidad crítica.
• Equipos con flujos personalizados: si tu equipo tenía convenciones específicas o roles especializados, Roo Code te dejaba crear modos que los reflejaran. Un modo para QA, un modo para documentación, un modo para refactorización.
• Orquestación de tareas complejas: el modo Orchestrator permitía descomponer una tarea grande y delegar subtareas a otros modos. El contexto se mantenía limpio porque solo recibías resúmenes, no historiales completos.

🚀 Cómo se usaba (mientras funcionaba)

El setup era directo, sin cuenta ni login obligatorio.

1. Instalar la extensión: desde el VS Code Marketplace, buscar Roo Code e instalar. También había versión para VSCodium y otros editores compatibles.
2. Configurar un proveedor: al abrir Roo Code por primera vez, elegías entre OpenRouter, Anthropic, OpenAI, Google Gemini, o modelos locales. Introducías tu API key o configurabas la conexión local.
3. Elegir un modo: el desplegable en la parte inferior izquierda del chat te permitía cambiar entre Code, Architect, Ask, Debug, y Orchestrator. También podías usar comandos como /architect o /ask.
4. Asignar modelos a modos: en la configuración, podías asignar un modelo distinto a cada modo. Roo recordaba tus elecciones y las aplicaba al cambiar de modo.
5. Lanzar una tarea: describías lo que querías en lenguaje natural. En Architect, el agente planificaba. En Code, implementaba. En Ask, respondía sin tocar nada.

💡 Trucos que marcaban la diferencia

• Usa Architect antes de Code: el flujo que mejor funcionaba era planificar primero. Pídele a Architect que diseñe la solución sin escribir código. Revísalo. Luego cambia a Code con el plan aprobado. Reduce los errores de lanzarse a codificar.
• Asigna modelos baratos a Ask y Architect: no necesitas un modelo caro para responder preguntas o planificar. Usa Gemini Flash o un modelo local para Ask, y reserva Claude Sonnet u Opus para Code. Ahorras coste sin sacrificar calidad en la implementación.
• Crea modos personalizados para tu equipo: si tu equipo tiene convenciones específicas, crea un modo que las aplique. Un modo para revisión de código que solo lea y comente. Un modo para documentación que solo escriba markdown. La flexibilidad era la ventaja principal.
• Configura la aprobación automática con cuidado: permitir escritura automática acelera mucho, pero también aumenta el riesgo. Empieza con aprobación manual para todo, y activa auto-aprobación solo para categorías en las que confíes plenamente.
• Usa el modo Debug para problemas difíciles: Debug tenía instrucciones específicas para reflexionar, aislar posibilidades, añadir logs, y confirmar antes de arreglar. Es un flujo más sistemático que simplemente pedirle a Code que arregle algo.

🖥️ Dónde funcionaba

• VS Code: la superficie principal y la única oficialmente soportada. La extensión sigue instalable desde el marketplace, pero ya no recibe actualizaciones.
• VSCodium y forks compatibles: funcionaba en cualquier editor basado en la API de VS Code.
• Web: no había versión web.
• Móvil: no había apps móviles.
• CLI: Roo Code Inc. ofrecía Roo Cloud, un servicio de ejecución en la nube, pero no era la misma experiencia que la extensión local.

💰 Cuánto costaba

Roo Code era gratis con BYOK. No había suscripción obligatoria ni tiers que desbloquearan funciones.

• Extensión: 0€. Licencia Apache-2.0. Sin telemetría obligatoria.
• BYOK: pagabas directamente al proveedor de modelos. Sin markup de Roo Code. El coste dependía del modelo y del uso. Con modelos locales, cero. Con modelos baratos, unos pocos euros al mes. Con Claude Sonnet intensivo, podía subir.
• Roo Cloud: servicio de ejecución en la nube a $5/hora. Era una opción separada para quien quería ejecutar agentes sin máquina local.
• Enterprise: Roo Code Inc. ofrecía soporte comercial y certificación SOC 2, pero los detalles no están disponibles tras el cierre.

👥 ¿Para quién era?

• Desarrolladores que valoraban el control: si querías un agente que no se lanzara a modificar código sin permiso, Roo Code era la opción más granular.
• Usuarios de VS Code que querían personalización: si tu flujo de trabajo tenía fases distintas (planificar, implementar, revisar), Roo Code te daba las herramientas para reflejarlas.
• Equipos con convenciones específicas: la capacidad de crear modos personalizados permitía adaptar el agente a las reglas del equipo.
• Quien quería privacidad: con modelos locales vía Ollama, el código nunca salía de la máquina.
• Quien no quería suscripciones: BYOK sin markup significaba que pagabas exactamente lo que consumías.

No era para: quien quería una experiencia pulida sin configuración. Roo Code requería decisiones sobre modos, modelos, y permisos. Si eso te abrumaba, Copilot o Cursor eran más sencillos.

🌍 Adopción global

Roo Code tenía más de 3.400 forks en GitHub y una comunidad activa en Reddit y Discord. En el VS Code Marketplace, tenía varias cientos de valoraciones con una puntuación alta. Era uno de los agentes de código open source más populares, con adopción concentrada en Estados Unidos y Europa, especialmente entre desarrolladores que valoraban la personalización y el control de costes.

El cierre en mayo de 2026 fue un golpe para esa comunidad. La empresa lo justificó diciendo que no creemos que los IDEs sean el futuro de la programación y pivotó a Roomote, un agente en la nube. La comunidad respondió creando Zoo Code, un fork que continúa el desarrollo. Kilo Code, otro fork, también se posicionó como alternativa.

⚖️ Lo bueno y lo no tan bueno

Lo que funcionaba bien:

• Separación real entre pensar y hacer: los modos no eran cambios de prompt, eran capas de permisos. El modo Ask no podía editar archivos, punto. Eso eliminaba el riesgo de modificaciones accidentales.
• Personalización sin límites: podías crear modos para cualquier flujo de trabajo. La flexibilidad era el punto fuerte del proyecto.
• BYOK sin markup: pagabas exactamente lo que consumías. Sin suscripciones opacas ni créditos que se agotaban.
• Comunidad activa: 3.400 forks, contribuciones constantes, modos compartidos. El proyecto tenía vida más allá del equipo original.

Lo que no convencía:

• El proyecto está cerrado: desde mayo de 2026, no recibe actualizaciones, parches de seguridad, ni adaptación a nuevas versiones de VS Code. Usarlo hoy es asumir un riesgo creciente.
• La interfaz no era la más pulida: Cursor y Copilot tenían una experiencia de usuario más refinada. Roo Code era funcional pero menos elegante.
• La personalización podía abrumar: con tantos modos, permisos, y configuraciones, era fácil perderse. No era plug-and-play.
• El cierre fue abrupto: la comunidad no fue consultada. El equipo simplemente decidió que el IDE no era el futuro y se marchó. Eso dejó a muchos usuarios en una posición complicada.

🆚 Comparativa con alternativas

Si vienes de Roo Code, el camino más natural es Zoo Code, el fork creado por la comunidad y recomendado por el propio equipo de Roo Code. Kilo Code es otra opción: es un fork de Roo Code que añadió características de Cline y sigue en desarrollo activo. Cline, el proyecto original del que Roo Code nació, también sigue activo pero con menos capacidades de personalización.

✅ Veredicto: ¿merecía la pena?

Sí, mientras funcionaba. Roo Code era una de las mejores opciones para desarrolladores que querían control granular y personalización real. Sus modos con permisos distintos eran una innovación que otros agentes tardaron en copiar. La comunidad lo quería, y el cierre dejó un vacío que los forks intentan llenar.

¿Recomiendo usarlo hoy? No. La extensión sigue instalable, pero no recibe actualizaciones ni parches de seguridad. Cada nueva versión de VS Code aumenta la probabilidad de que algo se rompa. Usarlo hoy es asumir un riesgo creciente sin beneficio claro.

¿Qué hacer si venías de Roo Code? Zoo Code es la continuación más directa y la recomendada por el equipo original. Kilo Code es otra opción sólida si quieres un fork con desarrollo activo y algunas mejoras. Cline sigue siendo la opción más simple si no necesitas tanta personalización.

Roo Code fue un gran proyecto. Su cierre es una lección sobre el riesgo de depender de herramientas que pueden desaparecer cuando el equipo decide pivotar. La buena noticia es que el código es Apache-2.0, y la comunidad sigue trabajando en los forks.