Nos encontramos en un punto de inflexión en el desarrollo de software. El debate suele centrarse en cuál si la IA escribe el mejor código (Claude frente a ChatGPT) o dónde en dónde debe residir la IA (IDE o CLI). Pero esa no es la pregunta adecuada.
Si adoptamos la IA como «Vibe Coders» —nosotros indicamos la intención y la IA se encarga de la ejecución—, generaremos un flujo enorme de software nuevo. Un enjambre de agentes de IA puede generar en un minuto más código del que un desarrollador sénior puede revisar en una semana. El ser humano se ha convertido en el cuello de botella.
La solución no consiste en más personas. La solución es una Autoridad de Diseño de IA.
Tradicionalmente, la «Autoridad de Diseño» es un pequeño grupo de arquitectos que se reúne una vez por semana o al mes para aprobar o rechazar un diseño. En un mundo de desarrollo de IA de alta velocidad ese modelo está completamente obsoleto. Es demasiado lento y reactivo.
Si adoptamos el «código desechable» —software que no refactorizamos indefinidamente, sino que desechamos y volvemos a generar cuando cambian los requisitos—, nuestro papel cambia radicalmente. Ya no somos albañiles que colocan las piedras una a una. Somos los arquitectos de la fábrica que imprime las paredes.
Pero ¿quién controla que esas paredes estén rectas?
Una Autoridad de Diseño de IA no es una persona, sino una cadena de procesos. Un «campo de pruebas» por el que debe abrirse paso cada línea de código generada para llegar a producción. Este proceso no sustituye la revisión humana del código por nada, sino por algo mejor.
Funciona en tres capas:
1. El poder ejecutivo (la generación)
No pedimos a una sola IA que encuentre una solución; se lo pedimos a tres. Hacemos que Gemini 3, GPT-5 y un modelo de código abierto (como Llama) trabajen en paralelo sobre el mismo problema. Esto evita la visión de túnel y rompe con la «pereza» que a veces afecta a los LLM. Este enfoque también está investigado científicamente y demuestra que se pueden evitar las alucinaciones de la IA y construir cadenas muy largas sin errores
2. El filtro estricto (la ley)
Aquí no hay lugar para el debate. El código debe compilar. Los linters no deben generar errores. Y, lo que es crucial, las Pruebas de caja negra deben superarse. No comprobamos si la función funciona internamente (la IA podría manipularlo), sino si el sistema hace externamente lo que debe hacer. ¿Falla la prueba? Directamente a la papelera.
3. El filtro sutil (el jurado de IA)
Esta es la verdadera innovación. Las soluciones restantes se presentan a una «IA de votación» especializada. Este agente no escribe código, sino que lee revisa el código. Está entrenado según nuestros principios de arquitectura, requisitos de seguridad (OWASP, ISO) y normas de cumplimiento (Ley de IA de la UE).
Él vota: «La solución A es más rápida, pero la solución B es más segura y se ajusta mejor a nuestra arquitectura de microservicios».
El ganador pasa a producción.
Este modelo impone una separación de poderes que falta en muchos equipos.
project-description.md, rules.md, skills.md en principles.md) y los requisitos estrictos. El arquitecto determina qué qué construimos, quién lo construye, cómo y por qué.Nos libera de la tiranía de los errores de sintaxis y nos permite centrarnos en aquello que se nos da bien: pensar en sistemas. Buscar la verdad. La estructura y la toma de decisiones.
La cuestión no es si la IA puede escribir nuestro código. Ese tema ya está zanjado. El código se está convirtiendo, en gran medida, en un producto desechable.
La pregunta es: ¿Te atreves a soltar el control del código para recuperar así el control de la calidad ?
házmelo saber