VillaSlot y ShipSaaS: la arquitectura que permite a los agentes de IA entregar sin crear código espagueti
Mike Codeur
Ver la masterclass completa de 50 minutos
Nueve horas de ejecución autónoma y una pregunta válida
VillaSlot se construyó durante una ejecución autónoma de nueve horas. El agente trabajó sobre veinte historias de usuario en esa secuencia. El primer vídeo se centraba en la velocidad: un agente puede asumir un alcance considerable, trabajar durante varias horas y producir una aplicación funcional.
Varios desarrolladores reaccionaron con la misma crítica: «Esto es vibe code». La observación merece una respuesta mejor que ponerse a la defensiva. Una interfaz que funciona no demuestra por sí sola que el proyecto tenga una estructura sana, que los accesos sean seguros o que el producto siga siendo fácil de modificar dentro de seis meses. Hay que abrir la arquitectura y examinarla.
La velocidad no demuestra la calidad
Un agente rápido puede escribir código bueno o malo. La duración de la ejecución no permite distinguirlos. La calidad se observa en las decisiones de arquitectura, los límites entre responsabilidades, las pruebas y los controles que deben superarse antes de dar una historia por terminada.
ShipSaaS aporta una base Full Stack ya organizada. El agente no inventa la forma general de la aplicación con cada historia. Trabaja dentro de límites conocidos. Esos límites reducen las decisiones improvisadas, facilitan la revisión de los cambios y ofrecen puntos estables desde los que probar el sistema.
El multitenancy empieza en la arquitectura
VillaSlot es una aplicación multitenant. Varias organizaciones utilizan el mismo producto, pero mantienen separados sus espacios y sus datos. Esa condición afecta a casi todas las operaciones. Una solicitud válida debe proceder de un usuario autenticado, aunque eso solo es el primer requisito. También debe ejecutarse en el contexto de la organización correcta.
Autenticación, usuarios y organizaciones
La autenticación establece quién realiza una acción. Esa identidad se vincula con un usuario de la aplicación y con una organización. La organización se convierte entonces en una frontera funcional para las lecturas y escrituras.
Esta distinción evita un atajo peligroso: asumir que un usuario conectado puede acceder a cualquier recurso cuyo identificador consiga enviar. En un SaaS multitenant, la aplicación debe imponer el contexto de la organización en todos los puntos donde el acceso sea relevante. Un identificador enviado por la interfaz nunca demuestra una autorización.
El aislamiento de datos no es un filtro visual
Ocultar un elemento en la interfaz no protege sus datos. El aislamiento debe aplicarse en el servidor, cuando se valida la operación y cuando se consulta la capa de persistencia. Por eso el contexto de la organización acompaña a la solicitud.
Tres capas con funciones distintas
ShipSaaS divide el sistema en Presentación, Servicios y Persistencia. Los nombres son conocidos. Lo que importa es aplicarlos de forma constante.
Presentación
La capa de Presentación gestiona lo que ve el usuario y el inicio de las acciones. Recoge datos, muestra estados útiles y envía una intención al servidor. No debe decidir por sí sola las reglas de negocio ni abrir una vía directa hacia la base de datos.
Servicios
La capa de Servicios contiene los casos de uso. Recibe una solicitud, comprueba las condiciones necesarias, aplica las reglas de negocio y coordina la operación. En ella, el contexto autenticado y la pertenencia a una organización adquieren un significado operativo.
Persistencia
La capa de Persistencia lee y escribe datos. Encapsula la forma de consultar el almacenamiento y devuelve resultados que los servicios pueden utilizar. No decide cómo debe comportarse la experiencia de usuario.
El recorrido de un caso de uso, de la interfaz a la base de datos
Pensemos en el recorrido genérico de una acción dentro de VillaSlot. Un usuario inicia una operación en la interfaz. La capa de Presentación reúne los datos necesarios y envía la solicitud. El servidor identifica al usuario autenticado, resuelve el contexto de su organización y entrega un comando estructurado a la capa de Servicios.
El servicio comprueba las precondiciones y las reglas de negocio. No acepta el identificador del recurso como prueba de acceso. Combina el recurso solicitado con el contexto de la organización y llama a Persistencia. Esta realiza una lectura o escritura limitada a ese ámbito. El resultado vuelve al servicio, que lo convierte en una respuesta útil, y después a Presentación, que actualiza la pantalla.
Los agentes necesitan reglas, no solo tareas
Un agente de programación no debería recibir únicamente una historia de usuario. También necesita las convenciones del proyecto, los límites arquitectónicos y una definición comprobable de «terminado». Sin ese marco, tenderá a optimizar el resultado más visible: conseguir que funcione el escenario principal.
Las reglas obligan a respetar las capas, reutilizar los recorridos existentes, conservar el contexto multitenant y no esquivar la autenticación. También exigen tratar los errores y verificar el efecto real de un cambio. No se busca frenar la iniciativa útil del agente. Se busca reducir el espacio en el que una solución rápida puede entrar en conflicto con el resto del sistema.
El ciclo de entrega que rodea cada historia
La entrega no acaba cuando el código compila o la pantalla parece correcta. El ciclo comienza con los criterios de aceptación. Estos convierten la petición en comportamientos observables y evitan que un agente declare el trabajo terminado a partir de una interpretación ambigua.
Después llega el TDD: escribir o adaptar pruebas, observar la necesidad aún no cubierta, implementar el comportamiento esperado y limpiar el código sin perder la prueba. Una revisión separada examina el cambio desde otra perspectiva. Esa separación importa porque quien crea una solución, sea una persona o un agente, tiende a ver lo que quería escribir y no solo lo que quedó escrito.
A continuación se ejecutan las pruebas automatizadas. El flujo también se comprueba de extremo a extremo en Chrome para verificar la integración real entre interfaz, servidor y datos. Luego se realiza un control visual. Una prueba funcional puede pasar aunque la pantalla esté recortada, resulte ilegible o tenga incoherencias.
Cuando aparece un problema, el agente no se limita a informar. El ciclo de auto-fix devuelve el fallo a la implementación y después repite las comprobaciones. El recorrido completo queda así: criterios, TDD, revisión separada, pruebas, E2E en Chrome, control visual, corrección automática y una nueva validación.
Lo que este método no garantiza
Ninguna arquitectura convierte a un agente en infalible. Las reglas pueden estar incompletas, las pruebas pueden omitir un caso y una revisión puede no detectar un defecto. Una base bien estructurada también necesita mantenimiento a medida que cambia el producto.
La ejecución autónoma de nueve horas no sustituye la responsabilidad técnica ni el criterio de producto. Demuestra que un agente puede avanzar rápido cuando el sistema hace visibles los caminos correctos y permite detectar las desviaciones. Las fronteras de autorización siguen necesitando atención, las pruebas deben mejorar y las decisiones que dejen de encajar deben revisarse.
Examinar la arquitectura en vez de discutir una etiqueta
Llamar «vibe code» a VillaSlot no evalúa el resultado. Las preguntas útiles son concretas. ¿Están separadas las responsabilidades? ¿El contexto de la organización acompaña cada operación? ¿Los datos de cada tenant están aislados? ¿Cada historia pasa por un ciclo de prueba, revisión y corrección?
El primer vídeo enseñaba la velocidad. Esta masterclass muestra los mecanismos que impiden que esa velocidad produzca un montón de código frágil. ShipSaaS aporta la estructura Full Stack, VillaSlot la aplica en un producto real y los agentes trabajan con reglas que se pueden inspeccionar.