Hay una diferencia que pocos articulan al hablar de IA aplicada al desarrollo: no es lo mismo dejar que un asistente como Claude Code escriba una función de validación de emails que dejar que escriba la configuración Terraform que despliega tu producción.

La primera la revisas en tres minutos y, si está mal, lo peor que pasa es que falle un test. La segunda, si está mal, puede dejar tu base de datos pública en internet a las dos de la mañana y enterarte el lunes por un email de AWS.

Y sin embargo, la mayoría del entusiasmo de “vibe coding” con IA se centra en código de aplicación. La infraestructura como código (IaC) recibe menos atención y, en mi experiencia trabajando con equipos que usan Claude Code para Terraform, Pulumi o configuraciones AWS, es justo donde la IA cambia las reglas del juego más que en ningún otro sitio.

Este artículo es lo que hemos aprendido. No es una guía de “cómo usar IA para infraestructura”. Es una reflexión sobre qué cambia, qué no cambia y dónde están los límites reales.

Lo que la IA hace bien con infraestructura como código

Los archivos Terraform, los manifiestos Kubernetes, las plantillas CloudFormation, las configuraciones Ansible — todos comparten una característica que los hace particularmente adecuados para asistencia con IA: son declarativos.

Tú no le explicas paso a paso qué tiene que hacer la máquina. Le declaras el estado final que quieres (“una base de datos PostgreSQL 16 en eu-west-1 con backup automático y replicación a eu-west-3”) y la herramienta se encarga de comparar contra el estado actual y aplicar los cambios necesarios.

Eso encaja perfectamente con cómo trabaja un asistente como Claude. La IA es buena describiendo estados deseados a partir de intención. Es mucho mejor traduciendo “quiero un balanceador con SSL automático y certificados gestionados” a un Terraform correcto que generando código procedural complejo de cero.

Tres cosas que en mi flujo van francamente bien con Claude Code aplicado a IaC:

Generar configuración inicial razonable. Le pasas el contexto de tu proyecto y le pides la primera versión de un VPC con subredes públicas y privadas, NAT gateway, security groups y todo lo demás. En tres minutos tienes ochocientas líneas de Terraform que en su mayor parte son correctas. Quitando los nombres y las decisiones específicas, esa es la parte que más tiempo robaba antes.

Refactorizar para usar mejores prácticas. “Convierte estas cinco recetas separadas en módulos reutilizables.” “Migra de count a for_each.” “Saca los valores hardcoded a variables.” Tareas mecánicas que un humano hace mal por aburrimiento, la IA las hace consistente.

Revisar configuraciones para encontrar problemas evidentes. Pedir a Claude “revisa este Terraform y dime qué está mal o qué falta” es sorprendentemente eficaz. Detecta security groups demasiado abiertos, falta de tags estándar, configuraciones de red incoherentes, y cosas que un revisor humano se saltaría.

Lo que la IA hace muy mal y por qué

La parte buena viene con un reverso peligroso. Hay tres tipos de errores que Claude Code comete con regularidad en infraestructura, y todos son del tipo “parece correcto hasta que despliegas en producción”.

Inventa atributos o recursos que no existen. Esto es el clásico “hallucination” pero con consecuencias caras. Te genera un Terraform que usa aws_lambda_function.runtime_version_2 cuando ese atributo no existe, y como nunca aplicaste antes ese módulo, no lo detectas hasta el terraform apply. Aquí no hay debate: cualquier configuración generada por IA tiene que pasar por terraform plan antes de ser revisada.

Mezcla versiones de proveedor. El sintaxis de AWS Provider 4.x no es exactamente la del 5.x. Pueden estar mezclando documentación de ambos. La versión que te genera puede no compilar en tu versión actual del proveedor.

No sabe qué tienes ya desplegado. Si tu base de código tiene convenciones específicas (un sufijo de tag obligatorio, un módulo personalizado para crear S3 buckets con encriptación, un naming determinado), la IA va a ignorar todo eso a menos que se lo digas explícitamente. Y va a generar código técnicamente correcto pero incoherente con tu ecosistema.

Estos tres problemas son la razón por la que dejarle escribir IaC sin contexto es peligroso. Con contexto, va bien. Sin contexto, te genera arquitectura que se ve bien y rompe en producción.

El cambio fundamental: la IA acelera, no decide

Lo que más he visto malinterpretarse cuando un equipo empieza a usar IA para infraestructura es la idea de que la herramienta puede tomar decisiones de arquitectura.

No puede.

Decidir si tu sistema necesita una base de datos relacional o NoSQL no es una decisión técnica aislada — depende del modelo de datos, los patrones de acceso, los requisitos de consistencia, el presupuesto y el equipo que va a mantenerlo. Esa decisión la toma un arquitecto humano.

Lo que la IA hace excelentemente bien es ejecutar esa decisión una vez tomada. “Vamos a usar Aurora PostgreSQL con dos réplicas” se traduce a Terraform correcto en segundos. Pero el “vamos a usar Aurora PostgreSQL” es trabajo del cerebro humano que entiende el negocio.

El resultado práctico es que el rol de la persona que hace infraestructura está cambiando. Menos tiempo escribiendo recetas y más tiempo decidiendo qué pedir, validando lo que la IA produce y manteniendo el contexto del sistema actualizado para que la IA pueda generar dentro de los límites correctos.

Las tres reglas que aplicamos para no romper nada

A base de errores, hemos llegado a tres reglas duras cuando trabajamos con Claude Code en infraestructura.

Regla 1: nada se aplica sin plan revisado por un humano. El plan de Terraform muestra exactamente qué va a cambiar. Cualquier diff sospechoso (recursos que se borran cuando no esperabas que se borraran, cambios en producción cuando creías estar tocando staging) es señal de parar y revisar. Esto no es desconfianza — es responsabilidad básica.

Regla 2: secrets nunca pasan por la conversación con la IA. Las claves API, contraseñas de bases de datos, certificados privados — eso no entra en el chat con Claude. Se gestiona con un sistema de secrets dedicado (AWS Secrets Manager, HashiCorp Vault, sealed secrets en Kubernetes) y el código IaC referencia los secrets por nombre, no por valor. Esto vale para humanos también, pero con IA la disciplina tiene que ser absoluta.

Regla 3: separar por entornos no es opcional. Tener desarrollo, staging y producción en estados de Terraform separados, con permisos distintos y revisión diferenciada, no es un lujo. Es la red de seguridad que evita que un comando mal aplicado tumbe la producción cuando estabas tocando otro entorno. Esta regla existía antes de la IA, pero con IA se vuelve crítica porque los errores son más rápidos.

Cuándo NO usar IA para infraestructura

Aunque la IA aplicada a IaC funciona bien en general, hay situaciones donde añade riesgo sin compensar.

Migraciones críticas que dependen de timing exacto. Si el coste de un fallo es interrumpir el servicio durante horas, la IA no debería tener el control directo. Debería sugerir, un humano ejecuta
Sistemas con cumplimiento normativo estricto. Sectores como sanitario, financiero o defensa tienen requisitos de auditoría donde cada cambio tiene que estar trazado y justificado por una persona identificable
Cuando la persona revisora no entiende la salida. Si quien revisa el Terraform generado por la IA no sabe leer Terraform en serio, no está revisando — está confiando ciegamente. Eso no es uso de IA, es delegación irresponsable

La práctica que de verdad cambia el rendimiento

Lo más útil que hemos incorporado al flujo no es prompting elaborado ni configuraciones de modelo específicas. Es algo más aburrido pero más efectivo: mantener un contexto del sistema escrito y actualizado que la IA lee antes de generar código.

Ese contexto incluye qué proveedores usamos, qué versiones, qué módulos compartidos están disponibles, qué convenciones de naming y tagging seguimos, qué está expresamente prohibido (recursos sin tags, security groups abiertos a 0.0.0.0/0 en producción), y qué decisiones de arquitectura ya están tomadas.

Cuando Claude Code lee ese contexto antes de generar, el resultado pasa de “código que parece correcto” a “código que encaja en nuestro ecosistema y se puede aplicar tal cual con cambios mínimos”. La diferencia es la noche y el día.

Si trabajas con Claude Code en infraestructura y estás pensando en cómo estructurar el flujo para que la IA acelere sin meter la pata, esto es exactamente el tipo de problema que resolvemos. Comparto el método paso a paso en una serie de vídeos en preparación — apúntate y te aviso cuando esté lista.