Serie sobre Agentic IaC

Este es el primero de tres posts donde voy a documentar, paso a paso, la construcción de un agente de IA para proyectos de Infrastructure as Code. Sin hype, sin hablar de la IA como si fuera la magia salvadora del universo. Sin prometer que un único prompt va a resolver todos tus problemas de infraestructura. Ya te adelanto: no lo hará. Al final de este post estoy seguro de que te vas a dar cuenta de eso.

Lo que vas a encontrar aquí es orientación práctica, basada en referencias técnicas de ingeniería y en artículos de OpenAI, Anthropic y Martin Fowler que describen cómo equipos reales están construyendo y operando agentes en producción. La idea es traer ese conocimiento al contexto de quien trabaja con Terraform e IaC en el día a día.

La serie está organizada así:

• Post 1 (este): La anatomía del agente: qué es, cuáles son los mecanismos, cómo funciona la estructura
• Post 2: En la práctica: un paso a paso completo para entregar un proyecto real de principio a fin usando el agente
• Post 3: Distribución: cómo transformar el agente en un estándar del equipo y escalar a toda la organización

Cada post debe leerse de forma independiente, pero juntos intento crear una hoja de ruta básica para quien quiere ir más allá de “usar IA para generar código de IaC” y construir un sistema de entrega que aprende y mejora con el tiempo.

¿De acuerdo? ¡Vamos allá entonces!

Introducción a Agentic IaC

En muchas empresas, el equipo repite los mismos aciertos y errores en proyectos de IaC en cada sprint. El problema no es la falta de competencia. Es la falta de un sistema para gestionar todo eso.

Cuando el conocimiento vive en la cabeza de las personas y no en el repositorio, cada sesión de trabajo empieza de cero. Y es exactamente aquí donde entra una verdad que poca gente dice: el éxito de un agente de IA no depende del modelo que elijas. Depende del trabajo que haces antes de dar cualquier prompt. Es el proceso lo que importa.

Antes de montar un agente, necesitas mirar cómo trabaja tu equipo y hacer un ejercicio difícil. Revisar y eliminar procesos que existen por inercia, esos pasos que nadie sabe por qué están ahí. Si el proceso es confuso para un humano, va a ser confuso para un agente. Después, detallar lo que queda con suficiente claridad para que alguien que nunca lo vio pueda seguirlo. Y por último, la parte más importante: transformar el conocimiento tácito en reglas explícitas. Esa convención de naming que “todo el mundo sabe”. Ese workaround que el senior hace de memoria. Esa decisión arquitectónica que quedó registrada solo en una reunión. Si no está escrito en un archivo que el agente pueda leer, simplemente no existe para él.

Ese trabajo de explicitar, documentar y estructurar es la inversión real en la construcción de un Agentic IaC. Agentic IaC es la práctica de combinar un agente de IA con una estructura de reglas, contexto y validación que vive en el repositorio junto con el código de infraestructura. Una forma de empaquetar todo lo que tu equipo sabe en un formato que tanto humanos como agentes de IA pueden consumir. No estoy hablando de un chatbot genérico. Estoy hablando de una estructura operacional que le da al agente memoria, proceso y mecanismos de aprendizaje continuo. Eso es lo que hace que el enfoque sea “agentic”: el agente no solo responde preguntas o genera código bajo demanda. Opera dentro de un sistema que acumula contexto, sigue un proceso definido y mejora en cada ciclo. En este primer post, vamos a diseccionar la anatomía del bicho.

El problema que resuelve

Si trabajas con infraestructura como código, probablemente reconoces al menos uno de estos tres dolores:

Contexto que se pierde entre reuniones. Estabas trabajando en un módulo de VPC el viernes, vuelves el lunes y necesitas gastar 30 minutos reconstruyendo el razonamiento. Si es un colega asumiendo la tarea, peor todavía.

Errores que se repiten. Ese recurso de AWS que se recrea cuando cambias el nombre. Ese provider que tiene un bug conocido. Ese módulo que necesita un depends_on explícito o si no se rompe. Alguien lo descubre, lo resuelve, y seis meses después otro colega cae en la misma trampa.

Conocimiento que queda invisible. Las decisiones tomadas en una reunión. La convención de naming que “todo el mundo sabe”. El motivo por el cual el state está separado de esa manera. Si no está escrito en el repo, no existe para el agente y eventualmente tampoco va a existir para el equipo.

El agente no resuelve estos problemas mágicamente. Los resuelve porque la estructura a su alrededor obliga a que el conocimiento sea registrado, versionado y consultado.

Qué es un AI Agent (y qué no es)

Vamos a alinear el vocabulario. Cuando digo “agent” aquí, no estoy hablando de un modelo de lenguaje puesto en una terminal con acceso a comandos. Eso es una herramienta. Un agente es diferente.

La definición más útil que encontré viene de la comunidad de ingeniería de IA:

Agent = Model + Harness

El modelo es la inteligencia bruta, el LLM que genera texto, “razona”, escribe código. El Harness son las reglas, el contexto, los mecanismos de validación, las instrucciones de comportamiento. El modelo sin harness es como un perro loco que ladra y muerde sin parar. El harness sin modelo es el corral vacío y la correa colgada en la pared, es decir, un proceso bonito que nadie ejecuta.

El punto central aquí es que el trabajo de la persona de DevOps deja de ser “escribir código de infraestructura” y pasa a ser “diseñar el ambiente donde el agente puede trabajar bien”. Te conviertes en el arquitecto del sistema. El agente pasa a ser quien ejecuta.

Los humanos dirigen. Los agentes ejecutan.

Guides y Sensors: el modelo mental de trabajo

Aquí está el framework conceptual que organiza todo. Viene de la ingeniería de control y fue formalizado recientemente para el contexto de coding agents.

Existen dos mecanismos de control:

Guides (feedforward): anticipan problemas y dirigen al agente ANTES de que actúe. Son como los guardrails en una carretera de montaña. En el contexto de IaC, un guide es cualquier información que reduce la probabilidad de que el agente tome una decisión equivocada incluso antes de escribir la primera línea de código.

Ejemplos concretos de guides para IaC:

• Un documento que lista los CIDRs ya asignados en la organización evita que el agente proponga un rango que entre en conflicto con otra VPC
• Una regla explícita: “todo recurso AWS debe tener las tags project, environment, owner y managed_by”; el agente la aplica desde la primera iteración, sin necesidad de corrección humana
• Un checklist pre-apply: “verifica si el provider está fijado, si el backend está configurado, si no hay secrets hardcodeados”; el agente valida antes de presentar el plan
• La lista de módulos internos aprobados por el equipo, con versión y ejemplos de uso; en vez de inventar desde cero, el agente reutiliza lo que ya existe
• Convenciones de naming como {proyecto}-{env}-{recurso}-{az} documentadas en un archivo, no en la cabeza de alguien
• Anti-patterns conocidos: “nunca uses count para resources que tienen lifecycle dependencies; usa for_each”; el agente evita trampas antes de caer en ellas

Sensors (feedback): observan el resultado DESPUÉS de que el agente actúa y alimentan la autocorrección. Son como los sensores de temperatura en un datacenter. En el contexto de IaC, un sensor es cualquier verificación que detecta problemas en lo que el agente ya produjo.

Ejemplos concretos de sensors para IaC:

• terraform validate: sensor computacional básico. Si el código tiene un error de sintaxis o una referencia inválida, lo detecta de inmediato
• El diff de terraform plan es el sensor más importante. Muestra exactamente lo que va a cambiar. Si aparece un destroy inesperado o un must-replace en un recurso de producción, el agente necesita parar y escalar
• terraform fmt -check verifica si el formato sigue el estándar. Trivial, pero evita ruido en el code review
• Checkov, tfsec o Trivy: scanners de seguridad que detectan configuraciones inseguras (bucket S3 público, security group abierto a 0.0.0.0/0, encryption deshabilitada)
• Infracost estima el costo mensual de los recursos en el plan. El agente puede verificar si el cambio está dentro del presupuesto esperado antes de pedir aprobación
• Re-plan inmediato después del apply. Si terraform plan muestra diff después de aplicar, hay drift. El sensor lo detecta y el agente lo registra
• El propio FEEDBACK.md es el registro estructurado de los outcomes. Cada falla registrada es un dato que alimenta el aprendizaje del proceso

Si solo tienes guides sin sensors, el agente sigue reglas pero nunca descubre si funcionaron. Si solo tienes sensors sin guides, el agente repite los mismos errores hasta que alguien percibe el patrón.

Cada mecanismo además se divide en dos tipos de ejecución:

• Computational es determinístico, rápido, ejecutado por herramientas. El terraform validate es un sensor computational. El tfsec corriendo en un pre-commit hook es un sensor computational. Un script que verifica si todas las variables tienen description es un guide computational.
• Inferential está basado en juicio, ejecutado por el propio LLM. Una revisión del plan por parte del agente buscando impactos no obvios es un sensor inferential. Un documento de design principles que el agente consulta antes de diseñar la arquitectura es un guide inferential.

La combinación de los dos ejes forma la matriz completa:

El poder está en la combinación. Los sensors computacionales son rápidos y baratos. Ejecútalos en cada iteración. Los sensors inferenciales son más caros pero capturan problemas semánticos que ningún linter detecta (“ese security group está técnicamente válido, pero la regla de ingress es más permisiva de lo necesario para esa aplicación”).

Validation loops: el agente que se autocorrige

Uno de los patterns más poderosos en el harness es instruir al agente para que valide su propio trabajo antes de avanzar. El patrón es simple: ejecuta, valida, corrige, repite hasta pasar.

Esto no es una sugerencia, es una instrucción explícita en el PROCESS.md. El agente no necesita ser perfecto en el primer intento. Necesita un loop de autocorrección claro, con validadores computacionales que dan feedback inmediato y específico.

El mismo principio se aplica al plan. Antes de presentar el plan al humano, el agente verifica contra el FEEDFORWARD.md: ¿hay destroys inesperados? ¿hay resources sin tags? ¿pasa el checklist pre-apply? Si no pasa, corrige antes de escalar.

Ese pattern, el plan-validate-execute, es especialmente importante para operaciones destructivas. Crear un plan intermedio, validar contra una source of truth, y solo entonces ejecutar. El agente que se salta la validación es el agente que destruye una base de datos en producción.

El steering loop y el aprendizaje continuo

El nombre viene de la idea de steering, que significa pilotar, dirigir. Piensa en un auto. No controlas cada explosión en el motor ni cada giro de la rueda. Sostienes el volante y haces correcciones de rumbo. Si el auto tira hacia la izquierda, corriges. Si una curva es más cerrada de lo que parecía, ajustas. No ejecutas, diriges.

Con un agente de IA es lo mismo. El humano no se queda escribiendo cada línea de Terraform. Construye el sistema de control (guides y sensors) y después dirige ajustando las reglas, agregando fallas ocurridas, refinando checklists. El agente ejecuta dentro de ese sistema.

El “loop” es lo que cierra el ciclo. No es una ejecución lineal que empieza y termina. Es un ciclo continuo donde el resultado de cada ejecución alimenta la siguiente:

El humano define las reglas y prioridades. Los guides dirigen al agente antes de que actúe. El agente ejecuta. Los sensors observan el resultado. Si algo falló, el agente intenta autocorregirse. Si el mismo problema apareció dos veces, el humano mejora el harness, agrega un nuevo pitfall en el FEEDFORWARD.md, refina un checklist, documenta una convención. En la siguiente ejecución, ese conocimiento ya está en los guides. El feedback se convierte en feedforward.

El poder del steering loop es que mejora con el tiempo sin exigir más trabajo del humano; al contrario, exige menos. Cada corrección que haces en el harness y commiteas en git es una corrección que nunca más necesita hacerse manualmente.

En la práctica, un apply falla porque un security group referencia una VPC que todavía no existe. El agente lo registra en el FEEDBACK.md. La próxima vez que el mismo tipo de dependencia aparezca, el FEEDFORWARD.md ya contiene la prevención.

Cómo se mueve el conocimiento dentro del loop

En un flujo de trabajo tradicional, el conocimiento nace y muere dentro de la cabeza de quien lo ejecutó. El ingeniero descubre que un recurso de AWS tiene un comportamiento extraño, resuelve el problema y sigue adelante. Tres meses después, otro colega, o él mismo, cae en el mismo hoyo. El conocimiento existía, pero no estaba accesible.

El steering loop resuelve esto porque cada ejecución del agente se convierte en una oportunidad de capturar conocimiento y volverlo reutilizable. No es algo que sucede “cuando sobre tiempo” o “al final del proyecto”. Es parte del proceso, y sucede automáticamente en cada ciclo de trabajo.

La mecánica es simple y basada en frecuencia:

Primera ocurrencia de un problema: se registra en el FEEDBACK.md. Solo se observa. Puede ser un caso aislado, no vale la pena crear una regla para algo que quizás nunca se repita.

Segunda ocurrencia del mismo problema: ahora es patrón. Se promueve a MEMORY.md (se convierte en una lesson permanente que el agente consulta al inicio de cada sesión) y a FEEDFORWARD.md (se convierte en prevención activa que el agente verifica antes de actuar).

Falla crítica en cualquier ocurrencia: no espera a que se repita. Se promueve inmediatamente a ambos. Si tiró abajo un recurso en producción o causó downtime, eso se convierte en prevención al instante.

Éxito notable: el aprendizaje no es solo sobre errores. Un pattern que funcionó particularmente bien, como una forma de organizar módulos o una estrategia de state splitting, va al FEEDFORWARD.md como “proven pattern”.

Esto crea un ciclo virtuoso:

¿Por qué esto es tan importante en este nuevo flujo de trabajo? Porque un agente de IA no tiene la experiencia acumulada que carga un ingeniero senior. No “recuerda” que aquel provider tiene un bug, que aquel módulo necesita un workaround, que aquella cuenta tiene una restricción. Cada vez que el agente inicia una sesión, empieza sin contexto, a menos que ese contexto esté escrito en un archivo que él pueda leer.

El loop de aprendizaje transforma el harness en un sistema que se vuelve más inteligente con cada entrega. En la primera semana, el FEEDFORWARD.md está casi vacío y el agente necesita bastante supervisión. En el segundo mes, ya tiene decenas de pitfalls documentados, patterns probados y quirks de providers registrados. El agente comete menos errores, necesita menos corrección, y el humano gasta menos tiempo revisando, porque el conocimiento que antes vivía solo en la cabeza de las personas ahora está en el repositorio, accesible para cualquier operador, humano o agente.

Escribiendo instrucciones que funcionan

Tener la estructura de archivos es necesario, pero no suficiente. El contenido dentro de los guides necesita estar escrito de una forma que el agente realmente pueda usar. Instrucciones vagas como “sigue buenas prácticas” o “maneja los errores adecuadamente” no sirven para nada. Ese no es el lenguaje del agente. Necesita orientación concreta, específica de tu contexto.

Algunos principios que hacen la diferencia a la hora de escribir el contenido de tus guides:

Incluye lo que el agente no sabe, omite lo que ya sabe. No necesitas explicar qué es una VPC o cómo funciona el protocolo TCP. El modelo ya lo sabe. Lo que no sabe es que en tu empresa el CIDR 10.0.0.0/8 ya está asignado, que el equipo usa naming con el patrón {proyecto}-{env}-{recurso}, o que aquel módulo interno exige una dependencia explícita en el Internet Gateway. Enfócate en el conocimiento específico de tu contexto, porque es ahí donde el agente se equivoca sin orientación.

Las secciones de trampas conocidas valen oro. El contenido de mayor valor en un guide generalmente es una lista de “trampas” específicas del ambiente, esos detalles traicioneros que parecen funcionar pero se rompen de formas inesperadas. En inglés, el término usado es gotchas (de “got you”). Son situaciones donde el comportamiento por defecto engaña incluso a gente experimentada. No son consejos genéricos, son correcciones concretas para errores que el agente va a cometer si nadie avisa:

## Trampas Conocidas

- El módulo `vpc-core` v2.3 tiene un bug: si pasas `enable_dns = false`,
  lo ignora y lo habilita de todas formas. Usa v2.4+.
- Los security groups que referencian otros SGs por ID necesitan una dependencia
  explícita cuando están en módulos separados.
- El backend S3 en la cuenta de staging usa una KMS key diferente a la de producción.
  No copies el backend config de uno al otro sin ajustar.

Da defaults, no menús. Cuando existen múltiples formas de hacer algo, elige una como default y menciona alternativas brevemente. Presentar cinco opciones como iguales paraliza al agente, porque no tiene contexto para elegir.

Prefiere procedimientos a declaraciones. El guide debe enseñar al agente cómo abordar una clase de problemas, no cuál es la respuesta para una instancia específica. “Para crear un módulo nuevo, sigue: 1) crea el directorio en modules/, 2) define variables.tf con description y validation, 3) corre fmt y validate antes de commitear” es más reutilizable que listar exactamente qué variables debe tener un módulo específico.

Calibra el nivel de control. No toda instrucción necesita el mismo rigor. Sé prescriptivo cuando la operación es frágil o irreversible, por ejemplo: “corre exactamente terraform plan -out=plan.tfplan antes del apply, sin modificar flags.” Da libertad cuando múltiples enfoques son válidos, como: “organiza los outputs de forma que tenga sentido para quien los consuma downstream.”

Progressive disclosure: el mapa, no el manual

Volviendo a la estructura de archivos, existe una razón por la cual el AGENTS.md es corto y apunta a otros documentos en vez de contener todo.

El contexto de un LLM es finito. Cada token en el prompt compite por atención con todos los demás. Si le tiras 5.000 líneas de instrucciones al contexto del agente, se va a perder y va a seguir reglas que no se aplican a la tarea actual, o va a ignorar reglas críticas porque están enterradas en medio de información irrelevante.

La solución más recomendada es el progressive disclosure: el AGENTS.md carga lo esencial, es decir, quién es el agente, cómo opera y dónde buscar más detalle. Los otros archivos se cargan bajo demanda, cuando el agente necesita esa información específica.

En la práctica:

• AGENTS.md dice: “antes de aplicar, consulta la sección Pre-Apply Guards del FEEDFORWARD.md”
• El agente solo carga esa sección cuando llega a ese momento del proceso
• El MEMORY.md entero solo se consulta al inicio de la sesión para restaurar contexto

Esto mantiene al agente enfocado en lo que importa ahora, sin sobrecargarlo con todo lo que podría necesitar eventualmente.

La estructura de archivos de un Agent

Ahora vamos a lo concreto. El harness del agente vive como archivos .md en la raíz del repositorio. Cada archivo tiene una función precisa:

repo/
├── AGENTS.md        — El índice. Corto, estable, apunta a los otros.
├── MEMORY.md        — Memoria de largo plazo. Append-only.
├── HANDOFF.md       — Estado de la sesión actual. Se lee al inicio, se escribe al final.
├── FEEDFORWARD.md   — Guides: pitfalls, checklists, anti-patterns, principles.
├── FEEDBACK.md      — Sensors: registro de outcomes post-ejecución.
├── PROCESS.md       — Flujo de entrega (stages secuenciales).
├── TASKS.md         — Descomposición del trabajo actual.
└── CHECKLIST.md     — Quality gates por transición de stage.

AGENTS.md es el mapa. No es un manual de 500 líneas, sino un índice de ~100 líneas que le dice al agente quién es, cómo opera y dónde buscar información más profunda. Si pones todo en un solo archivo, el agente pierde foco. Si lo distribuyes en archivos con responsabilidad clara, navega con precisión.

MEMORY.md es append-only. Decisiones, lessons learned, error patterns, quirks de providers. Nunca se borra una entrada; si quedó obsoleta, se marca como superseded. Eso garantiza el audit trail.

HANDOFF.md es el artefacto de transición. Estado actual, lo que se hizo, lo que falta, blockers, riesgos. Cuando una sesión termina (o cuando el agente cambia de contexto), este archivo captura todo lo que el próximo operador necesita saber.

FEEDFORWARD.md contiene la inteligencia pre-ejecución. Pitfalls conocidos, checklists pre-plan y pre-apply, design principles, anti-patterns. Se consulta antes de cada acción significativa.

FEEDBACK.md registra outcomes. Cada apply, cada falla, cada rollback se convierte en una entry con: qué se intentó, qué se esperaba, qué pasó, root cause, resolución, y la lesson extraída.

PROCESS.md define los stages de entrega: Intake, Design, Build, Validate, Deploy, Close. Secuencial, sin saltos.

TASKS.md descompone el trabajo. Una task activa por vez. Cada task con criterio de aceptación claro.

CHECKLIST.md define quality gates. Antes de transicionar de Build a Validate, por ejemplo, el agente verifica: ¿pasa fmt? ¿pasa validate? ¿las variables tienen description? Sin pasar el gate, no avanza.

Construyendo a partir de expertise real

Un error común es pedirle al LLM que genere los guides desde cero, sin contexto específico de tu proyecto. El resultado son instrucciones genéricas e inútiles: “maneja los errores adecuadamente”, “sigue buenas prácticas de seguridad”. Eso no aporta nada.

Los mejores guides nacen de la experiencia real. Es en este punto donde nuestro conocimiento técnico acumulado hace la diferencia. Veamos dos formas de construirlos:

Extrae de una tarea concluida. Termina una entrega de IaC trabajando junto con el agente. Presta atención a los momentos en que corregiste el rumbo, como: “no, usa ese módulo en vez de aquel”, “aquí se necesita un validation block”. Esos momentos de corrección son el contenido de tu FEEDFORWARD.md. Extrae el patrón reutilizable.

Sintetiza a partir de los artefactos que ya existen. Tu equipo probablemente ya tiene runbooks, comentarios de code review, incident reports, historial de fixes en git. Ese material es oro. Un FEEDFORWARD.md construido a partir de tus incident reports reales va a capturar los failure modes específicos de tu ambiente, y no los genéricos de un blogpost.

Y después de crear la primera versión, refina con ejecución real. Corre el agente contra tareas concretas. Lee los traces de ejecución, no solo el output final. Si el agente está perdiendo tiempo intentando múltiples enfoques, el guide probablemente está demasiado vago. Si sigue instrucciones que no se aplican a la tarea, el guide está demasiado amplio. Itera.

Conclusión

Un AI Agent para proyectos de IaC no es un chatbot que corre terraform apply. Es un sistema de control con:

• Guides que previenen errores antes de la ejecución, escritos con conocimiento específico de tu contexto, no consejos genéricos
• Sensors que detectan problemas después de la ejecución y alimentan la autocorrección
• Memoria que acumula conocimiento a lo largo del tiempo
• Proceso que garantiza consistencia con validation loops en cada etapa
• Handoff que preserva el contexto entre sesiones
• Progressive disclosure que mantiene al agente enfocado sin sobrecargarlo

Pero antes de salir a montar la estructura, una advertencia importante: nada de esto funciona si simplemente pones un agente de IA encima de tu proceso actual y esperas que las cosas se aceleren. La IA no acelera el desorden, escala el desorden. Si tu flujo de entrega tiene etapas que nadie sabe por qué existen, el agente va a seguir esas etapas ciegamente. Si tus convenciones son contradictorias, el agente va a producir resultados contradictorios. Si el conocimiento del equipo está esparcido en Slack, Confluence y cabezas, el agente no va a tener acceso a nada de eso.

El trabajo real empieza antes del primer prompt. Revisar lo que hacen hoy. Eliminar lo que ya no tiene sentido. Adaptar lo que funciona pero necesita ser explicitado. Documentar lo que siempre fue implícito. Ese ejercicio de mirar hacia adentro, simplificar y estructurar es lo que separa a un equipo que usa IA de verdad de un equipo que solo instaló una herramienta más.

Y no es un ejercicio que haces una vez y listo. El harness necesita evolucionar junto con el equipo, con los proyectos, con los providers, con los modelos de IA. Revisar, ajustar, cambiar, acompañar continuamente. El steering loop no es solo para el agente. Es para todo el equipo. La estructura entera cabe en ocho archivos markdown versionados en el mismo repo de tu código de infraestructura. Sin dependencias externas. Sin herramientas adicionales. Sin base de datos.

En el próximo post, voy a tomar esta estructura y usarla para entregar un proyecto real de principio a fin, con una hoja de ruta completa por cada etapa del proceso. Vas a ver al agente consultando FEEDFORWARD.md, registrando en FEEDBACK.md, y actualizando HANDOFF.md en tiempo real.

¡Un abrazo!

¡Larga y próspera vida a todos!

Referencias

• Harness engineering: leveraging Codex in an agent-first world — OpenAI, Feb 2026
• Harness design for long-running application development — Anthropic, Mar 2026
• Harness engineering for coding agent users — Martin Fowler / Birgitta Böckeler, Abr 2026
• Best practices for skill creators — Agent Skills
• Spec Driven llegó al límite — Harness Engineering es el próximo paso — Aprendí mucho con ese video ⭐⭐⭐⭐⭐
• https://infraascode.com.br/ia-como-copiloto-em-infraestrutura/ — Curso desarrollado por el autor
• https://infraascode.com.br/ia-como-copiloto-em-infraestrutura-v2/ — Curso desarrollado por el autor
• https://infraascode.com.br/meu-amigo-robo/ — Post sobre cómo hacer troubleshooting con IA
• https://infraascode.com.br/nao-tenha-medo-da-ia-estude-os-fundamentos/ — Post sobre los fundamentos de IA

Entre em contato: