Lovable redujo los callejones sin salida un 5% con archivos de conocimiento y RAG

Un agente de IA autónomo parece más potente que uno controlado: puede planificar por sí mismo, invocar herramientas, crear subtareas y trabajar hasta alcanzar el objetivo. Lovable probó esta idea en un producto con el que las personas crean aplicaciones mediante un chat y obtuvo el efecto contrario. Los agentes se perdían en laberintos técnicos, acumulaban errores y no lograban terminar el trabajo de forma predecible.

El equipo eliminó temporalmente casi todo el código complejo del agente. En lugar de un ciclo abierto, mantuvo una secuencia clara: solicitud del usuario, cambios en los archivos, verificación del resultado en una vista previa en vivo y siguiente solicitud. Más adelante recuperó la autonomía, pero acompañada de una infraestructura que permitía detectar rápidamente los errores y probar otra vía de forma segura.

Primero hay que acotar la tarea

Lovable se centró inicialmente en aplicaciones nuevas y eligió una única pila tecnológica. El usuario aporta una idea, y el servicio crea el código y lo ejecuta en un entorno definido de antemano. Esto es mucho más sencillo que trabajar con cualquier repositorio existente, donde pueden aparecer dependencias, versiones y métodos de compilación arbitrarios.

Imaginemos un agente que debe añadir un formulario de pago. En un proyecto cualquiera, primero tiene que comprender la arquitectura, el gestor de paquetes, las reglas para gestionar secretos y el esquema de despliegue. En una pila controlada, la mayoría de esas decisiones ya están tomadas. Al agente solo le queda resolver la tarea concreta, mientras que la plataforma sabe cómo verificar el resultado.

La lección práctica no es que todo el mundo necesite el mismo framework. Hay una regla más útil: la libertad del agente debe corresponderse con la capacidad del modelo para detectar y corregir sus propios errores. Si el modelo todavía utiliza las herramientas de manera inestable, un proceso corto y controlado puede ofrecer un producto mejor que una autonomía de múltiples pasos.

Las instrucciones resultaron más útiles que un primer modelo ajustado

El equipo esperaba ajustar modelos con el historial de las sesiones de los usuarios. En la práctica, unos simples archivos de texto dieron resultados más rápido. Los ingenieros estudiaron aplicaciones defectuosas, identificaron causas recurrentes y redactaron reglas breves. Por ejemplo: utilizar únicamente iconos que existan realmente en la biblioteca elegida y, en caso de duda, escoger uno universal.

Antes de cada generación, el buscador seleccionaba las reglas pertinentes y las añadía al contexto del modelo. En esencia, era la combinación hoy habitual de una base de instrucciones y RAG. Una vez analizado un fallo, este podía ayudar a los siguientes usuarios sin necesidad de otro ciclo de entrenamiento. Según la propia Lovable, una primera versión de su sistema de búsqueda de problemas y soluciones redujo un 5% la proporción de usuarios que se quedaban atascados durante el trabajo. Se trata de una métrica interna de la empresa, por lo que no debe interpretarse como un resultado universal.

Este enfoque también resulta práctico desde el punto de vista organizativo para un equipo de producto. Una regla se puede leer, debatir, modificar y vincular con un error concreto. Sin embargo, una base de conocimiento exige mantenimiento: las instrucciones contradictorias u obsoletas pueden empeorar el resultado con la misma facilidad con la que unas buenas instrucciones pueden mejorarlo.

La velocidad depende de la verificación, no solo del modelo

Lovable mantiene en ejecución el entorno del proyecto, actualiza la vista previa sin una compilación completa de producción y realiza verificaciones incrementales de TypeScript por separado. El error vuelve antes al agente, que puede preparar una corrección mientras la aplicación sigue funcionando. Más adelante, la plataforma aprendió a conservar el estado del entorno y a crear ramificaciones de este junto con los archivos, los procesos y la base de datos.

Aquí se encuentra la conclusión más práctica. Al desarrollar un agente, no hay que medir únicamente el tiempo hasta la primera respuesta, sino el ciclo completo: cambio, verificación, detección del fallo y corrección. Empieza con un conjunto limitado de acciones, convierte los errores recurrentes en instrucciones verificables y añade autonomía solo donde exista una señal rápida sobre el resultado y una reversión segura. Lovable no ha demostrado haber encontrado la arquitectura definitiva. Sin embargo, su historia muestra claramente por qué un agente fiable no es solo un modelo potente, sino un modelo dentro de un sistema correctamente limitado y observable.