VillaSlot: cómo sustituí dos flujos SaaS en 48 horas

▶️ Ver el vídeo completo

El soporte de Timely tardó cuatro días en responderme. Dos días después ya tenía la primera versión de VillaSlot. Esa frase explica el detonante, pero no el trabajo que permitió llegar al resultado. No envié «construye un SaaS» a un agente antes de irme a dormir. Preparé un producto que los agentes podían construir y comprobar sin inventar la intención del negocio.

VillaSlot resuelve un problema concreto en la gestión de mis villas. Las reservas por noche estaban en una herramienta, las franjas por hora para sesiones de fotos y eventos en otra, y los pagos tenían que llegar a las cuentas Stripe correctas. Reuní esos flujos en una sola aplicación adaptada a mi forma de trabajar.

Qué sustituye realmente VillaSlot

VillaSlot no pretende sustituir el marketplace completo de Airbnb. No aporta su audiencia, su captación, su red de confianza ni sus operaciones globales. Sustituye los flujos directos que necesito cuando el cliente ya está presente.

Este límite importa. Construir una herramienta de negocio enfocada en 48 horas es posible. Reproducir Airbnb, su demanda, su confianza y sus operaciones no lo es.

Las 48 horas empezaron antes del código

La velocidad vino de la preparación. Definí el producto con Codex y después preparé un PRD, 20 historias de usuario, sus criterios de aceptación, un grafo de dependencias y 20 maquetas. Cada agente recibió una parte acotada del producto con un resultado observable.

Una historia no decía solamente «añadir reservas». Describía el comportamiento esperado, las reglas del negocio y las pruebas necesarias para aceptar el trabajo. Esa preparación evita que el agente invente detalles críticos: qué calendario actualizar, qué cuenta Stripe utilizar, cuándo solicitar un depósito o cómo impedir dos reservas incompatibles.

El grafo de dependencias también fijaba el orden. Una historia que necesitaba el modelo de reservas o el flujo de pago no podía comenzar antes de que esas bases estuvieran listas. El objetivo no era mantener ocupados al mayor número posible de agentes. Era iniciar el trabajo correcto en el momento correcto.

La ejecución autónoma de 9 h 20

Cuando el contrato de trabajo estuvo listo, lancé una ejecución autónoma de 9 horas y 20 minutos durante la noche. El sistema procesó más de cuatro mil millones de tokens con Claude Code y Codex. Ese volumen muestra la intensidad de la ejecución, no la calidad del resultado. La calidad dependía del circuito de pruebas aplicado a cada historia.

El recorrido seguía estos pasos:

1. seleccionar una historia cuyas dependencias ya estuvieran terminadas;
2. leer sus criterios de aceptación y definir las pruebas esperadas;
3. escribir tests antes o durante la implementación;
4. implementar la función;
5. realizar una revisión separada;
6. ejecutar tests unitarios y de integración;
7. probar el recorrido en Chrome;
8. revisar el resultado visual;
9. corregir defectos técnicos o funcionales y repetir las pruebas.

Una historia validada liberaba las siguientes tareas del grafo. Un defecto reproducible volvía al circuito de corrección. Una ambigüedad de producto regresaba a una persona en lugar de convertirse en una decisión oculta dentro del código.

Por qué las maquetas importaban tanto como los tests

Los tests automatizados pueden confirmar que un cálculo, una API o una transición de estado funcionan. No demuestran que un calendario sea legible, que un botón esté en el lugar correcto o que el recorrido tenga sentido en una pantalla real.

Las 20 maquetas dieron a los agentes una referencia visual. La prueba en Chrome comprobó después la aplicación construida, no solo componentes aislados. La revisión visual permitió detectar problemas de maquetación, estados vacíos incoherentes y acciones difíciles de entender.

También separo la implementación de la revisión. El agente que acaba de escribir el código conoce demasiado bien su propia intención. Una pasada distinta examina el diff y las pruebas con menos contexto implícito. Puede equivocarse, pero reduce las validaciones basadas en «debería funcionar».

Qué entregó realmente la ejecución

A la mañana siguiente, la primera versión utilizable estaba lista. Después la enfrenté al uso real y añadí unas diez historias más. Esa segunda fase es tan importante como la primera. Una ejecución autónoma puede aplicar un plan, pero el uso descubre necesidades que el plan inicial no contenía.

Las 48 horas no significan que el producto quedara terminado para siempre. Marcan el tiempo entre un problema de negocio definido y una versión funcional que podía probar en mis villas. La etapa siguiente siguió un ciclo normal de producto: usar, observar, corregir y ampliar.

Los límites de este flujo

Este método no vuelve autónomos a los agentes por arte de magia. Traslada parte del esfuerzo hacia la preparación y la verificación. Falla rápido cuando los criterios son vagos, varias historias comparten un entorno inestable o los agentes pueden aprobar su propio trabajo sin pruebas independientes.

Mantengo varias reglas:

• las decisiones de producto ambiguas vuelven a una persona;
• la salida del terminal no sustituye una prueba funcional;
• un test verde no sustituye la revisión visual;
• una revisión no sustituye el uso real;
• el número de tokens o agentes nunca es un resultado de negocio.

La ventaja no nace de un prompt gigante. Nace de un contrato preciso entre la intención del producto, la implementación y las pruebas. Con esa estructura puedo dejar trabajar a los agentes durante horas sin confundir actividad con entrega.

▶️ Ver VillaSlot, la ejecución y el flujo completo

Para recibir más experiencias reales sobre desarrollo agéntico, únete a The Agentic Dev.