Cómo construí VillaSlot en 48 horas con agentes de IA
Mike Codeur
El soporte técnico de Timely tardó cuatro días en responderme. En lugar de seguir esperando, construí VillaSlot, un SaaS adaptado al funcionamiento de mis villas. La primera versión se desarrolló en 48 horas, con un run autónomo nocturno de 9 horas y 20 minutos.
El resultado no nació de un gran prompt que pedía a una IA «crear un SaaS». Nació de la definición del producto, la descomposición funcional y un ciclo de calidad suficientemente estricto para que los agentes trabajaran durante horas sin supervisión constante.
El problema de negocio
Mis villas utilizan dos modelos de reserva. Los viajeros reservan noches, como en Airbnb. Los fotógrafos, las marcas y los organizadores de eventos reservan franjas horarias. Ambos modelos deben compartir un calendario para evitar conflictos.
VillaSlot también debía gestionar depósitos y saldos, y enviar los pagos a las cuentas Stripe de las villas correspondientes. El producto reúne varias restricciones en un único flujo:
- reservas por noche;
- franjas horarias para sesiones y eventos;
- calendario compartido y control de disponibilidad;
- depósitos y saldos finales;
- pagos a cuentas Stripe externas.
VillaSlot sustituye los flujos de Timely y Airbnb que necesitaba. No sustituye el marketplace ni la captación de clientes de Airbnb.
Definir antes de programar
Empecé con una sesión de brainstorming con Codex para precisar el alcance y las decisiones de producto. Después preparé el PRD, 20 historias de usuario, sus criterios de aceptación y un grafo de dependencias.
El grafo era necesario porque algunas historias dependían de la autenticación y otras del calendario, los pagos o la gestión de villas. Ejecutarlas en un orden incorrecto habría provocado conflictos y trabajo repetido.
También preparé 20 maquetas. Cada agente tenía así un objetivo funcional y visual preciso.
| Elemento | Función durante el run |
|---|---|
| PRD | define el alcance y las reglas de negocio |
| Historias de usuario | divide el producto en resultados verificables |
| Criterios de aceptación | define cuándo termina cada historia |
| Grafo de dependencias | establece un orden de ejecución coherente |
| Maquetas | proporciona el objetivo visual |
Un run autónomo de 9 horas
Con la preparación terminada, lancé los agentes durante la noche. Trabajaron en las historias durante 9 horas y 20 minutos. El objetivo no era producir mucho código rápidamente, sino terminar cada historia con pruebas.
Cada historia seguía el mismo proceso:
- definir el comportamiento esperado;
- escribir las pruebas con un enfoque TDD;
- implementar la funcionalidad;
- ejecutar una revisión separada;
- lanzar las pruebas unitarias y de integración;
- probar el recorrido completo en Chrome;
- comprobar visualmente la interfaz;
- corregir automáticamente hasta la validación.
A la mañana siguiente, la primera versión funcional correspondiente al alcance definido estaba lista. No era una versión final. El uso real generó unas diez historias adicionales al día siguiente.
Por qué la QA es más importante con agentes
Cuanto más largo es el run autónomo, más fuerte debe ser la QA. Sin criterios precisos, pruebas y controles visuales, un error temprano puede afectar varias horas de trabajo posterior.
El papel del desarrollador cambia. Puede dedicar menos tiempo a escribir directamente cada funcionalidad, pero debe definir mejor los contratos, los casos alternativos y las pruebas que espera de cada agente. La autonomía depende del sistema de validación.
El coste de los tokens frente al tiempo humano
El proyecto procesó más de cuatro mil millones de tokens, y la mayor parte de ese volumen procedía de lecturas de caché. No debe confundirse con cuatro mil millones de tokens nuevos facturados a la tarifa estándar.
La comparación útil se centra en lo entregado: 20 historias, pruebas, revisiones, recorridos E2E y correcciones. El consumo parece excesivo si se observa de forma aislada. Se entiende mejor al compararlo con el tiempo humano necesario para desarrollar, probar y revisar el mismo alcance.
El método Killer SaaS busca ese equilibrio: suficiente preparación y QA para convertir largas sesiones de agentes en un producto funcional, no en una acumulación de código frágil.
Descubre VillaSlot y mira la demostración completa del flujo.
Cada semana comparto experiencias prácticas sobre agentes de IA y desarrollo en The Agentic Dev.