Hay una lectura del desarrollo con IA que se ha vuelto consenso, y es fatalista: la IA no sabe de arquitectura, no «siente» el software, no toma decisiones a largo plazo. Y ahí se queda, como si fuera un límite intrínseco del modelo, algo que el tiempo y los parámetros acabarán resolviendo. O no.
Esa lectura confunde el síntoma con la causa.
El modelo optimiza el siguiente paso porque es lo único que le pasamos
Un modelo optimiza el siguiente paso porque el siguiente paso es lo único que le damos. La arquitectura es exactamente lo contrario: decidir hoy en función de restricciones que aún no existen, del coste de mantener algo durante años, de la coherencia conceptual de un sistema que todavía no está escrito del todo. Es razonamiento sobre el futuro. Y el futuro casi nunca viaja dentro del contexto que le damos a la máquina.
Cada sesión empieza en blanco. Las decisiones que tomaste ayer, por qué esta capa existe, qué invariante protege este módulo, qué se intentó y se descartó, viven en tu cabeza, no en el material que el modelo ve cuando vuelve a tocar el código. Le pedimos un paso local, sin el plano del edificio, y nos sorprende que el resultado sea localmente correcto.
Es que es literalmente lo que pedimos.
La incoherencia no está dentro del modelo
La incoherencia global no emerge de que el modelo sea tonto. Emerge de que nadie está gestionando lo que el modelo ve cada vez que decide. El problema no está dentro del modelo. Está en la capa que falta entre nuestras intenciones y su contexto.
La coherencia nunca ha sido una propiedad de la inteligencia. Piénsalo. Seguro que conoces personas brillantes y poco coherentes: el genio que no termina nada, el founder brillante que pivota cada lunes. Localmente correcto, globalmente incoherente.
Es una propiedad del proceso. No consigues un sistema coherente esperando que el modelo sienta la arquitectura. Lo consigues haciendo que la decisión arquitectónica, la especificación y la definición de qué significa correcto viajen con cada cambio, y verificando cada paso contra eso. La coherencia se impone, no se invoca.
El incentivo de la industria apunta a más, no a mejor
Conviene nombrar el sesgo. La IA en la nube monetiza volumen, no elegancia. Nadie factura por borrar 20.000 líneas innecesarias, eso sigue siendo un oficio casi artesanal, pero hay toda una industria facturando por generarlas. El incentivo entero apunta a más generación, más iteración, más tokens, más consumo. El vibe coding no es popular porque funcione mejor, es popular porque está perfectamente alineado con quién cobra.
Conviene no olvidarlo cuando alguien te vende que la arquitectura ya la pone la máquina.
Junior contra senior es un multiplicador de herramienta, no de persona
El junior produce más ruido cuando las restricciones no viven en el sistema, cuando nada le obliga a respetar las decisiones que ya se tomaron. El senior produce más valor porque lleva esas restricciones en la cabeza y las aplica sin pensar. Pero esa diferencia es justo lo que se puede externalizar en parte: cuando pones la arquitectura como un artefacto de primera clase, y te aseguro que se puede, de repente el junior, o el agente, también produce coherencia.
No por talento. Por andamiaje.
Hay una parte, eso sí, que no se externaliza: el software se siente. Quien ha hecho motores o gameplay durante años sabe que hay decisiones que no salen de la lógica verbal de un prompt, sino de la intuición acumulada tras miles de horas viendo sistemas fallar. La intuición es experiencia comprimida. Una parte de esa compresión se puede convertir en reglas explícitas, en restricciones, en criterios. Otra parte no, y por eso el humano sigue en el centro del bucle.
Negarlo es el error del vendehumos. Pero rendirse y decir que como no se puede capturar todo entonces no se puede capturar nada, es el error contrario, y es igual de equivocado.
Lo que de verdad preocupa
Lo que preocupa no es que la IA escriba código. Es que cada vez menos gente aprende a entender sistemas complejos. Cuando estos proyectos (funciones que existen y nadie sabe por qué, abstracciones que nadie se atreve a tocar) necesiten mantenimiento serio, hará falta gente capaz de leer código, detectar coherencia, simplificar y decidir. Y esos perfiles se forman cada vez menos, porque todo el mundo está aprendiendo a hacer prompts en lugar de a entender sistemas.
La respuesta no es prohibir la IA. Tampoco es rezar para que aparezca alguien capaz de leerse las 100.000 líneas. Es hacer el sistema legible por diseño: que cada decisión deje evidencia, que cada criterio sea verificable, que entender deje de depender de una rara avis y pase a estar forzado por el propio proceso de construir.
La capa que falta
Llevo más de un año construyendo justo esa capa: PaellaDoc. Obligar a que el plano viaje con cada cambio, y que nada llegue a «hecho» sin demostrarlo contra los criterios que se fijaron antes de escribir una línea.
No es una afirmación de fe. Cuando lo mides, un build en verde no es una feature correcta: hasta el mejor modelo, en crudo, cuela un fallo real una de cada tres veces en lo no trivial, y de forma no-determinista. La spec por delante y el gate de ejecución lo cierran. Y un nivel por encima, hacer producto es instalar un comportamiento, no acumular superficie: la misma idea, que la coherencia se impone, aplicada a qué construir en vez de a cómo construirlo.
El humano sigue en el centro. Lo que cambia es que deja de sostener la coherencia con la memoria y empieza a imponerla con el proceso.