Terraform con IA: AWS con Cursor y MCP Server

Q: ¿Cómo usar Cursor para generar Terraform?

Configurás el MCP Server de HashiCorp en el archivo mcp.json de Cursor, definís un Cursor Rules con las convenciones de tu proyecto (nomenclatura, versiones de providers, estructura modular), y usás Agent Mode para generar módulos en pasos separados. El flujo correcto va de la red base (VPC) hacia los servicios de compute y distribución, un módulo por prompt.

Terraform con IA dejó de ser experimental en 2026: usando Cursor en Agent Mode con el MCP Server oficial de HashiCorp, podés generar infraestructura AWS completa con contexto real del Terraform Registry. El resultado es código que pasa terraform apply en vez de romperse a mitad de camino.

En 30 segundos

El MCP Server de HashiCorp conecta la IA con el Terraform Registry real, eliminando alucinaciones por documentación desactualizada
Cursor en Agent Mode genera múltiples archivos coordinados (VPC, Security Groups, Load Balancer) dentro de una sola sesión
El flujo correcto exige dividir la infraestructura en módulos separados, nunca pedir todo de una sola vez
Sin terraform plan antes del apply, el código generado puede destruir recursos existentes sin aviso
HashiCorp actualizó el MCP Server en mayo 2026 con soporte para Stacks y herramientas adicionales de búsqueda

Cursor es un editor de código basado en VS Code que integra modelos de lenguaje para asistencia en programación, desarrollado por Anysphere. Incluye herramientas como autocompletado, generación de código y depuración asistida por IA.

Por qué Terraform con IA importa en DevOps moderno

El Model Context Protocol (MCP) es un estándar abierto que permite a los editores de código conectarse con fuentes de datos externas estructuradas para proveer contexto real a los modelos de lenguaje durante la generación de código.

Ponele que tenés que levantar un entorno AWS desde cero: VPC con subredes públicas y privadas, security groups, un Auto Scaling Group, un Load Balancer, y CloudFront arriba de todo. En un proyecto chico, el Terraform lo escribís a mano en un par de horas. En producción, con múltiples módulos y dependencias cruzadas, el tiempo se va en otra parte: revisar docs del Registry, cazar casos especiales de AWS, reejecutar terraform apply tres veces hasta que funciona.

Muchos equipos llevan meses experimentando con Terraform con IA para acortar ese ciclo. El problema es que funciona a medias si el modelo no tiene contexto real de tu infraestructura y de las versiones actuales de los providers.

Las limitaciones críticas de generar Terraform sin contexto

La primera reacción de cualquiera es mandarle al chat: “Generame Terraform para una VPC con subredes públicas y privadas.” Y sí, te devuelve algo. El tema es que ese algo generalmente tiene cuatro problemas concretos, documentados en la práctica por equipos que lo intentaron antes:

Argumentos obsoletos: el modelo usa sintaxis de providers viejos que el registry ya no acepta
Ignora la estructura modular: genera un bloque monolítico cuando tu proyecto usa módulos separados por servicio
Dependencias incompletas: referencia recursos que no crea, o crea recursos en orden incorrecto
Falla en apply: el código pasa el terraform validate y revienta en terraform plan o directamente en el apply

¿Por qué pasa esto? Porque el modelo no sabe qué versión del provider AWS estás usando, no lee tu versions.tf, y trabaja con lo que tenía en su conjunto de datos de entrenamiento, que puede tener meses o años.

A fines de 2024, un equipo que documentó este problema intentó resolverlo con RAG (Retrieval-Augmented Generation): construyeron una herramienta interna que indexaba la documentación del Terraform Registry y se la pasaba al modelo como contexto. Safó por poco, pero tenía el problema de que la indexación se desactualizaba y el mantenimiento era una carga más. La solución real llegó después con MCP. Lo explicamos a fondo en herramientas de CI/CD para automatizar despliegues.

¿Qué es MCP Server y por qué lo necesita Terraform?

El MCP Server de Terraform es un servidor oficial de HashiCorp que expone el Terraform Registry como una fuente de contexto estructurado para editores compatibles. Cuando Cursor lo tiene configurado, el modelo recibe información actualizada del registry en tiempo real antes de generar código.

Según el anuncio de HashiCorp de mayo 2026, el servidor tiene cuatro capacidades principales:

Provider Docs: documentación actualizada de providers (AWS, GCP, Azure) con argumentos válidos para la versión que especificás
Module Discovery: búsqueda de módulos verificados en el Registry por funcionalidad
Module Details: inputs, outputs y ejemplos de módulos específicos
Policy Search: búsqueda de políticas Sentinel para Terraform Cloud

La actualización de mayo 2026 agregó soporte para Terraform Stacks, que es el sistema de orquestación para despliegues multi-ambiente. El código del servidor está disponible en GitHub bajo la organización HashiCorp.

El resultado práctico: el modelo ya no adivina qué argumentos acepta aws_lb. Los lee del registry actualizado antes de escribir una línea.

Cursor como editor principal para Terraform con IA

Cursor tiene tres características que lo hacen mejor opción que VS Code con GitHub Copilot para este caso de uso específico:

Agent Mode permite que el modelo cree y modifique múltiples archivos en una sola sesión sin que vos tengas que copiar y pegar entre prompts. Cuando generás una VPC, el agente puede crear vpc.tf, actualizar main.tf, y agregar las variables correspondientes en variables.tf de manera coordinada.

Entendimiento de dependencias entre módulos: cuando ya tenés una VPC definida y pedís un Security Group, Cursor lee los IDs de la VPC del contexto existente en vez de inventarlos.

Cursor Rules: podés definir un archivo de reglas del proyecto que incluya convenciones de denominación, versiones de providers, y estructura modular. Cualquier generación posterior respeta esas reglas automáticamente. (Esto equivale a tener un tech lead que le explica el estilo del proyecto al modelo antes de cada tarea.) En optimizar contenido en múltiples idiomas profundizamos sobre esto.

Flujo de trabajo práctico: generar infraestructura AWS paso a paso

La regla más importante: dividí en pasos. Si le pedís “generame toda la infraestructura de producción en un prompt”, lo que obtenés es código que parece completo pero tiene dependencias rotas entre módulos. El flujo que funciona va así:

Paso 1 – Red base: VPC + subredes públicas y privadas + Internet Gateway. Prompt: “Creá un módulo Terraform para VPC en us-east-1 con 2 subredes públicas y 2 privadas en AZs distintas, usando el provider AWS versión 5.x”
Paso 2 – Security Groups: una vez que tenés el VPC ID, pedís los grupos para cada capa (web, app, data) referenciando la VPC existente
Paso 3 – Compute: Auto Scaling Group con Launch Template, referenciando los subnets y security groups del contexto
Paso 4 – Jumpbox: instancia bastion en subred pública con acceso SSH restringido
Paso 5 – Load Balancer: ALB en subredes públicas apuntando al ASG
Paso 6 – CDN y DNS: CloudFront delante del ALB, registros Route 53

¿Y qué pasa si mandás todo en un solo prompt? El modelo genera algo, claro. Pero las referencias entre módulos quedan hardcodeadas con valores de ejemplo o directamente rotas. Después perdés más tiempo debugueando que si lo hubieras dividido desde el principio.

Cada paso termina con un terraform plan y revisión manual antes de seguir. No hay apuro que justifique saltear eso.

Errores comunes y cómo evitarlos

Apply directo sin plan

El error más común, especialmente cuando el código “se ve bien”. Corrés terraform apply sin terraform plan previo y destruís un recurso existente porque el estado local no matchea el estado remoto. Siempre terraform plan -out=plan.tfplan antes. Siempre.

Permisos inseguros por default

Los modelos de lenguaje tienden a generar security groups con cidr_blocks = ["0.0.0.0/0"] porque es lo más simple y suele aparecer en ejemplos de documentación. Pasás ese código a producción y tenés puertos abiertos al mundo. Revisá manualmente cada ingress y egress antes de aplicar.

No versionar en Git

Generar Terraform con IA y aplicarlo sin commitearlo antes es trabajar sin red. Si algo sale mal, no tenés forma de revertir. Cada cambio generado va a un branch, pasa por pull request, y recién ahí va a producción. Este punto parece obvio, pero equipos que adoptan IA acelerada lo saltean. Esto se conecta con lo que analizamos en ejecutar agentes de IA sin APIs externas.

No entender el código antes de aplicarlo

Esto es más sutil. El modelo genera algo que funciona, lo aplicás, y tres meses después nadie del equipo entiende qué hace ese módulo ni por qué tiene esa estructura. La IA te ahorra tiempo de escritura, no tiempo de comprensión. Si no podés explicar qué hace cada bloque, no lo aplicás todavía.

Ignorar el versionado de providers

Sin un versions.tf con constraints explícitos, un terraform init nuevo puede traer el provider 6.x cuando el código fue generado para 5.x. El Cursor Rule de tu proyecto debería incluir la versión del provider AWS y el bloque required_providers como template base.

Mejores prácticas y consideraciones de seguridad

Si usás el stack Terraform + Cursor + MCP en un entorno de trabajo real (no un side project), hay tres puntos que no son opcionales:

Primero, las políticas IAM generadas por AI necesitan revisión humana siempre. El modelo tiende a usar políticas de acceso amplio porque resultan en código que “funciona” en todos los casos. Lo que necesitás en producción es least privilege. Revisá cada aws_iam_policy_document antes de aplicar.

Segundo, si tu empresa usa infraestructura en cloud, donweb.com ofrece servicios de hosting y servidores cloud en Argentina donde podés alojar los backends de estado de Terraform (S3 equivalente + DynamoDB para locking) sin depender de proveedores externos.

Tercero, el control humano en producción no es negociable. La IA genera el código, el humano decide cuándo y cómo se aplica. Un pipeline de CI/CD que aplica automáticamente código generado por IA sin aprobación manual es un riesgo que no tiene justificación de velocidad.

Confirmado / Pendiente

Funcionalidad	Estado (mayo 2026)
MCP Server con Provider Docs	Confirmado, disponible en GitHub
Module Discovery y Module Details	Confirmado, en producción
Soporte para Terraform Stacks via MCP	Confirmado, agregado en actualización de mayo 2026
Integración nativa Cursor + Terraform MCP	Confirmado via configuración manual en mcp.json
Policy Search (Sentinel)	Confirmado para Terraform Cloud Enterprise
Soporte para Terraform CDK via MCP	Sin confirmar, no anunciado por HashiCorp

Preguntas Frecuentes

¿Cómo funciona Terraform con inteligencia artificial?

Terraform con IA combina un editor como Cursor con el MCP Server de HashiCorp para generar código HCL con contexto real del Terraform Registry. El modelo recibe la documentación actualizada del provider que estás usando antes de escribir cada bloque, lo que reduce los errores de argumentos obsoletos o dependencias rotas que aparecen cuando usás el AI sin ese contexto. Tema relacionado: consideraciones de seguridad en tus plataformas.

¿Qué es MCP y por qué Terraform lo necesita?

MCP (Model Context Protocol) es un estándar que conecta editores de código con fuentes de datos externas estructuradas. Terraform lo necesita porque los modelos de lenguaje generan código usando documentación del training data, que puede estar desactualizada. Con el MCP Server de HashiCorp, el modelo consulta el Registry en tiempo real y usa los argumentos correctos para la versión del provider que especificás.

¿Cómo usar Cursor para generar Terraform?

Configurás el MCP Server de HashiCorp en el archivo mcp.json de Cursor, definís un Cursor Rules con las convenciones de tu proyecto (nomenclatura, versiones de providers, estructura modular), y usás Agent Mode para generar módulos en pasos separados. El flujo correcto va de la red base (VPC) hacia los servicios de compute y distribución, un módulo por prompt.

¿Es seguro generar infraestructura AWS con IA?

Con las precauciones correctas, sí. Los riesgos principales son permisos IAM demasiado amplios y security groups abiertos al mundo, que los modelos generan por defecto. El proceso seguro implica revisar manualmente cada política IAM y cada regla de security group, ejecutar terraform plan antes de cualquier apply, y pasar el código generado por pull request con revisión humana antes de llegar a producción.

¿Cuáles son los errores más comunes de Terraform generado por IA?

Los cinco más frecuentes: apply directo sin plan previo (destruye recursos existentes), security groups con 0.0.0.0/0 en puertos sensibles, ausencia de versionado de providers en versions.tf, no commitear el código antes de aplicarlo, y dependencias entre módulos hardcodeadas que se rompen cuando reorganizás el proyecto. Todos son evitables con un proceso de revisión antes del apply.

Conclusión

El stack Terraform + Cursor + MCP Server resuelve el problema concreto que tenía la generación de infraestructura con IA hasta ahora: el modelo alucinaba porque no tenía contexto real. Con el MCP Server de HashiCorp apuntando al Registry actualizado, ese problema desaparece en su mayor parte.

Lo que no cambia es que alguien tiene que entender el código antes de aplicarlo. La IA acorta el tiempo de escritura de Terraform de manera significativa, especialmente en módulos repetitivos como VPCs y security groups. Pero el terraform plan, la revisión de políticas IAM, y el control sobre qué va a producción y cuándo siguen siendo responsabilidad humana. No porque la herramienta sea mala, sino porque ese control es parte del trabajo.

Si tu equipo maneja infraestructura AWS y todavía escribe Terraform completamente a mano, vale la pena probar el setup. La curva de configuración inicial (MCP + Cursor Rules) es de un par de horas, y el tiempo que recuperás en módulos subsiguientes es real.