Cómo reviso mis clases con Claude Code

Claude Code no me hace las clases. Revisa cada una con unas reglas que escribí antes de que generara una sola diapositiva, y se para al final de cada fase hasta que le digo que sí.

Este curso doy dos asignaturas en UNIR: IA aplicada a sectores productivos y una nueva de programación y algoritmia. Las clases son online y los perfiles son de todos los colores: sobre todo ADE, Económicas y Derecho, pero también magisterio e ingeniería. La mayoría ejecuta las celdas de un cuaderno; no las escribe. Desde el 7 de septiembre de 2026, víspera de la primera sesión del curso, todas las clases que he preparado siguen las mismas reglas: siete sesiones de una asignatura y la primera de la otra. Cuento cómo funciona y qué regla me salté una y otra vez.

Primero, las reglas

Todo empieza en un CLAUDE.md, el fichero que Claude Code lee al arrancar cada sesión. El mío tiene nueve reglas fijas:

1. Techo de teoría: 15 o 25 minutos por sesión de dos horas, según la asignatura.
2. Si nombro una herramienta, se abre en pantalla ese día; si no, no sale en las diapositivas.
3. Cada alumno se va con algo hecho por él: un dashboard, un gráfico, una predicción, un workflow que funciona.
4. Los 120 minutos cuadran. Se suman los bloques y, si no dan, se dice.
5. Sígueme en pantalla: entornos preparados, un checkpoint cada 15 o 20 minutos y una versión simplificada por si el grupo va lento.
6. Se dice en voz alta: un prototipo no es producción.
7. No se inventan datos. Una cifra o se puede verificar o va marcada.
8. Datos reales, o sintéticos calibrados con referencias reales y avisando de que lo son.
9. Markdown, nunca .pptx, salvo que lo pida.

Encima de todas, esta frase:

Estas reglas prevalecen sobre cualquier otra consideración, incluida una petición mía en caliente. Si te pido algo que las rompe, avísame antes de hacerlo.

Cada asignatura añade su fichero encima. El de la nueva suspende la regla 2, porque una introducción a la programación nombra lenguajes que nunca abre.

La regla 7 viene con marcas: lo inferido lleva una amarilla; lo que no tiene fuente, una roja y un «pendiente de confirmar», nunca un dato verosímil.

Cuatro fases, un sí cada vez

Primero, Claude Code lee el material de partida, los .pptx y .pdf pasados a Markdown, nunca de memoria. Después vienen cuatro fases, y no pasa a la siguiente hasta que apruebo la anterior. El fichero explica por qué: me ahorra descartar contenido ya escrito.

Fase	Fichero	Qué apruebo
1. Diagnóstico	00-diagnostico.md	Qué se salva, qué se recorta, qué se sustituye y mis preguntas abiertas. Todavía sin contenido
2. Esqueleto	01-esqueleto.md	Objetivo, entregable del alumno, bloques que suman 120 minutos, herramientas, dataset y qué se corta primero
3. Producción	02-guion.md, 03-handson.md	Diapositiva a diapositiva, qué se ve y qué digo. La práctica paso a paso
4. Auditoría	04-checklist.md	El test de calidad y lo que tengo que tener listo y probado antes de clase

El primer diagnóstico es del 7 de septiembre. Mi propia presentación de abril, de la que partía, tenía 61 diapositivas y unos 118 minutos de material: el reloj cuadraba. Lo que lo llenaba, no: unos 45 minutos de teoría, nueve herramientas nombradas y dos abiertas como mucho, nada que hicieran los alumnos y nueve cifras sin fuente. El esqueleto volvió una vez con mis correcciones (nada de parejas: las clases son online), y la versión 2 las recoge en una tabla.

Cómo es un test de calidad para una clase

Antes de entregarme una sesión, Claude Code contesta por escrito nueve preguntas. ¿La teoría respeta el techo? ¿Se usa una herramienta en pantalla? ¿Cada alumno hace algo? ¿Se nombra alguna herramienta que no se usa? ¿Se repite algo de una asignatura anterior? ¿Los bloques suman 120? ¿Hay un checkpoint cada 15 o 20 minutos? ¿Hay versión simplificada y colchón de tiempo? ¿Está marcado todo dato que no se puede verificar? Si falla una casilla, lo dice antes de entregar, sin justificar por qué la sesión vale igual.

La regla que me salté una y otra vez

El test marcó la teoría en todas las sesiones de la asignatura de sectores. En seis de las siete fue de entre 44 y 64 minutos, con un techo de 25. Lo dijo por escrito cada vez, y cada vez seguí adelante. Dos de esas decisiones se notaron.

En la sesión 1 aprobé 44 minutos de teoría, 26 de ellos de actualidad, en una presentación de más de 90 diapositivas, cuando las reglas ponen el rango sano para dos horas entre 30 y 40. El debate de la actualidad se comió la clase. El tema del sector pasó a la sesión 2 y la práctica, a autoestudio. Desde entonces la actualidad tiene regla propia: de 8 a 10 minutos, con reloj en pantalla.

En la sesión 3 volví a aprobar media hora de actualidad. Las notas de Claude Code de esa versión dejaban escrito qué se caería por el final: la demo de montar un workflow de Make por MCP. Se cayó, y el RAG pasó a la sesión siguiente.

El test no decide por mí. Me enseña el precio antes de pagarlo.

¿Por qué me la seguí saltando? Porque el techo a veces es demasiado estricto y había cosas especialmente interesantes e importantes que contar. Porque depende muchísimo del grupo: la edición anterior exigía ver herramientas, y esta valoraba muchísimo más la teoría y los casos de negocio. Y porque con los MCP aterrizar en una herramienta nueva es muchísimo más fácil: pasar de un 0 % a un 30 % como usuario es rápido, así que importa más saber para qué sirve una herramienta que aprender a usarla a bajo nivel.

Las presentaciones y los cuadernos salen de código

La regla 9 dice Markdown, nunca .pptx. El checklist de la sesión 1 todavía me encargaba montar el PowerPoint, con una estimación de «el grueso de la noche». Esa misma noche la carpeta ya tenía un script que lo generaba, y desde entonces cada sesión tiene el suyo.

Es python-pptx: clonar diapositivas que ya se ven bien en la plantilla de la universidad y cambiarles el texto, para conservar tema, fuentes y logo. La mía de abril tenía notas del presentador en 15 de sus 61 diapositivas. La final tenía 92, todas con notas.

Parte de la gracia de hacerlo en Python es triple: iterar sobre lo que dieron de sí las sesiones de años anteriores, revisar de forma automatizada cualquier dato que pueda estar mal o haber cambiado y, lo más importante, actualizar los materiales, sobre todo a las últimas novedades y cambios del sector.

Las cosas se rompieron, y cada rotura acabó en una comprobación. La «reparación» de PowerPoint borró las notas de 25 diapositivas, todo el bloque de actualidad, justo lo que no me sabía de memoria. En la diapositiva de cierre, el enlace impreso y el QR apuntaban a dos formularios distintos, y ninguno era el bueno. Ahora unos scripts detectan notas compartidas entre diapositivas, texto que se sale del área útil en el PDF y párrafos que han perdido el texto, y los QR se decodifican del fichero.

En la asignatura nueva, cada sesión tiene una sola fuente: un fichero de Python con el texto de cada diapositiva, las notas y lo que voy a decir. Al ejecutarlo comprueba los límites de caracteres y que los minutos suman 60. El script que genera la presentación escribe también el guion, que no se toca a mano, así que no pueden divergir. El código de las diapositivas sale del generador del cuaderno.

El cuaderno tampoco se edita a mano. Un verificador ejecuta todas las celdas, con exec y otra vez con IPython, y compara cada salida carácter a carácter con lo que prometen los checkpoints. Comprueba hasta las cifras que digo en voz alta: preguntando siempre por el del medio, del 1 al 100 se acierta en 7 preguntas como mucho, y del 1 al millón, en 20. Última ejecución, 29 de septiembre: 75 comprobaciones, 0 fallos.

No inventar datos, en la práctica

Para la sesión de logística, el material de partida traía 27 «ejemplos reales» de empresas que usan IA. Se buscó una fuente primaria para cada uno. Diez se sostenían tal cual, siete a medias, dos estaban mal atribuidos, siete no tenían rastro y una de las empresas no existe. Los que fallaban seguían un patrón: empresa real, algoritmo que suena técnico y beneficio genérico.

Convertí la comprobación en una diapositiva, porque preguntarse dónde lo dice la empresa es el hábito que quiero que se lleven. Acabó oculta para dejar sitio a la práctica. Eso también es una regla.

Con qué me quedo

Tres semanas después, me quedo con esto. Las reglas, antes que el contenido. Ninguna fase sin mi sí. Presentaciones y cuadernos que salen de código y comprueba un script. Y cada excepción, por escrito y con su motivo, antes de la clase.

Claude Code sigue sin hacerme las clases. Decido yo qué es una buena clase, y sigo saltándome mis propias reglas. La diferencia es que ahora lo hago a propósito y por escrito.