Por qué tu IA no debería decidir tu infraestructura (y qué hacer en su lugar)

Es fácil dejarse llevar por la idea de que la IA puede encargarse de todo el código. En la lógica de negocio funciona bastante bien: genera controladores, consultas y funciones sin problema. Pero hay un área donde las cosas se complican.

Cuando le pides que genere infraestructura, los resultados dejan de ser fiables.

El problema del contexto

Los modelos actuales dominan la sintaxis. Pueden crear archivos de Terraform o CloudFormation sin errores de formato. El verdadero problema aparece cuando hay que tomar decisiones que dependen del contexto real del proyecto.

Supongamos que quieres añadir un nuevo evento a tu sistema de mensajería. La IA creará un topic de SNS, una cola de SQS con su dead-letter queue y las políticas de IAM necesarias. Todo parece correcto hasta que te das cuenta de que ha elegido valores arbitrarios: tiempos de espera, periodos de retención y permisos que no tienen por qué ajustarse a tu carga de trabajo ni a la forma en que opera tu equipo.

La carga de revisar código generado

Lo peor no es que la IA se equivoque. Lo peor es que ahora el proceso de revisión se vuelve más pesado. En lugar de revisar lógica de aplicación, el revisor tiene que validar configuraciones de IAM, comprobar que los recursos encajan con la arquitectura existente y recordar decisiones que nunca quedaron documentadas.

Cuando algo falla en producción, el aviso llega a quien esté de guardia, no al pipeline de CI.

Decisiones separadas

El fondo del problema no es de herramientas. Aunque añadas validadores y módulos personalizados, el AI sigue tomando decisiones de infraestructura sin ver el código que las va a utilizar.

La aplicación y la infraestructura viven en repositorios distintos, con ciclos de revisión independientes. Esa separación impide que el contexto necesario llegue a quien tiene que tomar las decisiones.

Una alternativa más limpia

¿Qué pasaría si la infraestructura dejara de ser un problema aparte?

En lugar de escribir código de aplicación que luego necesita recursos externos, declaras esos recursos directamente dentro del código tipado. El framework se encarga de crear los topics, las colas y los permisos basándose en lo que realmente usa tu aplicación.

Un topic de mensajería se define así:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

No hay archivo de Terraform adicional ni políticas que revisar manualmente. El framework calcula los valores necesarios a partir de los tipos declarados.

Tu pull request se reduce a un único cambio en TypeScript.

Por qué importa para el desarrollo asistido por IA

La lógica de aplicación se puede delegar con cierta seguridad porque está acotada y se puede probar. Las decisiones de infraestructura requieren información que vive fuera del archivo que se está editando.

La solución no está en mejorar los prompts. Está en eliminar la frontera entre aplicación e infraestructura. Cuando el framework genera los recursos a partir del código de la aplicación, las decisiones críticas dejan de depender de conjeturas de la IA o de revisiones nocturnas.

Eso sí permite delegar con más tranquilidad.