Hay dos consejos sobre tests y arquitectura en proyectos construidos con IA, y los dos están equivocados. Uno dice escribe los tests primero, diseña la arquitectura por adelantado, hazlo bien desde el día uno. El otro dice sáltate todo eso, publica por sensaciones, ya añadirás lo aburrido después. Seguir el primero mata la velocidad que hizo que la IA mereciera la pena. Seguir el segundo garantiza el colapso del que todo el mundo avisa.
La respuesta correcta es un momento, no una política. Y lo útil es que el momento se anuncia solo, si sabes qué señal vigilar. Es la misma señal para los tests y para la arquitectura, y por eso los trato juntos.
Por qué el día uno está mal
Escribir tests y diseñar arquitectura antes de saber si la idea funciona es gastar tu esfuerzo más caro en tu apuesta menos segura.
Casi todo lo que construyes en los primeros días de un proyecto con IA no sobrevivirá la semana. Estás explorando. El sentido entero de construir con un agente es que explorar se abarató, así que puedes probar cinco versiones de una idea y tirar cuatro. Tests escritos contra código que estás a punto de borrar son puro desperdicio. Arquitectura diseñada para un producto que no has validado es una catedral construida para una congregación que quizá no aparezca.
Hay un coste real en la estructura prematura más allá de las horas perdidas: te vuelve reacio a tirar el código. Una vez que has invertido en probar y estructurar algo, lo defiendes, incluso cuando lo correcto es borrarlo. El rigor prematuro convierte la exploración en coste hundido. En la fase en la que deberías estar más dispuesto a descartar, te vuelve el que menos.
Así que el día uno está mal no porque los tests sean malos, sino porque todavía no sabes qué merece tenerlos.
Por qué el nunca está mal
El otro fallo es más común y más caro, porque no duele hasta que es demasiado tarde para ser barato.
Un proyecto con IA sin tests y sin arquitectura funciona bien justo hasta el punto en que necesitas cambiarlo sin romperlo. Entonces la ausencia de ambos pasa a ser lo que te frena. Cada cambio es una apuesta, porque nada atrapa una regresión y nada acota el radio de la explosión. Ese es el miedo a tocar tu propio código, y no es irracional. Es la respuesta correcta a un código sin red de seguridad.
El “nunca” además compone. Cada feature que un agente añade sobre una base sin estructura y sin tests hace la siguiente más arriesgada, porque la base sobre la que construye es menos fiable. Lo que empieza como velocidad se convierte en parálisis, y la parálisis llega justo cuando el proyecto está teniendo éxito y más necesitas moverte. Ese es el mecanismo detrás de las apps hechas con vibe coding que se rompen hacia el tercer mes: no un fallo súbito, sino el coste acumulado del “nunca” llegando a su vencimiento.
La señal: sostener peso
Aquí está el momento. Un camino merece tests y estructura cuando pasa a sostener peso, que es algo concreto y observable: cuando romperlo dolería a un usuario real, y cuando vas a seguir cambiándolo.
Las dos condiciones importan. Un camino que dolería a un usuario pero que nunca cambia no necesita tests con urgencia, porque los tests protegen frente al cambio y no hay ninguno. Un camino que cambia constantemente pero que no hace daño a nadie si se rompe puede seguir cutre. La intersección, mucho en juego y mucho cambio, es donde inviertes, y suele ser una fracción pequeña del código.
Esto te da una regla que de verdad puedes aplicar. No preguntes “¿debería este proyecto tener tests?”. Pregunta, para cada camino, “¿le dolería a un usuario si esto se rompiera, y voy a volver a tocarlo?”. Cuando las dos respuestas son sí, ese camino acaba de pasar a sostener peso, y esa es tu señal. No la edad del proyecto. No un objetivo de cobertura. El estado del camino concreto que tienes delante.
Primero los tests, luego la arquitectura
Cuando la señal se dispara, haz las dos cosas en orden, porque una habilita la otra.
Añade primero los tests, y añádelos como tests de caracterización: tests que fijan lo que el código hace ahora mismo, antes de cambiarlo. En un proyecto construido con IA rara vez tienes una spec limpia contra la que probar, así que pruebas el comportamiento que existe y funciona. Lo que en realidad pruebas cambia cuando el código lo escribió una máquina, y eso es una disciplina propia: probar código generado por IA va de cazar los modos de fallo que un autor humano no habría producido. Los tests de caracterización son específicamente la herramienta para fijar un comportamiento que no diseñaste, de modo que puedas cambiarlo con seguridad. Y solo cuentan si de verdad los corres. Un agente que informa de verde sin ejecutar la suite no te ha dado nada, que es toda la razón de que hecho tenga que significar hecho.
Después, y solo después, refactoriza la arquitectura, usando los tests como red. Ahora puedes reestructurar el camino que sostiene peso, porque los tests te avisarán en el momento en que cambies su comportamiento. Refactorizar sin esa red es cómo introduces la regresión exacta que intentabas evitar. Los tests son lo que hace que el trabajo de arquitectura sea seguro en vez de aterrador.
Fíjate en la secuencia. Los tests no van primero porque sean más importantes. Van primero porque hacen sobrevivible el cambio de arquitectura. Invierte el orden y estás reestructurando a ciegas.
Esto es pagar la deuda en el orden correcto
Si has leído cómo pienso sobre la deuda del vibe coding, esto es la misma idea desde el otro lado. La deuda de verificación y la de arquitectura vencen las dos cuando un camino pasa a sostener peso. “Cuándo añadir tests y arquitectura” es solo “cuándo vence esa deuda”, y la respuesta es: cuando el camino puede hacer daño a alguien y vas a seguir tocándolo.
Ese marco también te protege de la trampa del build verde. Un camino que sostiene peso con tests que pasan pero no demuestran nada no está protegido, solo se siente protegido, que es peor. Los tests tienen que ejercitar de verdad el comportamiento que importa, o has pagado el coste de probar sin comprar la seguridad. Esa es la diferencia entre una red real y un build verde que no es una feature correcta.
Y toda esta disciplina es lo que separa publicar una demo de publicar algo que puedes operar. Saber cuándo añadir rigor, y dónde, es la mayor parte del trabajo real de llegar del vibe coding a producción sin ahogarte en proceso prematuro ni colapsar sin ninguno.
Dónde encaja PaellaDoc
La parte difícil de esta regla no es estar de acuerdo con ella. Es saber, en cualquier momento dado, qué caminos de tu proyecto sostienen peso y si están de verdad cubiertos. Ese conocimiento vive en tu cabeza, y se queda obsoleto rápido cuando un agente cambia el código más rápido de lo que puedes seguir.
PaellaDoc mantiene ese mapa al día: qué partes del producto sostienen peso, qué contrato debe cumplir cada una y qué evidencia hay de que lo cumple. Así, cuando un camino cruza a sostener peso, lo ves, en vez de enterarte cuando se rompe. La señal deja de depender de tu memoria y pasa a vivir en el sistema, que es la única versión de esta regla que sobrevive al contacto con la velocidad real.
Preguntas frecuentes
¿Debería escribir tests antes de empezar un proyecto con IA? Normalmente no. El código temprano es exploratorio y en su mayoría desechable, y probar código que estás a punto de borrar es esfuerzo malgastado que además te vuelve reacio a borrarlo. Espera a que un camino pase a sostener peso.
¿Qué significa “sostener peso” exactamente? Un camino sostiene peso cuando romperlo dolería a un usuario real y vas a seguir cambiándolo. Las dos condiciones tienen que darse. Mucho en juego sin cambio, o mucho cambio sin nada en juego, no necesitan la inversión con urgencia.
¿Van primero los tests o la arquitectura? Primero los tests, como tests de caracterización que fijan el comportamiento actual, y luego la arquitectura usando esos tests como red. Refactorizar sin tests reintroduce las regresiones que intentabas evitar.