IA para reparar Terraform drift: así funciona tfdrift

En pocas palabras: sí, el comando tfdrift remediate de la versión 0.5.3 del CLI open source tfdrift, creado por Sudarshan Thakur, detecta el drift entre tu código Terraform y la infraestructura real, y usa Claude o GPT-4o para generar un archivo .tf corregido en HCL, listo para revisar y aplicar.

El desarrollador Sudarshan Thakur lanzó tfdrift remediate, el nuevo comando de su CLI open source tfdrift (versión 0.5.3) y una apuesta concreta de IA para reparar Terraform drift: escanea tus workspaces, detecta la desviación entre el código y la infraestructura real, y genera un archivo .tf corregido usando Claude o GPT-4o, listo para revisar y aplicar.

Contexto para el que llega recién: tfdrift es una herramienta de línea de comandos gratuita, con licencia Apache 2.0, que vigila de forma continua la distancia entre lo que declarás en Terraform u OpenTofu y lo que de verdad corre en tu nube. Clasifica cada desviación por severidad, te avisa por Slack, Teams u OpsGenie y, desde la 0.5.3, redacta la corrección en HCL con comentarios que explican cada cambio. Vos revisás, ajustás lo que haga falta y recién ahí aplicás.

¿Qué es el drift de Terraform y por qué aparece?

El drift de Terraform ocurre cuando la infraestructura real de tu nube deja de coincidir con lo que declara tu código, y la causa más común son los cambios hechos a mano desde la consola. Según la documentación de HashiCorp, Terraform compara el estado declarado con el estado real de los recursos en cada plan; cualquier diferencia entre ambos es drift.

Ponele que corrés terraform plan un lunes a la mañana y aparecen 12 cambios que nadie pidió. Alguien agrandó una instancia en la consola. Otro agregó una regla a un security group. Un tercero borró un tag. (Todos fuimos ese alguien alguna vez, seamos honestos.)

Eso es drift. Y el ejemplo que trae el propio anuncio es de manual: una instancia web que pasó de t3.medium a t3.large fuera del código, más reglas de ingress añadidas a mano en un security group. Duele. Más todavía si nadie documentó el cambio. Para más detalles técnicos, mirá cómo evitar caídas por errores de DNS.

¿Por qué arreglar el drift a mano es un suplicio?

“Detectar el drift es una cosa. Arreglarlo de verdad es donde los ingenieros pierden horas”, escribió Thakur en el anuncio de la función (traducción propia). Y el diagnóstico es correcto: el flujo manual de siempre consiste en mirar el output del plan, identificar qué atributos cambiaron, editar los archivos .tf para que vuelvan al estado deseado, verificar y aplicar.

Con uno o dos recursos, zafa. Ahora bien, cuando tenés diez o más recursos repartidos en varios workspaces, el proceso se vuelve lento y propenso a errores, sobre todo con tipos complejos como aws_security_group, aws_iam_role_policy o azurerm_virtual_network, donde un argumento mal puesto te deja un puerto abierto de par en par o un rol roto. Mirás el plan, abrís el .tf, editás a mano, rezás para no romper nada, volvés a correr el plan y descubrís que te faltó un argumento y que el security group quedó distinto de lo que esperabas, así que borrás todo y arrancás de nuevo. Horas perdidas que nadie te devuelve.

¿Cómo funciona tfdrift remediate, la IA para reparar Terraform drift?

tfdrift remediate toma el drift ya detectado, se lo presenta a un modelo de lenguaje con el contexto completo y devuelve un archivo drift-remediation.tf con el HCL corregido y comentado. El flujo, según el repositorio oficial del proyecto, tiene cinco pasos:

• Escanea todos los workspaces de la ruta que le indiques buscando drift activo.
• Lista cada recurso afectado con su severidad y la cantidad de atributos cambiados.
• Te pregunta qué querés arreglar: todo de una (A) o recursos específicos (S).
• Manda el contexto completo a la IA: tipo de recurso, acción necesaria y valor deseado frente a valor actual de cada atributo.
• Escribe el archivo de remediación con comentarios inline que explican cada corrección.

El prompt interactivo se ve así (le saqué los circulitos de color, pero la estructura es idéntica):

Found 3 drifted resource(s):
aws_instance.web high - 2 attribute change(s)
aws_s3_bucket.logs medium - 1 attribute change(s)
aws_security_group.app high - 3 attribute change(s)

What would you like to remediate?
Choice [A]:

Elegís S y ponés 1,3 para remediar solo los de severidad alta, o A para generar el fix de todo. La salida es HCL válido con comentarios:

# Generated by tfdrift remediate
# Restores instance type to desired state
resource "aws_instance" "web" {
 instance_type = "t3.medium" # corrected: actual was t3.large
}

Lo revisás, ajustás lo que quieras y aplicás con terraform apply drift-remediation.tf. ¿Y si la IA se manda una? Puede pasar, y por eso el archivo pasa por tus ojos antes de tocar un solo recurso. Lo explicamos a fondo en comparativa de pipelines de CI/CD.

¿Qué proveedores de IA soporta tfdrift y cómo se configuran?

La herramienta auto-detecta el proveedor según tus variables de entorno: si encuentra ANTHROPIC_API_KEY usa Claude, la opción preferida del proyecto, y si solo hay OPENAI_API_KEY recurre a GPT-4o como respaldo. La instalación lleva un comando y la configuración es exportar la key:

pip install 'tfdrift[ai]'
export ANTHROPIC_API_KEY=sk-ant-...
tfdrift remediate --path ./infra

¿Preferís forzar un proveedor puntual? Existe el flag –provider:

tfdrift remediate --provider openai --path ./infra

Que Claude sea el default no me sorprende: en generación de código los modelos de Anthropic suelen comportarse bien. Igual tomalo con pinzas, porque no hay benchmark público comparando a los dos dentro de la herramienta; para HCL corto, en la práctica, cualquiera de los dos debería zafar.

¿Es seguro dejar que una IA aplique cambios en producción?

Acá está la decisión de diseño más importante de la herramienta: tfdrift remediate no aplica nada, genera un archivo para que un humano lo revise antes, mientras que el modo “auto-fix” de tfdrift scan corre terraform apply sin preguntar. Son caminos distintos para necesidades distintas, y conviene tenerlos claros:

Método	Qué hace	Control humano	Cuándo conviene
Edición manual	Leés el plan y corregís los .tf a mano	Total	Uno o dos recursos, cambios triviales
tfdrift scan –auto-fix	Detecta el drift y corre terraform apply directo	Casi nulo	Entornos descartables o de prueba
tfdrift remediate	La IA genera un archivo comentado para revisar	Alto: revisás antes de aplicar	Producción, muchos recursos, equipos

¿Por qué importa tanto la revisión humana? Porque que la IA “entienda” tu infraestructura suena lindo, pero el modelo trabaja con el contexto del plan y no conoce tu intención de negocio. Un cambio manual a veces es un hotfix legítimo hecho de madrugada durante un incidente, y revertirlo en automático te tira abajo el arreglo justo cuando más lo necesitabas. Mi consejo: remediate para producción, siempre; el “auto-fix” dejalo para entornos de prueba que podés romper sin drama. Más contexto en cuál elegir entre Jenkins y GitHub Actions.

¿Qué características tiene tfdrift y qué viene en el roadmap?

Antes de este lanzamiento, tfdrift ya hacía detección continua de drift en Terraform y OpenTofu: corre terraform plan en todos tus workspaces, clasifica cada desviación por severidad (critical, high, medium, low) y manda alertas a Slack, Teams u OpsGenie. Todo eso sigue igual; lo nuevo es la capa de remediación.

Según el anuncio, estas mejoras están en el radar del proyecto:

• Planes de remediación multi-workspace consolidados en un único archivo.
• Filtrado por severidad con –min-severity high, para remediar solo lo crítico y lo alto.
• Generación automática de pull requests en GitHub con el archivo de remediación adentro.

La de los PRs me parece la más interesante: si el fix entra como pull request, el cambio pasa por revisión de código del equipo y queda registrado en el repo, que es exactamente donde debe vivir. Para integrarlo a tu pipeline, podés programar el scan en un job periódico de CI y dejar la remediación como paso manual con revisión; el soporte de OpenTofu vía –binary tofu también juega a favor si ya migraste.

¿Cómo empezar a usar tfdrift remediate paso a paso?

Tres comandos y estás en marcha: instalás el paquete con el extra de IA, exportás la API key de tu proveedor y corré el comando apuntando a tu carpeta de infraestructura.

pip install 'tfdrift[ai]'
export ANTHROPIC_API_KEY=sk-ant-...
tfdrift remediate --path ./infra

Flags útiles para el día a día:

• –all: arregla todo sin pasar por el prompt interactivo.
• –output my-fixes.tf: elige el nombre del archivo de salida.
• –provider openai: fuerza GPT-4o aunque tengas key de Anthropic.
• –binary tofu: usa OpenTofu en lugar de Terraform.

Eso sí, sugerencia de quien ya rompió cosas en producción: arrancá con un workspace chico de staging, mirá qué tan bien interpreta tu HCL y recién después lleválo a entornos serios.

Errores comunes al usar IA para reparar Terraform drift

• Aplicar el archivo generado sin leerlo. Los comentarios inline existen para eso mismo: explican qué se corrige y por qué. Si no los leés, tirás a la basura el único filtro entre la IA y tu producción.
• Confundir remediate con auto-fix. Uno genera un archivo para revisar; el otro aplica directo. Mezclarlos en producción es la receta perfecta para un incidente evitable.
• Tratar el síntoma e ignorar la causa. Si tu equipo sigue tocando recursos desde la consola, el drift vuelve. (Spoiler: vuelve a pasar.) Poné reglas claras: los cambios entran por código y la consola queda en modo lectura para producción.
• Asumir que la IA conoce tu negocio. Antes de revertir un drift, preguntale al equipo si ese cambio manual era intencional. Diez segundos de pregunta ahorran horas de rollback.

Preguntas Frecuentes

¿Qué es tfdrift y quién lo desarrolló?

tfdrift es una CLI open source (licencia Apache 2.0) de detección continua de drift para Terraform y OpenTofu que desarrolló el ingeniero Sudarshan Thakur. La versión 0.5.3 incorporó el comando tfdrift remediate con generación de correcciones por IA. Ya lo cubrimos antes en SEO internacional con etiquetas hreflang.

¿Puedo usar Claude o GPT-4o para reparar drift en Terraform?

Sí. tfdrift remediate usa Claude cuando detecta la variable ANTHROPIC_API_KEY (proveedor preferido) y GPT-4o como alternativa con OPENAI_API_KEY. También podés forzar el proveedor con el flag –provider openai.

¿Cuál es la diferencia entre detectar drift y remediarlo?

Detectar es correr terraform plan y clasificar las diferencias entre código e infraestructura, algo que tfdrift hacía desde versiones anteriores. Remediar es generar la corrección concreta en HCL: el comando tfdrift remediate hace ambas cosas y entrega un drift-remediation.tf listo para revisar.

¿Es seguro aplicar los cambios que genera la IA?

El diseño de la herramienta apunta a que no apliques nada a ciegas: remediate produce un archivo comentado para revisión humana antes del apply. La variante scan –auto-fix sí aplica directo, y esa conviene reservarla para entornos no productivos.

¿Cuánto cuesta tfdrift?

Nada: el proyecto es open source bajo licencia Apache 2.0. El único costo posible es el consumo de API del modelo que elijas (Anthropic u OpenAI), y lo factura cada proveedor según sus tarifas.

Conclusión

Hasta ahora, el ciclo del drift terminaba siempre igual: la detección era automática y el arreglo, artesanal. Con tfdrift 0.5.3 la parte mecánica de redactar el fix pasa a la IA y el criterio queda donde debe estar, en vos. Ganás horas y reducís errores manuales; de paso, el archivo comentado documenta qué se corrigió y por qué.

Si querés probarlo, el camino es corto: instalalo, configurá tu API key, corrélo sobre un workspace de staging y evaluá si vale para tu flujo. Y si tu infraestructura vive en un VPS o un servicio de hosting local como donweb.com, el principio no cambia: los cambios entran por código, nunca por panel. Tu yo del futuro, el que no tenga que reconstruir un security group a las 2 de la mañana, te lo va a agradecer.

Fuentes

• DEV Community – Anuncio oficial de tfdrift remediate por Sudarshan Thakur
• GitHub – Repositorio oficial de tfdrift
• HashiCorp – Documentación de Terraform sobre estado e infraestructura declarada
• OpenTofu – Sitio oficial del proyecto open source compatible con Terraform