autoridad de diseño de IA

La autoridad de diseño de IA

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.

Del artesano al director de fábrica

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?

El «Gauntlet»: una prueba de fuego automatizada

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.

La separación de poderes del software

Este modelo impone una separación de poderes que falta en muchos equipos.

  • El poder legislativo (el arquitecto): El arquitecto redacta la «Constitución». Los prompts, los documentos de arquitectura (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é.
  • El poder ejecutivo (los agentes de programación): Ellos ejecutan. De forma rápida y económica, bajo la supervisión de desarrolladores humanos.
  • El poder judicial (la autoridad de diseño): Una capa de IA independiente que verifica el cumplimiento de la ley.

Conclusión: el nuevo papel del arquitecto

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

Gerard

Gerard trabaja como consultor y director de IA. Gracias a su amplia experiencia en grandes organizaciones, puede desentrañar un problema con especial rapidez y avanzar hacia una solución. Su formación en economía, combinada con esta experiencia, le permite tomar decisiones empresarialmente responsables.