Lo esencial: en junio de 2026, Retool da el salto a un app builder exclusivamente basado en IA sobre una nueva arquitectura full-stack en React/TypeScript, combinado con un servidor MCP que permite crear aplicaciones Retool desde cualquier agente de programación con IA (Claude, Codex…). La ambición es aprovechar la velocidad de la IA generativa sin perder la gobernanza empresarial que diferencia a Retool de las herramientas de «vibe coding» (Lovable, Replit, v0…).
1. Lista de novedades
La novedad principal: el paso de un motor de renderizado propietario y cerrado a un stack React + TypeScript estándar e inspeccionable.
Hasta ahora, las abstracciones propietarias de Retool permitían construir rápido, pero tenían tres límites: los modelos de IA no podían trabajar de forma nativa en el formato de Retool, los desarrolladores no podían aportar sus propias herramientas y flujos de trabajo, y las aplicaciones construidas en otras plataformas (Replit, Lovable, v0, etc.) no podían ejecutarse en Retool ni heredar su gobernanza centralizada. Con este nuevo motor, las aplicaciones Retool se escriben ahora en React en el frontend y en TypeScript en el backend: el agente de IA genera código estándar, inspeccionable, reutilizable y mejorable por cualquier equipo técnico, sin encerrar nada en un formato propietario (fuente).
1.1 Replantear la experiencia como un verdadero editor de IA
La funcionalidad se activa desde la configuración de la organización, con la posibilidad de conectar su propio modelo (AWS Bedrock, Azure, OpenAI…) en lugar de depender únicamente del modelo predeterminado de Retool.
El nuevo editor está pensado para un uso prompt-first: se puede dirigir un prompt a toda la aplicación o hacer clic en un elemento concreto de la vista previa para limitar el prompt a ese componente (fuente).
1.2 Mejora del chatbot dentro de la aplicación
Retool también ha abierto la puerta a muchos más tipos de entrada que antes: ahora se pueden arrastrar y soltar capturas de pantalla, PDF, archivos de diseño (Figma…) u hojas de cálculo, y el agente trabaja directamente a partir de las mismas referencias que ya utiliza el equipo. Esto permite retomar el trabajo ya realizado en otras herramientas (maquetas, especificaciones, conjuntos de datos) y trasladarlo a Retool para seguir construyendo la aplicación (fuente).
- Pestaña Code: inspección y edición directa del React generado; al hacer clic en un elemento de la vista previa, se accede directamente a la línea de código correspondiente.
- Pestaña Data: mientras que las aplicaciones generadas por IA suelen dificultar saber qué hacen realmente con los datos, Retool mantiene esta capa legible por diseño: cada lógica de acceso a datos se expone como una función que se puede abrir y entender. Para las lógicas condicionales más complejas, un grafo de datos visual muestra las relaciones entre las entradas y las fuentes de datos, y cómo las acciones del usuario se traducen en operaciones sobre los datos.
Importación de aplicaciones existentes: si tengo una aplicación React ya empezada en Lovable, Replit, v0 o cualquier otra herramienta de vibe coding, o incluso un proyecto React procedente de un repositorio local, ahora puedo importarla directamente para desplegarla en Retool, sin reescribirla. Durante la importación, Retool asocia automáticamente las conexiones de datos de la aplicación con los recursos ya configurados y protegidos por mi equipo. La aplicación hereda además los permisos de Retool a nivel de aplicación (RBAC), para controlar quién puede consultarla, utilizarla o administrarla, con las mismas reglas que en el resto de Retool (fuente).
El gran punto negativo es que habrá que convertir las aplicaciones creadas con la arquitectura anterior.
En la pestaña Chat, un nuevo acceso directo «Convert classic app» permite convertir directamente una aplicación «clásica» (creada con el antiguo editor de Retool, antes de esta actualización) al nuevo editor React. Un agente importa el código fuente de la app clásica en modo de solo lectura, elabora un plan de conversión en varias fases y, a continuación, convierte las consultas sobre los recursos, el JavaScript y el resto del código en funciones equivalentes dentro del nuevo modelo. La aplicación clásica original nunca se modifica durante el proceso; en aplicaciones complejas, la conversión puede tardar hasta una hora. Las aplicaciones clásicas seguirán siendo compatibles durante al menos dos años tras la disponibilidad general del nuevo editor, por lo que la conversión no es obligatoria (fuente).
1.3 MCP: gestionar Retool desde cualquier agente de IA
Lo esencial: un servidor MCP en beta pública permite gestionar Retool (apps, recursos, usuarios) directamente desde Claude, Cursor, Codex o Kiro, con las mismas salvaguardas de seguridad que la interfaz web.
Gobernanza y seguridad: el lugar donde se construye no debería determinar el nivel de seguridad. Retool extiende su modelo de gobernanza a los agentes de programación conectados: tanto si se mejora una aplicación existente como si se parte de cero a través del MCP, los cambios heredan automáticamente los estándares de seguridad ya aprobados por la organización (control de acceso, audit trail, permisos sobre los datos), configurados una sola vez a nivel de plataforma en lugar de aplicación por aplicación (fuente).
En lugar de abrir un navegador, los administradores pueden interactuar directamente con Retool desde su entorno de programación con IA para:
- construir y modificar aplicaciones y, después, desplegarlas en la plataforma Retool;
- escribir consultas sobre los recursos conectados para alimentar análisis de datos;
- invitar a usuarios de forma masiva o gestionar las invitaciones pendientes;
- auditar los usuarios con acceso a la organización;
- inspeccionar la configuración de la organización y de los entornos de recursos;
- listar todos los recursos conectados y consultar su configuración.
Documentación técnica: MCP tools reference.
¿Se puede ahora exportar el código React para desplegarlo fuera de Retool?
En resumen: el código es más abierto (React/TypeScript, sincronizable con su repositorio Git), pero la ejecución en producción sigue vinculada a la plataforma Retool (changelog).
Estas novedades introducen dos limitaciones.
1.4 Pasarlo todo por la IA, ¿es realmente un avance?
Me planteo dudas sobre una estrategia que obliga (o solo permite) a pasar por la IA para hacer modificaciones. Donde el antiguo editor permitía hacer visible o invisible un botón, o cambiar la acción que desencadena, en dos segundos y con un clic, ahora todo tendrá que pasar por un prompt en lenguaje natural o directamente por código, y después probarse para asegurarse de que no hay efectos secundarios ni malentendidos por parte de la IA. En modificaciones triviales y repetitivas, este rodeo me parece bastante limitante y potencialmente más lento que un clic directo en el antiguo editor.
1.5 La migración forzosa de las aplicaciones complejas
El segundo límite es la obligación, a medio plazo, de migrar las aplicaciones complejas construidas con el editor clásico a este nuevo editor de IA. Retool ha anunciado que solo mantendrá el antiguo editor durante los próximos dos años. Pasado ese plazo, probablemente ya no será posible editar una aplicación de otra forma que no sea mediante la IA, lo que plantea la cuestión de qué ocurrirá con las aplicaciones críticas, complejas y ya estabilizadas, para las que una conversión (incluso asistida por IA) nunca está exenta de riesgos.
2. Por qué este cambio: la verdadera batalla es la gobernanza
Con la IA, cualquiera puede ya crear una aplicación. Enseguida se llega a una situación en la que perfiles operativos sin conocimientos técnicos se convierten en los desarrolladores de sus propias herramientas. El verdadero reto ya no es «¿se puede crear una app fácilmente?», sino «¿cómo se gestiona a escala de toda la empresa?». Retool busca dar respuesta a este reto, y esta aceleración trae consigo nuevos desafíos.
2.1 Visibilidad y puesta en común
Uno de los retos clave es dar visibilidad a las aplicaciones ya desarrolladas, para evitar que dos personas trabajen en paralelo sobre el mismo tema sin saberlo. Esto pasa, en primer lugar, por compartir con claridad qué existe o está en desarrollo, de modo que los nuevos empleados puedan encontrar rápidamente las aplicaciones ya implantadas en lugar de empezar de cero, lo que requiere una documentación o un inventario centralizado y accesible para todos. A más largo plazo, el objetivo es también poner en común los desarrollos: Retool permite que varias personas trabajen en una misma aplicación gestionando entornos separados (pruebas/producción, o por equipo), lo que abre la puerta a una colaboración estructurada en lugar de desarrollos aislados y redundantes.
2.2 Alojamiento y centralización
Hoy en día, algunas aplicaciones se ejecutan en local y otras están alojadas en cualquier parte (Cloudflare, Vercel, AWS…), lo que hace muy difícil que una empresa tenga una visión global y centralizada de todo lo que existe. Esta dispersión complica varios aspectos esenciales:
- El RGPD: un desarrollador puede elegir un proveedor de alojamiento simplemente porque se lo sugiere una IA o un tutorial, sin conocer las restricciones de localización de los datos (alojamiento fuera de la UE, transferencias de datos personales, etc.), lo que expone a la empresa a riesgos de cumplimiento que no controla.
- La facturación: cada servicio (alojamiento, nombre de dominio, base de datos, API de terceros…) genera su propia factura, a menudo con una tarjeta bancaria o una cuenta distinta, lo que hace muy tedioso el seguimiento de los costes y su asignación a un proyecto concreto.
- DNS y URLs: cuando cada aplicación tiene su propio nombre de dominio o subdominio configurado en un proveedor distinto, nadie en la empresa sabe con precisión a dónde apunta cada cosa, ni quién tiene permisos para modificarlo en caso necesario (renovación, migración, incidencia).
A esto se suman otros riesgos: la seguridad y la gestión de accesos (contraseñas y claves de API dispersas entre varias plataformas, sin una visión centralizada de quién tiene acceso a qué), la dependencia de una sola persona que conoce la arquitectura de una aplicación (si esa persona deja la empresa, nadie sabe cómo está alojado el servicio ni cómo mantenerlo) y la deuda técnica derivada de la falta de estándares comunes, que encarece cada nueva aplicación a la hora de retomarla o hacerla evolucionar.
2.3 Seguridad y permisos
Otro reto importante es centralizar la gestión de permisos. Se trata de saber con precisión quién tiene acceso a qué, en función de la sensibilidad de la aplicación, de su criticidad y de los datos que maneja. Esto implica gestionar la conexión entre herramientas sin perder el control sobre esos accesos. Por ejemplo, hay que evitar que cualquiera pueda leer o escribir en el CRM, que sigue siendo una herramienta central y crítica para la empresa, y en el que una mala manipulación puede tener consecuencias graves.
Esto pasa también por segmentar los entornos y las claves de API por equipo o por usuario. Es un punto verdaderamente clave para limitar el radio de impacto en caso de error o de fuga: si cada equipo o cada aplicación dispone de sus propios accesos aislados, un problema en uno de ellos no expone todo el sistema, y resulta mucho más fácil identificar el origen de una incidencia y acotarla rápidamente.
3. Conclusión
Con esta nueva estrategia, Retool se posiciona como competidor directo de Lovable for Enterprise en el segmento empresarial: mientras que las herramientas de vibe coding apuestan por la velocidad de generación pura, Retool añade la capa de gobernanza (permisos, audit trail, conexiones seguras a los recursos, RBAC) que faltaba hasta ahora para desplegar este tipo de aplicaciones a escala de toda una organización. Este reposicionamiento no es un simple ajuste de producto: refleja un cambio de fondo en la forma en que las empresas tendrán que gestionar la proliferación de aplicaciones internas creadas con IA.
Estoy convencido de que toda empresa que no aborde este tema en los próximos meses se encontrará con dificultades importantes: multiplicación de aplicaciones no inventariadas, dispersión de alojamientos y accesos, dependencia de unas pocas personas clave que saben cómo se construyó una herramienta y una exposición creciente a riesgos de seguridad y de cumplimiento (en particular del RGPD) que la empresa ya no controla. El verdadero riesgo no es que los equipos creen aplicaciones con IA —eso va a continuar, con o sin marco—, sino que lo hagan sin ninguna gobernanza centralizada.
El objetivo es centralizar las aplicaciones (visibilidad, ciclo de vida, alojamiento), centralizar la autenticación y los permisos (quién tiene acceso a qué, con qué claves y en qué entornos) y centralizar las skills o componentes reutilizables (conectores a los recursos, flujos de trabajo, estándares de desarrollo), para que cada nueva aplicación se apoye en una base común en lugar de empezar de cero, además de una serie de pruebas antes del paso a producción. Es esta centralización la que permite conservar la ganancia de velocidad que aporta la IA generativa sin sufrir sus efectos secundarios en materia de seguridad, costes y deuda técnica.