Qué tienen en común los cuatro
- La especificación vino primero, y fue corta. Un párrafo, no un documento. Pero nombró las restricciones que importaban: idiomas, "solo ve sus propios datos", "aun así envía lo que tengas", "publicar al hacer push de un archivo", incluyendo las restricciones de flujo de trabajo que nunca aparecen en la aplicación en funcionamiento.
- Los secretos nunca tocaron el repositorio. Cada proyecto leyó las claves desde variables de entorno o secretos cifrados, configurados en un panel, no en el código. Dijimos "never hardcode it" en voz alta, porque el comportamiento por defecto es el contrario.
- La pila se eligió para que hubiera menos margen de error. Autenticación gestionada, gestionada, alojamiento estático, funciones sin servidor: cada elección eliminó una categoría de código que la IA podía romper en nuestro nombre, y una categoría de cosa que tendríamos que mantener.
- Los obstáculos se resolvieron alimentando a la IA con evidencia exacta —el error literal, el código real, la configuración de despliegue, el síntoma verdadero— y acotando las correcciones de forma estrecha para que el código que funcionaba siguiera funcionando. Dos veces el síntoma estuvo en el código, pero la causa estuvo en la infraestructura.
- El lanzamiento significó una prueba real contra la realidad: una compra en vivo (y una rechazada), una segunda cuenta de usuario, un disparador a demanda, un enlace profundo en el sitio desplegado. No "compiló".
No necesitas una gran idea para empezar. Necesitas una pequeña, una especificación de un párrafo, y la disposición a dirigir en lugar de escribir, además de la paciencia para poner a prueba lo construido contra la realidad antes de darlo por terminado.