Construimos salty.poker con IA. Aquí está la Parte que Nadie Vio.

Veintidós sesiones de construcción en diez días.

Cada sesión: un agente de Claude Code trabajando desde una especificación de 100 páginas — leyendo el estado actual del código, tomando el módulo de especificación asignado, escribiendo código, conectando servicios, ejecutando migraciones, haciendo commits. Sin reuniones de estimación. Sin conversaciones de alcance. Sin tickets de Jira debatidos en una sala de conferencias.

El resultado de esas sesiones fueron 20 microservicios, un motor de mesa en tiempo real, gestión de torneos, un libro mayor de doble entrada, verificación KYC, detección de fraude y una mesa de póker renderizada en PixiJS con tarjetas animadas y pilas de fichas.

El changelog cubre lo que se entregó. Este post trata de lo que sucedió después.

Lo que Realmente Sucede Después de que Se Escribe el Código

Escribir código correcto y tener un sistema que funciona son dos cosas diferentes. El código pasa sus pruebas unitarias. Los servicios se comportan correctamente en aislamiento. Pero cuando conectas todo — la aplicación web, el motor de mesa, las conexiones en tiempo real, la autenticación, la base de datos — la superficie de fallo crece más rápido de lo que cualquier suite de pruebas puede anticipar.

Esta semana pasada fue esa fase. Pruebas de extremo a extremo. Inicios de sesión reales, lobby real, mesas reales, jugadores reales sentándose.

La vista de la mesa se cargó y mostró un lienzo vacío donde deberían estar los asientos. Sin diálogo de compra. Sin forma de volver al lobby. Una pantalla en blanco donde debía estar un juego de póker.

El lobby tenía una tarjeta de mesa que se extendía para llenar toda la altura de la página. Un valor predeterminado de CSS — eso es simplemente cómo se comporta CSS Grid cuando solo hay un elemento en la fila y no has anulado su comportamiento de estiramiento.

Ninguno de estos errores fue escrito por un humano. Una sesión de IA escribió la vista de la mesa. Una sesión de IA escribió el lobby. Seguían siendo errores. Seguían necesitando ser encontrados, rastreados hasta su causa raíz y corregidos.

Por Qué Este Sigue Siendo el Mejor Camino

Antes de la historia de cómo-se-rompió: el hecho de que estemos en pruebas de extremo a extremo en diez días es la historia.

Dos empresas anteriores me enseñaron cuánto tiempo lleva esto de la manera tradicional. Meses de andamiaje antes de tener algo que probar. Meses más antes de que estés probando algo que se parece al producto final.

Cerramos esa brecha en diez días. La fase de pruebas es la parte difícil. Estamos en ella.

Lo que Viene en Esta Serie

Este es el post uno de cuatro. A lo largo de la próxima semana, recorreremos lo que realmente encontramos durante las pruebas — un bug de enrutamiento que era invisible hasta que el stack completo corrió, un entorno de desarrollo que ignoraba silenciosamente los cambios de código, y una guard de autenticación que enviaba cada intento de navegación a un bucle de redirección.

Para la metodología más profunda, escribo sobre ello en The Salty Korean.

Stay salty.