CDK vs Terraform vs Pulumi vs SST: cuál gana con IA
En pocas palabras: Ganó AWS CDK. En una prueba publicada el 16 de julio de 2026, un desarrollador le pidió a GPT que armara la misma infraestructura serverless de seis formas: CDK se impuso porque genera el mejor loop de feedback para que la IA detecte y repare sus propios errores.
Un desarrollador que firma como sun_wukong121 le pidió a GPT que armara la misma infraestructura serverless en AWS usando seis formas distintas de definirla, y publicó el resultado en dev.to el 16 de julio de 2026. Ganó AWS CDK. Pero no por usar TypeScript o Python: ganó porque genera el mejor loop de feedback para que una IA detecte y repare sus propios errores. Esta es la parte interesante de cualquier CDK vs Terraform Pulumi comparación hoy: la pregunta ya no es cuál te gusta más a vos, sino cuál le da a un agente de IA la mejor chance de escribir infra correcta.
Infrastructure as Code (IaC) es la práctica de definir servidores, bases de datos y redes con archivos de código versionable en vez de configurarlos a mano en una consola. AWS CDK, Terraform, Pulumi y SST son cuatro frameworks para hacer esto sobre AWS: CDK y Pulumi usan lenguajes de programación reales (TypeScript, Python), Terraform usa su propio lenguaje declarativo HCL, y SST es un framework enfocado en apps serverless construido sobre CDK. Cada uno cambia qué tan fácil le resulta a un modelo de lenguaje validar lo que escribió.
En 30 segundos
- Ganó CDK en la prueba publicada el 16/07/2026, por su loop de feedback: convierte un error en un mensaje de compilador preciso que la IA arregla al toque.
- El test fue el mismo pedido para todos: una API serverless de acortador de URLs con API Gateway HTTP API, Lambda y DynamoDB.
- No es un benchmark estadístico. El propio autor lo aclara: es una prueba de escritorio, direccional y opinada. Los puntajes son heurísticas de ingeniería, no tasas de aprobación universales.
- “Amigable para humanos” no es “amigable para IA”. Un framework puede ser conciso pero difícil de validar para un agente.
- El resultado depende del contexto: versión del framework, docs provistas, schemas del provider, modelo elegido y calidad del loop de validación pueden cambiar todo.
¿Qué es Infrastructure as Code y para qué sirve en AWS?
Infrastructure as Code es definir tu infraestructura (Lambdas, tablas DynamoDB, API Gateways, buckets, permisos IAM) mediante código, para poder versionarla en git, revisarla en un pull request y desplegarla de forma repetible. En AWS lo usás para no tener que clickear cada recurso en la consola y para que dos ambientes sean idénticos.
Ponele que armás un backend a mano en la consola de AWS, funciona, y tres meses después necesitás replicarlo en otra cuenta. ¿Te acordás de cada checkbox que tildaste? Con IaC eso no pasa: corrés el mismo archivo y listo. Los cuatro frameworks de esta nota resuelven ese problema, con filosofías distintas. Para más detalles técnicos, mirá cómo se integran en pipelines de deployment.
- AWS CDK: escribís infra en TypeScript o Python y CDK la traduce a CloudFormation. Tenés autocompletado, tipos y clases reutilizables.
- Terraform: usa HCL, un lenguaje declarativo propio de HashiCorp, y es agnóstico de nube (sirve para AWS, Azure, otros).
- Pulumi: como CDK, usa lenguajes reales (TypeScript, Python, Go, C#), pero es multi-nube.
- SST: framework en TypeScript pensado para apps serverless full-stack, construido arriba de CDK, con foco en experiencia de desarrollo.
¿Por qué importa cómo un framework funciona con inteligencia artificial?
Importa porque un agente de IA no “sabe” si su infra está bien hasta que algo se lo dice. El framework que le devuelve el error más rápido y más preciso es el que le permite corregirse antes de romper nada en producción. Ese ciclo (escribir, validar, recibir error específico, reparar) es lo que el autor llama loop de feedback, y es donde CDK sacó ventaja.
Pensalo así. Un humano con experiencia lee un HCL verboso y entiende el contexto. Un modelo trabaja distinto: propone algo, lo tira contra el validador y ajusta según la respuesta. Si el framework le devuelve “propiedad inválida en la línea 42, esperaba string” en tiempo de compilación, la IA arregla eso al instante. Si en cambio el error recién aparece a mitad de un deploy de tres minutos, el agente perdió tiempo y contexto.
Por eso la conclusión del test es contraintuitiva: un framework “bueno para humanos” no es lo mismo que uno “bueno para agentes”. Uno puede ser conciso pero difícil de validar. Otro, verboso pero con un preview engine excelente. Un tercero convierte una propiedad mal escrita en un error de compilador exacto. La “elegancia” de la sintaxis pesa menos que la calidad del feedback.
¿Qué diferencias de sintaxis y curva de aprendizaje tienen CDK, Terraform, Pulumi y SST?
La diferencia central es lenguaje real versus lenguaje declarativo propio. CDK, Pulumi y SST usan TypeScript o Python, así que aprovechás loops, funciones, tipos y todo el tooling del lenguaje. Terraform usa HCL, que es declarativo y más explícito, con una curva más suave para quien nunca programó pero más verboso cuando la lógica se complica. Más contexto en otras herramientas de automatización modernas.
Si ya escribís TypeScript, CDK y SST te van a resultar naturales. El tema es que con más poder viene más forma de meter la pata. HCL es más rígido, y esa rigidez a veces juega a favor: hay menos maneras de escribir algo mal.
¿Cuál framework da el mejor feedback para que la IA repare errores?
CDK, según la prueba del 16/07/2026. La razón es que combina chequeo de tipos en tiempo de compilación (el error salta antes de desplegar) con la síntesis a CloudFormation, que agrega una segunda validación de schema. Ese doble control le da al agente dos oportunidades tempranas de atrapar un problema y arreglarlo sin llegar al deploy.
Terraform aporta su propio golazo con terraform plan, que muestra qué va a cambiar antes de aplicar. Es un preview fuerte. Pulumi combina tipos del lenguaje con un preview parecido. SST hereda el modelo de CDK y suma feedback pensado para el flujo serverless. Ninguno es malo; la diferencia es cuán rápido y cuán preciso llega el error a manos del modelo.
Prueba real: la misma API serverless en cada framework
El pedido fue idéntico para los seis enfoques: construir una API serverless de acortador de URLs con mentalidad de producción sobre AWS. Debía incluir una API Gateway HTTP API, una función Lambda y una tabla DynamoDB. Nada exótico, un caso que cualquiera que haya tocado serverless reconoce al toque. Tema relacionado: comparamos distintos modelos de IA.
El autor evaluó cinco cosas en el código que generó GPT: si eligió los recursos correctos y los conectó bien, si evitó permisos IAM excesivos, si el código era consistente con el modelo actual del framework, qué tan útiles eran los errores del compilador, validador o preview, y cuánta corrección humana haría falta antes de un deploy seguro. CDK lideró justamente por la reparabilidad, gracias a esos mensajes de error precisos que le permitieron al modelo cerrar el loop rápido. Acá va la comparación general según esa prueba.
| Framework | Lenguaje | Validación temprana | Fortaleza para IA |
|---|---|---|---|
| AWS CDK | TypeScript / Python | Tipos + síntesis CloudFormation | Mejor loop de feedback (ganador) |
| Terraform | HCL | terraform plan | Preview claro de cambios |
| Pulumi | TS / Python / Go / C# | Tipos + preview | Multi-nube con lenguaje real |
| SST | TypeScript | Hereda CDK | Foco serverless full-stack |
¿Qué factores pueden cambiar el resultado de esta comparación?
Muchos, y el autor es honesto en aclararlo. Sus palabras: es una prueba de escritorio chica, direccional y opinada, no un benchmark estadístico controlado. Los puntajes son heurísticas de ingeniería, no tasas de aprobación universales. Tomalo con pinzas.
- El modelo elegido: otro LLM, u otra versión, puede rendir distinto con cada framework.
- La versión del framework: CDK, Terraform y Pulumi cambian rápido; una release nueva mueve la aguja.
- La documentación provista: cuántas docs y schemas le pasaste al agente en contexto.
- La calidad del loop de validación: cómo armaste el ciclo de correr, leer el error y reintentar.
- Los schemas del provider: un schema más rico le da al modelo mejores pistas para autocorregirse.
Cuando montás esta infra en la nube, tarde o temprano necesitás dónde correr los servicios que no son serverless: bases gestionadas, VPS, dominios. Si buscás hosting y dominios en Argentina, donweb.com es una opción para esa parte del stack.
Errores comunes al elegir un framework de IaC con IA
- Elegir por sintaxis linda en vez de por feedback. El código que “se ve bien” no es el que la IA puede reparar más rápido. Priorizá el que devuelve errores precisos y tempranos.
- Tomar esta prueba como veredicto absoluto. Es un test de un desarrollador, con un caso, un modelo y una fecha. Replicalo con tu propio stack antes de migrar todo.
- No armar el loop de validación. Si dejás que el agente escriba sin correr
plan, tipos o síntesis, tirás a la basura la ventaja principal de estos frameworks. El feedback sirve solo si lo ejecutás. - Ignorar el lock-in. CDK y SST son fuertes en AWS; si mañana necesitás multi-nube, Terraform o Pulumi te dan más margen. Elegí pensando en dónde vas a estar en dos años.
Preguntas Frecuentes
¿Cuál es el mejor framework de IaC para que lo use una IA?
Según la prueba publicada en dev.to el 16/07/2026, AWS CDK, por su loop de feedback: chequeo de tipos más síntesis a CloudFormation le dan al modelo errores precisos y tempranos para autocorregirse. El propio autor aclara que es un test direccional, no un benchmark estadístico.
¿Qué diferencia hay entre CDK y Terraform?
CDK usa lenguajes de programación reales (TypeScript, Python) y compila a CloudFormation, con foco en AWS. Terraform usa HCL, un lenguaje declarativo propio, y es agnóstico de nube. CDK te da tipos y lógica programable; Terraform te da un preview de cambios claro con terraform plan. Esto se conecta con lo que analizamos en evaluamos modelos de IA para código.
¿Qué es SST y en qué se diferencia de CDK?
SST es un framework en TypeScript para aplicaciones serverless full-stack en AWS, construido sobre CDK. Hereda su modelo de validación pero agrega una experiencia de desarrollo orientada al flujo serverless. CDK es más general; SST está más opinado hacia apps serverless.
¿Qué lenguajes soporta Pulumi?
Pulumi soporta TypeScript, Python, Go y C#, entre otros. Es multi-nube, así que la misma lógica sirve para AWS, Azure u otros providers. Combina los tipos del lenguaje con un preview de cambios previo al deploy.
¿Cuánto cuestan estos frameworks?
Los cuatro frameworks (CDK, Terraform, Pulumi, SST) son de código abierto y gratis en su uso base. Lo que pagás es la infraestructura de AWS que despliegan y, en algunos casos, servicios gestionados opcionales del proveedor del framework (por ejemplo, backends de estado en la nube).
Conclusión
Lo que cambió acá no es el ranking, es la vara. Cuando el que escribe la infra es un agente de IA, el ganador no es el framework más elegante sino el que devuelve el error más rápido y más preciso. CDK ganó esta prueba por eso, y la lógica se sostiene más allá del test puntual.
¿Qué hacer con esto? Si trabajás sobre AWS y vas a delegar parte de la infra a un modelo, probá CDK con un loop de validación real (tipos, síntesis, reintentos) y medí vos mismo la reparabilidad. Si necesitás multi-nube, mirá Terraform o Pulumi. Y no tomes ninguna nota, esta incluida, como palabra final: replicá la prueba con tu stack, tu modelo y tu caso antes de mover producción. Es una prueba de escritorio, no una ley.
