Infra Course: un curso de Azure a medida, construido a partir de nuestra propia nube

TL;DR

Cuando pasé a ser CTO de Footprint Technologies, tuve que hacerme cargo de nuestra nube en Azure, y la verdad es que no la entendía bien. Le pedí a Claude que me construyera un curso sobre nuestra propia infraestructura. Leyó el sistema en vivo y nuestro Terraform, lo contrastó todo con la documentación oficial y después me examinó sobre lo que tenemos de verdad.

El primer examen me dio un 75%. Pero solo 7 de las 28 respuestas eran correctas y las había marcado como “seguro”. El resto era casi todo adivinar.

El vídeo y las capturas salen de una copia anonimizada del curso. Los nombres de recursos, IDs, dominios y rangos de red son inventados, y no aparece ningún hallazgo de auditoría.

¿Qué es esto?

Es un curso privado que corre en mi portátil. Tiene siete módulos, uno por cada parte de nuestra nube: fundamentos, Terraform, redes, cómputo, datos y secretos, identidad, y edge/CI. Cada módulo explica primero el concepto, luego enseña cómo lo tenemos montado nosotros y después me hace practicarlo. En un lateral hay un chat que sabe qué página estoy leyendo, para preguntarle lo que la página no explica bien.

¿Por qué lo construí?

Cuando pasé a ser CTO había huecos en mi experiencia que tenía que cubrir. Venía de la parte de deep tech y producto de la empresa, y la arquitectura de Azure era algo para lo que no estaba preparado. Una parte de mí todavía dudaba de si tenía que ser yo quien la gestionara.

“A lo mejor podemos contratar a alguien que nos ayude con esto”, pensé. Después de una charla con nuestro anterior CTO, esa idea desapareció. “Ahora el CTO eres tú, me temo que esta responsabilidad viene con el cargo”, me dijo.

Bueno, si quería entenderlo de verdad, mejor empezar por lo básico. Así que me puse un objetivo: tenía que ser capaz de reconstruir nuestra arquitectura paso a paso, entendiendo los detalles importantes de cada parte.

Lo que probé primero

En algún momento abrí Claude Code y empecé a construir el mío.

¿Cómo lo construí?

Arquitectura

Fig. 1 · Línea continua = el camino de construcción. Discontinua = el bucle de feedback.

Claude Code lee de tres fuentes y escribe todo lo que verifica en un único fichero, la base de hechos. El examen y todos los módulos se escriben a partir de ese fichero. El curso es HTML plano servido por un pequeño servidor en Python, que guarda mi progreso en SQLite. Antes de escribir cada tanda nueva de módulos, Claude lee esa base de datos y se centra en lo que fallé o adiviné.

La fuente de verdad

Antes de que existiera nada del curso, quería una fuente de información en la que pudiera confiar. Estos fueron los pasos:

1. Le pedí a Claude que sacara el estado actual de nuestro sistema. Configuré el CLI de az con un rol de Entra que solo puede leer y listar, y Claude escribió lo que encontró en ficheros Markdown (y JSON cuando hacía falta).
2. Le pedí que leyera todos nuestros ficheros de Terraform y los comparara con lo que acababa de encontrar. Todo lo que existe en Azure pero no en el código, o corre una versión distinta a la que dice el código, es drift.
3. Le pedí que lo organizara todo por temas: roles y permisos de Entra, redes, cómputo, datos, etc. Esos temas se convirtieron en los módulos.
4. No quería que Claude escribiera la teoría de memoria, así que para cada módulo le pedí que buscara las páginas oficiales de Microsoft Learn y del registro de Terraform. Quería estar lo más cerca posible de la fuente. El curso acaba enlazándolas unas 20 veces.

Con eso tenía los datos divididos en módulos, la teoría de cada uno y, al lado, el estado actual de nuestra nube.

Funcionalidades

• Un examen inicial de 28 preguntas tipo test. En cada respuesta también tenía que decir si estaba Seguro, No seguro o Adivinando. Quería que el curso se centrara en mis puntos débiles y en lo que adiviné, no solo en las respuestas incorrectas. Los resultados (vergonzosos) de este examen son la base de todo el curso.
• Cada módulo tiene cinco partes. Teoría: qué es esto en Azure y cómo funciona. Nuestra infraestructura: lo que tenemos de verdad, con los nombres reales y cómo se conectan las piezas. Mejoras: ¿nos falta algo según las buenas prácticas, hay drift en el Terraform? Después, Ejercicios y un Lab.
• Juegos para practicar: flashcards con repetición espaciada, preguntas tipo test, emparejar cada servicio con su función y ordenar los pasos de un proceso.
• Labs en los que lanzo yo mismo comandos de az de solo lectura, para acostumbrarme a depurar cosas rápido desde el portátil.
• Un checkpoint al final de cada módulo, 8 o 9 preguntas en las que necesitas un 80% para aprobar. Al aprobarlo, las flashcards de ese módulo entran en la práctica diaria.
• El chat del tutor en el lateral, que puedo plegar. Recibe la página actual como contexto.
• Memoria, que explico más abajo porque me costó dos intentos.

Stack y dependencias

Decisiones clave y trade-offs

Una vez tuve los resultados del examen, el siguiente problema era guardar el estado. Lo necesitaba en dos sitios.

Mi propio progreso (notas, flashcards, rachas) se guardaba al principio en el localStorage del navegador. Eso salió mal (lo cuento más abajo), así que lo pasé a SQLite a través de serve.py, con una copia por día. El progreso de Claude entre sesiones vive en un fichero PROGRESS.md: qué está construido, qué le pedí y qué dice la base de datos sobre mí. Con las dos cosas, Claude puede abrir la base de datos, ver lo que fallé y escribir los siguientes módulos en función de eso. Perdí la sencillez de un sitio puramente estático, pero sin esto el curso no se adaptaría a mí.

Para el tutor, no quería pagar una API key ni darle ningún poder. El chat llama al CLI de Claude Code, así que usa mi login normal. Recibe la base de hechos y mi progreso con el primer mensaje, el texto de la página con cada pregunta, y solo puede leer ficheros:

cmd = [CLAUDE_BIN, "-p", prompt, "--model", "sonnet",
       "--output-format", "stream-json", "--include-partial-messages"]
if session_id:
    cmd += ["--resume", session_id]
else:
    cmd += ["--system-prompt", tutor_system_prompt()]
# read-only tutor: Read/Grep/Glob stay available, nothing that mutates or leaves
cmd += ["--disallowedTools", "Bash", "Edit", "Write", "NotebookEdit",
        "WebSearch", "WebFetch", "Task"]

La pega es que solo funciona mientras serve.py está corriendo en mi máquina.

El papel de la IA en el build

No escribí nada del código. Lo que hice fue decidir cómo tenía que ser el curso, hacer el examen con honestidad y quejarme cuando algo no estaba bien.

• Fable 5 planificó los contenidos, los módulos y la estructura básica.
• Opus 5 lo construyó, en Claude Code.
• Sonnet 5 mueve el chat del tutor.

Skills y herramientas que usó:

Algo que pedí una y otra vez fueron pruebas. Cada afirmación sobre nuestra nube tenía que salir de las lecturas en vivo con az o del Terraform, y antes de escribir un módulo nuevo Claude volvía a comprobar los datos contra el tenant en vivo.

Demo

El curso es privado, porque básicamente es un mapa de nuestra nube de producción. El vídeo de arriba enseña el flujo completo. Estas son las partes que puedo enseñar:

Mi rutina son unos 10 minutos de flashcards y luego una parte de un módulo por sesión. Hago el checkpoint cuando siento que tengo el módulo controlado.

Qué salió mal

• En las primeras versiones, la respuesta correcta siempre era más descriptiva que las incorrectas. Podías aprobar eligiendo la opción más larga. Tuve que iterar unas cuantas veces hasta equilibrarlas.
• El chat de Sonnet es un poco demasiado verboso. Ayuda, pero a menudo vuelve a explicar cosas que ya sé, aunque su system prompt le pide respuestas cortas.
• Perdí la pista de mi progreso durante unos días. Había estado abriendo el curso desde file:// en un navegador que no era Chrome, así que todo se guardaba solo en ese navegador. Claude lo recuperó abriendo la página allí con el servidor encendido, lo que lo subió a la base de datos.
• Chrome se quedó con un cards.js antiguo en caché y la página de práctica se rompió hasta que hice un hard refresh. Claude lo arregló con una cabecera Cache-Control: no-cache en el servidor local.
• En un momento dado, la comprobación de permisos de Claude Code bloqueó algunas lecturas en vivo de Key Vault y de las VMs. Me frenó, pero sinceramente prefiero tener esa comprobación cerca de producción.
• La UI/UX no era la prioridad de este proyecto. Funciona, pero podría haberla mejorado un poco.

En cifras

Lecciones aprendidas

Preguntarme lo seguro que estaba me dijo más que la nota. Un 75% parecía estar bien. Ver que la mayoría era adivinar es lo que me dijo dónde centrarme.

Construí la fuente de verdad antes que el contenido, y lo volvería a hacer. Comparar el estado en vivo, el código y la documentación oficial sacó drift que no sabía que teníamos. Solo por eso ya mereció la pena.

Claude lo hizo mejor cuando podía ver mis resultados. No tuve que explicarle en qué era malo. Leyó la base de datos y escribió los siguientes módulos en función de eso.

Esto podría ser nuestro onboarding. Cualquiera que entre en el equipo necesita el mismo mapa que necesité yo, y este además te examina.

Replícalo

Este es el prompt del que partir. Pégalo en Claude Code (o en cualquier agente de programación) dentro de un repo que tenga el código de tu infraestructura, y adapta las primeras líneas a tu nube.

I just took ownership of our Azure infrastructure and I need to understand it well enough to rebuild it step by step. Build me a private, local course about OUR cloud, not generic Azure.

1. Ground truth first. Using a read-only `az` login, inventory the live tenant and write the findings to Markdown (JSON where useful). Then read all the Terraform in this repo and compare it to what is live: list the drift (resources not in code, versions that differ). For every concept, check the official Microsoft Learn and Terraform registry docs instead of relying on memory, and keep the links.
2. Split the estate into modules (e.g. foundations, Terraform, networking, compute, data and secrets, identity, edge/CI). Save everything verified as one fact base; every question and lesson must come from it.
3. Before writing lessons, give me a baseline exam: ~28 multiple-choice questions where I also tag each answer Sure / Not sure / Guessed. Make wrong answers as long and as specific as the right ones.
4. Each module has five parts: Theory, Our estate (exact names and how they connect), Improvements (best practice gaps and drift), Exercises, and a Lab of read-only `az` commands I run myself. End each module with a checkpoint (80% to pass).
5. Add practice: spaced-repetition flashcards, matching and ordering games.
6. Stack: static HTML + vanilla JS, a stdlib-only Python server on 127.0.0.1 that saves my progress to SQLite. Keep a PROGRESS.md with what's built and what I asked.
7. Add a collapsible tutor chat that knows the current page, using `claude -p` with read-only tools only.
8. Before each new batch of modules, read my results in the database and write the batch around what I got wrong or guessed.

Never run commands that change anything in the cloud. Show your evidence for every claim about our estate.