Decidí hacer un experimento que ya imaginaba que iba a funcionar, pero aun así me pareció válido hacerlo y compartirlo aquí en el blog, pues tal vez sea una idea nueva y útil para alguien. Lo más importante es el proceso y no el experimento en sí. El experimento realizado fue el siguiente: a partir de un diseño de arquitectura como código le pedí a un asistente de IA que hiciera el IaC con Terraform de ese diseño. ¿Adivina el resultado?!!

En minutos, la infraestructura estaba codificada. Organizada en archivos. Con security groups, subnets, IAM roles. Todo estaba hecho, no usé ninguna herramienta secreta. Junté dos cosas que ya existen: Diagram as Code e Inteligencia Artificial.

Ese resultado me viene haciendo repensar cómo trabajamos con infraestructura. Fue una prueba simple, tal vez en algo más complejo no funcionaría tan bien, puede ser, pero no deja de ser una indicación de cambio en la forma en que trabajamos hoy.

La IA no es futuro, es el presente. El futuro sigue siendo difícil de prever

Las personas que trabajan con IaC necesitan actualizarse con estas nuevas herramientas y empezar a incorporar cada vez más las nuevas formas de trabajo en su día a día. Eso es de gran valor y de suma importancia para mantenerse en el mercado profesional.

El experimento

Voy a mostrarte todo el proceso que realicé.

A partir del código de un diagrama de una infraestructura, le “pregunté” a una IA si conseguiría interpretar un diagrama y generar Terraform. El ejemplo que usé, con código real, es un flujo completo, del diagrama al terraform plan. Muestro también lo que funcionó y lo que necesita atención y, al final, muestro hacia dónde va esa combinación de IaC e IA. Si trabajas con redes, sistemas o cloud, necesitas leer esto.

La rutina de hacer IaC todavía duele

Quien trabaja con cloud ya lo sabe: crear recursos por la consola no funciona a largo plazo. Esto es I-N-D-I-S-C-U-T-I-B-L-E!!! Creas un security group hoy, la semana que viene alguien crea otro parecido. El mes que viene, nadie sabe cuál es cuál. Alguien intenta replicar el entorno de staging a producción y descubre que la mitad de las configuraciones no están documentadas.

Terraform, Pulumi, CloudFormation son herramientas que resolvieron buena parte de ese problema. La infraestructura pasó a ser descrita en archivos de texto. Se puede versionar en Git. Se puede revisar en un pull request. Se puede destruir y recrear sin miedo y con bastante confianza.

Pero seamos honestos. Escribir IaC todavía lleva tiempo crearlo y da trabajo mantenerlo; es necesario estudiar y conocer la sintaxis HCL. Hay que saber qué argumentos acepta cada recurso, hay que entender el orden de las dependencias, hay que recordar cómo configurar un target group, un listener, un subnet group.

Es un trabajo repetitivo. Y si es un trabajo repetitivo, es exactamente el tipo de cosa que la IA hace bien. #ficadica #ficaalerta

Diagram as code: arquitectura en código Python

Antes de hablar de la IA, necesito presentarte la biblioteca Diagrams de Python. Hay un post en el blog sobre esto si no la conoces, te va a gustar, te lo garantizo. La propuesta es bien simple. Escribes código Python describiendo componentes de infraestructura y las conexiones entre ellos. Corres el script. Sale una imagen con el diagrama de la arquitectura. Sin arrastrar cajitas, sin alinear flechas, sin exportar PNG manualmente.

Este fue el código que usé en mi prueba:

from diagrams import Cluster, Diagram
from diagrams.aws.compute import ECS
from diagrams.aws.database import ElastiCache, RDS
from diagrams.aws.network import ELB, Route53

with Diagram("Clustered Web Services", show=False):
    dns = Route53("dns")
    lb = ELB("lb")

    with Cluster("Services"):
        svc_group = [ECS("web1"),
                     ECS("web2"),
                     ECS("web3")]

    with Cluster("DB Cluster"):
        db_primary = RDS("userdb")
        db_primary - [RDS("userdb ro")]

    memcached = ElastiCache("memcached")

    dns >> lb >> svc_group
    svc_group >> db_primary
    svc_group >> memcached

Mira lo que está descrito ahí:

• Route53 como DNS.
• Un load balancer recibiendo el tráfico.
• Tres servicios ECS: web1, web2, web3.
• Un cluster de base de datos con RDS primario y una réplica de lectura.
• ElastiCache corriendo Memcached.
• El flujo: DNS apunta al LB, el LB distribuye a los servicios, los servicios acceden a la base de datos y a la caché.

Corrí el script. Salió un PNG con todo eso dibujado, limpio, organizado. Listo para poner en documentación o presentar al equipo. Y lo más importante, está en código, versionado. Cuando la arquitectura cambie, actualizo el script y el diagrama lo acompaña.

Hasta aquí, nada de IA. Pero fue el próximo paso el que cambió, presta atención.

La IA lee el código del diagrama y genera el Terraform

Tomé el código Python del diagrama y se lo pasé a la IA. Le pedí que analizara los componentes, entendiera las relaciones y generara el Terraform correspondiente.

Hizo exactamente eso. No vino un template genérico. Vino código que refleja la arquitectura descrita en el diagrama. Cada componente mapeado. Cada conexión traducida en configuración.

Lo que la IA generó:

• Red — Una VPC con CIDR definido. Dos subnets públicas y dos privadas, en zonas de disponibilidad diferentes. Internet Gateway para el tráfico externo. NAT Gateway para que los recursos privados accedan a internet. Route tables configuradas.

• Security Groups — Separados por capa. El del ALB acepta tráfico HTTP de cualquier origen. El del ECS solo acepta tráfico proveniente del ALB. El del RDS solo acepta conexión proveniente del ECS. El del ElastiCache, lo mismo. Cada uno en su ámbito.

• Load Balancer — Un Application Load Balancer en las subnets públicas. Target group apuntando a los containers. Listener en el puerto 80 reenviando al target group.

• ECS — Un cluster Fargate. Una task definition con la configuración del container. Tres servicios — web1, web2, web3 — cada uno corriendo una task. Todos registrados en el target group del ALB.

• RDS — Instancia MySQL 8.0 como primaria. Una réplica de lectura apuntando a ella. Ambas en las subnets privadas, protegidas por el security group.

• ElastiCache — Cluster Memcached con un nodo, corriendo en las subnets privadas. Puerto 11211. Acceso restringido al security group del ECS.

• Route53 — Hosted zone con el dominio. Registro A del tipo alias apuntando al DNS del ALB.

Todo separado en archivos: network.tf, security_groups.tf, alb.tf, ecs.tf, rds.tf, elasticache.tf, route53.tf, variables.tf, outputs.tf.

Mientras generaba me quedé mirando aquello y pensando: ¿cuánto tiempo tardaría en escribir todo eso a mano? ¿Una hora? ¿Dos? Dependiendo del día, más. La IA tardó segundos.

Mira el flujo completo, paso a paso

Déjame organizarte lo que pasó; el flujo es más simple de lo que parece.

Paso 1: Escribí el diagrama en Python. Listé los componentes, definí la relación de los componentes y describí las conexiones con los operadores >> y -.

Paso 2: Corrí el script con python3 diagrama_as_code_cluster.py. Se generó un archivo PNG con el diagrama. Sirve para documentación, para presentar al equipo, para discutir arquitectura en una reunión.

Paso 3: Le pasé el código del diagrama a la IA y le pedí: “lee este diagrama y genera el Terraform en AWS”, podría ser Azure o GCP sin problemas.

Paso 4: La IA devolvió los archivos .tf con toda la infraestructura mapeada y organizada. Con variables para datos sensibles. Con outputs para los endpoints.

Paso 5: Copié los archivos a una carpeta Terraform/. Creé el terraform.tfvars con los valores. Corrí terraform init y terraform plan.

Del diagrama al plan de ejecución y creación de la infra. Sin saltarse etapas. Pero sin perder tiempo con el trabajo que se repite.

Una de las salidas generadas.

cat  ./Terraform/network.tf
data "aws_availability_zones" "available" {}

##
## NO UTILIZAR ESTE CÓDIGO
##

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "${var.project}-vpc" }
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = cidrsubnet(var.vpc_cidr, 8, count.index)
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true
  tags = { Name = "${var.project}-public-${count.index}" }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(var.vpc_cidr, 8, count.index + 10)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  tags = { Name = "${var.project}-private-${count.index}" }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "${var.project}-igw" }
}

resource "aws_eip" "nat" {
  domain = "vpc"
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public[0].id
  tags          = { Name = "${var.project}-nat" }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }
  tags = { Name = "${var.project}-public-rt" }
}

resource "aws_route_table" "private" {
  vpc_id = aws_vpc.main.id
  route {
    cidr_block     = "0.0.0.0/0"
    nat_gateway_id = aws_nat_gateway.main.id
  }
  tags = { Name = "${var.project}-private-rt" }
}

resource "aws_route_table_association" "public" {
  count          = 2
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table_association" "private" {
  count          = 2
  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private.id
}

¿Qué funcionó?

Este flujo, sin la menor sombra de duda, trae ganancias. Mira lo que percibí como ganancia concreta.

• Tiempo — la parte de escribir HCL dejó de ser un cuello de botella. Sobró más tiempo para pensar en la arquitectura, discutir trade-offs, evaluar costos.

• Documentación que acompaña al código — el diagrama y el Terraform nacen de la misma fuente. No existe ese problema de que alguien cambie la infra y se olvide de actualizar el dibujo en Confluence; ya nace junto.

• Barrera de entrada — alguien que entiende de arquitectura pero no domina Terraform consigue contribuir. Monta el diagrama en Python, la IA genera la base, el equipo de infra revisa y ajusta.

• Aprendizaje — si estás estudiando Terraform, ver el código generado a partir de un diagrama que entiendes ayuda a conectar los conceptos.

• Consistencia — la IA aplicó la separación de security groups por capa, usó variables para datos sensibles, colocó recursos de base de datos y caché en subnets privadas. Cosas que a veces uno olvida cuando está con prisa.

¿Dónde hay que tener cuidado?

Las cosas no son 100% preciosas :) con la IA. Mira algunos puntos de atención que he visto que son bien importantes.

• La revisión no es opcional — la IA entrega un punto de partida. Pero los tipos de instancia pueden no servir para tu escenario. Una instancia que funciona para prueba puede no funcionar para producción. Necesitas mirar cada recurso y evaluar si tiene sentido.

• El entendimiento sigue siendo tuyo — la IA no sustituye saber cómo funcionan las cosas. ¿Por qué el NAT Gateway está ahí? ¿Cuánto cuesta por mes? ¿Por qué el RDS está en una subnet privada y no pública? Si no sabes responder esas preguntas, el código generado se vuelve una caja mágica.

• Datos sensibles. — ¿el Terraform generado usa variables del tipo sensitive para las contraseñas? ¿Eso es lo correcto? Te corresponde a ti garantizar que el terraform.tfvars no vaya a parar a un repositorio público. Parece obvio, parece raro, pero pasa con frecuencia.

• Producción pide más — el código generado es una base. Para correr en producción de verdad, vas a necesitar monitoreo con CloudWatch, alarmas, backups automatizados, multi-AZ en RDS, auto scaling en ECS, certificado SSL en el ALB. La IA entrega la estructura. Tú la complementas según la necesidad del entorno.

• Costos — cada recurso generado tiene un costo en la nube. NAT Gateway, ALB, RDS, ElastiCache, todo entra en la cuenta. Antes de correr terraform apply, vale pasar el plan por una calculadora de costos para no llevarte sorpresas a fin de mes. Recuerda: a la AI no le importan los costos si no mencionas nada en el prompt.

¿Hacia dónde va esto?

Honestamente es difícil afirmarlo. Esta unión de IaC e IA está en el comienzo y el comienzo ya está así. Pero el futuro va a tener IA, va a tener Agents de IA haciendo IaC, skills de IA verificando IaC, va a haber IA con IaC, eso ya se puede afirmar.

Hoy, la IA lee un diagrama en Python y genera Terraform, vieron el ejemplo del post. Ya existe AI para sugerir cambios en la arquitectura, señalar fallas de arquitectura y seguridad. Las IAs te van a avisar que puedes cambiar un componente X por otro Y y economizar; la IA te va a recomendar una arquitectura multi-AZ antes de que te acuerdes de pedirla.

No creo que la IA vaya a sustituir a quien trabaja con infra. El contexto del negocio, las decisiones de arquitectura, la evaluación de riesgo, esas cosas siguen siendo cosa de humanos. Pero la parte de traducir decisiones en código, de escribir código, de recordar la sintaxis de cada recurso, esa parte la IA la hace bien, y la hace rápido.

Una palabra para calmar el alma. Jóvenes, no entren en pánico pensando que van a perder el empleo la semana que viene por una IA, eso no va a pasar, quédense tranquilos. Pero #ficadica, ¡EMPIECEN YA!!, no esperen, no pierdan tiempo, estudien conceptos, herramientas y hagan pruebas!! Otra cosa que se puede hacer: miren sus procesos de hoy y háganse la siguiente pregunta: “¿En cuál de estas etapas la IA puede ayudarme a mejorar algo real, si la coloco en el pipeline??”.

Quien incorpore la IA al flujo de trabajo de hoy resolviendo problemas reales va a conseguir entregar más valor a su producto y a su empresa. Eso ya te pone un paso adelante, pero sigue dando otros pasos.

¡Abrazos!

¡Larga vida y prosperidad para todos!!

Referencias

• https://infraascode.com.br/diagrama-as-code/
• https://infraascode.com.br/diagrama-as-code-com-chatgpt-p2/
• https://diagrams.mingrammer.com/docs/nodes/c4
• https://www.pulumi.com/
• https://www.crossplane.io/

Entre em contato: