Hacer una ficha interactiva a partir de un PDF tiene dos partes. Una
es decidir qué se pregunta. La otra es colocar los campos: abrir el
documento, dibujar una caja encima de cada línea de puntos, ajustar el
tamaño, escribir la solución, repetirlo veinte veces y descubrir al
final que un campo tapa el enunciado siguiente.
Desde la versión 1.29, OpenWorksheets puede hacer
ese trabajo por nosotros. No con un botón dentro de la aplicación, sino
desde la conversación con la inteligencia artificial que ya usemos: se
le dice dónde está el PDF y ella lo abre, lee la página, coloca los
campos donde tocan, mira cómo ha quedado y guarda la
ficha lista para abrir en el editor. Y no solo convertir: si no partimos de ningún documento, podemos pedirle la ficha entera sobre un tema, y la escribe sobre hojas en blanco.
«Convierte en ficha interactiva de OpenWorksheets este PDF:
energia.pdf»
Este artículo explica qué es lo que hace posible eso (un servidor
MCP), qué se le puede pedir, qué hace falta para instalarlo y, sobre
todo, dónde están sus límites, que los tiene.
Pódcast del artículo realizado por Gemini Notebook
Qué es un servidor MCP
Una IA de las de conversar sabe redactar preguntas, pero no puede
abrir un archivo de nuestro disco ni escribir uno. Vive dentro de su
ventana de chat. El MCP (Model Context
Protocol, «protocolo de contexto del modelo») es el estándar que le
da manos: un programa pequeño que se instala en el ordenador y le ofrece
a la IA una lista de operaciones concretas que puede ejecutar.
El servidor MCP de OpenWorksheets ofrece las operaciones propias para
fabricar una ficha: abrir un PDF, leer el texto de una página
con las coordenadas de cada línea, colocar campos de
respuesta, tapar una zona, ver el resultado y guardar el paquete
.owpkg. La IA decide qué preguntar y dónde ponerlo; el
servidor hace el trabajo material y le dice cuándo se está
equivocando.
Que sea un programa local tiene una consecuencia práctica: el
archivo no se sube a ningún servicio. El PDF se abre en nuestro
ordenador, las páginas se dibujan ahí y la ficha se guarda ahí, sin
pasar por ninguna web de conversión.
Conviene no confundir eso con privacidad total, porque no lo es. La
IA con la que hablamos sí ve el contenido: para colocar
los campos necesita el texto de las páginas, y para comprobar el
resultado necesita mirar la imagen de la ficha. Ambas cosas viajan a los
servidores de quien preste el servicio (Anthropic, OpenAI, Google,
etc.), igual que si pegásemos el documento en el chat. Con datos
personales del alumnado, o con material que no deba salir del centro,
hay que tenerlo presente. La única forma de que no salga nada es usar un
modelo que corra en el propio ordenador, con LM Studio, aunque de
momento lo usa muy poca gente, sobre todo porque necesita de un
ordenador muy potente para poder funcionar de forma fluida.
Formas de hacer una ficha
Sobre un documento propio. Es el caso para el que
nació. Partimos de un PDF o de una imagen (un examen antiguo, una ficha
fotocopiada, un esquema) y los campos se colocan encima, cada uno en su
sitio, respetando el diseño original. El alumnado ve el documento de
siempre, pero relleno de huecos que podrá completar y que se corrigen
solos.
Desde cero, sobre hojas en blanco. Le decimos el tema, el nivel y cuántos ejercicios, y la ficha se escribe entera: enunciado, campo de respuesta, separación y salto de página cuando hace falta. Es lo mismo que ya permitía la opción Crear una ficha con IA de la aplicación, la de copiar un prompt y pegar la respuesta, pero sin copiar ni pegar nada y con una diferencia importante: el servidor valida el formato sobre la marcha, así que si algo viene mal, la IA se entera al momento y lo corrige, en lugar de entregarnos un archivo que no abre.
Las dos formas se mezclan: se puede partir de un PDF y añadir al
final tres preguntas nuevas sobre hoja en blanco.
La vista previa es lo que lo hace fiable
Una IA colocando cajas sobre una página, a ciegas, se puede equivocar. Si pone el campo dos centímetros por debajo de donde iba, tapa media palabra del enunciado, deja a la vista la solución impresa en el margen. Por eso el paso importante no es colocar, sino comprobar: el servidor monta la página con el mismo visor que verá el alumnado y le devuelve a la IA una captura de cómo ha quedado, con el contorno y el número de cada campo dibujados encima. Con esa imagen delante, la IA corrige lo que esté desplazado antes de guardar nada.
Lo que ve la IA después de colocar los campos: la ficha real
montada con el visor del alumnado, con el contorno y el número de cada
campo añadidos encima. Esta ficha se ha hecho para el artículo con el
propio servidor, a partir de un PDF de una hoja.
Qué se le puede pedir
Todo en lenguaje normal, en la conversación, sin tocar la
aplicación:
«Convierte en ficha interactiva de OpenWorksheets este
PDF»
«Crea una ficha interactiva de OpenWorksheets con 10 ejercicios
y nivel de 1.º de ESO sobre la célula»
«El ejercicio 5 prefiero que lo cambies por una pregunta de
respuesta múltiple, en lugar de verdadero o falso»
«Tapa las soluciones que están impresas al pie de la
página»
«Enséñame la página 3 antes de guardar»
Los tipos de campo que sabe colocar son casi todos: respuesta corta,
numérica, fórmula, respuesta larga, opción única y múltiple,
desplegable, verdadero/falso, huecos en el texto, huecos dibujados sobre
el documento, casillas, tabla editable, emparejar, ordenar, arrastrar a
zonas y grabación de voz.
Qué hace falta
1. Una IA instalada en el ordenador. Esto no se puede hacer desde la web de ChatGPT, de Claude ni de Gemini: el navegador no puede instalar ni ejecutar nada en nuestro equipo. Hacen falta las aplicaciones de escritorio o herramientas de terminal como Claude Code o Codex CLI. Y en las aplicaciones de escritorio de ChatGPT y de Claude no vale el chat de siempre: hay que pedírselo desde su pestaña de código (Codex en ChatGPT, Claude Code en Claude), que es la parte que puede trabajar con archivos y programas. También sirven LM Studio, Antigravity, Cursor y VS Code.
2. Node.js 18 o superior y un navegador basado en
Chromium (Chrome, Chromium o Edge). Node es lo que ejecuta el
servidor; el navegador, que trabaja sin abrirse ni verse, es lo que
dibuja las páginas del PDF y monta la vista previa. Es probable que ya
estén instalados; si falta alguno, la propia IA puede
encargarse de instalarlo o guiarnos en el proceso.
3. El servidor, instalado una sola vez. Hay que
destacar que no lo instalamos nosotros, lo instala la
IA. En el editor de OpenWorksheets, en Archivo → Crear o
convertir fichas con IA (MCP), hay un prompt para copiar y pegarle
en su chat. Ella descarga la carpeta, la registra en su propia
configuración y comprueba que responde. Claude Code, Codex CLI, la
aplicación de escritorio de ChatGPT, Antigravity, Cursor y VS Code lo
pueden hacer; LM Studio no puede tocar su configuración, así que al
final nos dará escrito el texto que hay que pegar y nos dirá en qué
archivo va. Aunque si tenemos alguna de las IA anteriores, le podemos
decir que nos lo instale en LM Studio.
El diálogo del editor con las instrucciones que se le pegan a la
IA para que instale el servidor.
Para actualizarlo, hacemos lo mismo, escribimos en el chat: «Actualiza el servidor MCP de OpenWorksheets a la última versión y dime en cuál se ha quedado».
Límites que conviene conocer antes de empezar
Un PDF escaneado da mucho más trabajo. Si la página
es una fotografía, sin capa de texto, no hay coordenadas que leer y la
IA tiene que colocar los campos mirando la imagen y afinando por
aproximación. Sale, pero cuesta varias vueltas. Con un PDF generado
desde un procesador de textos, en cambio, es más sencillo.
Las respuestas las propone la IA. En preguntas
cerradas suele acertar; en las abiertas, y en cualquier cosa que dependa
de un criterio nuestro, hay que revisar la ficha antes de repartirla. La
ficha se abre en el editor como cualquier otra y podremos corregir lo
que haga falta.
No sustituye al editor, lo alimenta. Lo que devuelve
la IA es un .owpkg normal, que se abre en OpenWorksheets,
se retoca, se le puede modificar la puntuación y las opciones de
corrección, y se comparte como siempre.
Para qué sirve esto realmente
El cuello de botella de las fichas interactivas nunca ha sido la
falta de material: el profesorado tiene carpetas llenas de PDF buenos.
El cuello de botella es el rato de trabajo mecánico que separa ese PDF
del material interactivo, y que hace que muchos no lleguen a dar el
paso. Eso es exactamente lo que esto quita de en medio.
Con la ventaja de que no cambia el resto: la ficha resultante es una ficha de OpenWorksheets como cualquier otra, sin cuentas, sin servidores, sin depender de ninguna plataforma.
La misma ficha sin las marcas de trabajo: así la abre el
alumnado. El documento original se conserva intacto; los campos se
corrigen solos.
Los boletines de los grupos de Telegram ChatGPT-IA-edu y Vibe Coding
Educativo se publican desde 2023 y, por primera vez, su creación se ha
automatizado por completo. Una simple instrucción pone en marcha un
agente de IA que se encarga absolutamente de todo, desde la creación y
publicación hasta la difusión en redes sociales. Le he pedido a Claude
Code Opus 5 que escriba el artículo que hay a continuación. Utiliza sus
propias palabras y forma de ver todo el asunto, incluyendo sus menciones
a mi persona. Únicamente le indiqué el público docente al que va
encaminado el artículo y le he hecho algunas correcciones, tanto de
contenido como de estilo (cosa que él explica perfectamente más
abajo).
Juan José de Haro
Hacer el boletín semanal de dos comunidades educativas era una tarea
de tarde entera. Hoy el boletín está hecho y publicado en media hora —y
difundido en redes en un cuarto de hora más—, y lo ejecuta entero un
agente de IA.
La palabra importa, y merece una aclaración temprana. Un
asistente responde: le preguntas algo y te contesta. Un
agente actúa: recibe un encargo y lo lleva a cabo por
su cuenta, ejecutando programas, entrando en servicios, comprobando
resultados y corrigiendo el rumbo cuando algo falla. La diferencia no es
de inteligencia, sino de permisos y de autonomía: al agente no se le
pregunta, se le encarga.
Conviene decirlo desde el principio, porque es lo que suele
malinterpretarse: todos los pasos que vienen a continuación los
ejecuta el agente, incluidas las decisiones de redacción y las
comprobaciones intermedias. Juan José de Haro, que coordina las dos
comunidades, no ejecuta ninguno de ellos.
Lo que sí hace es lo que ninguna máquina puede hacer por él:
encarga, revisa, valida y, cuando algo no está a la altura, lo
manda repetir. La última palabra es suya, y la ejerce. Este
mismo artículo pasó por varias correcciones suyas antes de llegar aquí:
un dato mal atribuido, un cierre que se leía como una enmienda al propio
trabajo, unos diagramas con la letra demasiado pequeña para la columna
del blog. Nada de eso lo detectó el agente que los produjo.
Esa es la división real del trabajo: la ejecución es automática de
principio a fin; el criterio sobre si el resultado vale, no.
De qué estamos hablando
Cada semana, dos grupos de Telegram —ChatGPT-IA-edu y Vibe Coding Educativo—
generan cientos de mensajes: enlaces, dudas, hallazgos, debates,
aplicaciones que alguien ha creado y comparte. Es material valioso, pero
se pierde: quien no entra un par de días ya no lo recupera.
El boletín semanal existe para rescatarlo. Y no es solo un texto. De
cada semana y de cada grupo salen:
un boletín escrito, publicado en una web
consultable;
una infografía que resume visualmente la
semana;
un pódcast de quince o veinte minutos, en formato
conversación;
un vídeo de unos seis minutos, publicado en
YouTube;
y la difusión de todo ello en Telegram, X y
LinkedIn.
Todo está abierto y se puede consultar sin cuenta ni permiso:
Seis archivos multimedia, dos boletines, dos vídeos publicados y una
veintena de mensajes en redes. Cada semana. Hecho a mano, eso son
horas.
Todo el recorrido, de un vistazo. Lo importante es la
bifurcación: después de exportar, hay dos caminos que no se
estorban.
La idea de
fondo: una skill, que es una receta escrita
Lo primero que hay que entender es que la automatización no empezó
por programar, sino por escribir. Todo el proceso está
documentado en un único archivo que actúa como receta: qué se hace, en
qué orden, qué puede fallar y qué decisiones no se pueden tomar a la
ligera.
Ese archivo tiene nombre propio en el mundo de los agentes de IA: es
una skill. Conviene explicarlo porque el término se va
a oír cada vez más.
Una skill («habilidad», aunque casi nadie la
traduce) es un documento escrito en lenguaje corriente que le enseña a
un agente de IA a hacer una tarea concreta de la forma en que tú quieres
que se haga. No es un programa: es un texto, con sus instrucciones, sus
advertencias y sus ejemplos. El agente lo lee cuando toca hacer esa
tarea, y actúa en consecuencia.
La comparación que mejor funciona es la del profesorado sustituto. Si
dejas escrito «segunda hora, 3.º B, seguid por la página 84; a Marcos
hay que sentarlo delante; el proyector solo va con el cable HDMI de la
derecha», quien llegue podrá dar la clase decentemente aunque no conozca
al grupo. Una skill es eso mismo: el conocimiento acumulado de hacer
algo muchas veces, puesto por escrito para que otro pueda ejecutarlo sin
haber estado allí. La del boletín pasa de las setecientas líneas, y buena
parte son cosas que solo se aprenden fallando: que hay que acotar el
resumen a la semana o saldrá el histórico entero, o que la transcripción
confunde los nombres propios.
Como está escrita en lenguaje corriente y no en código, no
está atada a un agente concreto: puede seguirla cualquiera de
los que hoy existen —Claude Code, Codex, Antigravity CLI (Agy CLI)—, y
de hecho el boletín no siempre lo hace el mismo. De ahí la consecuencia
práctica que conviene tener presente al montar algo así: lo valioso, lo
que cuesta construir y no debe perderse, es el documento. El agente es
intercambiable.
De esa skill cuelgan una serie de pequeños programas —los llamamos
scripts— que son simplemente listas de órdenes que el ordenador
ejecuta solo. Nada exótico: es el equivalente informático de una macro
de hoja de cálculo, pero capaz de hablar con Telegram, con Google o con
YouTube. La skill es el guion; los scripts son las manos.
Cómo transcurre una semana
1. Recoger la conversación y poner a
trabajar a Gemini Notebook
Un programa se conecta a los dos grupos de Telegram y descarga todos
los mensajes de la semana pasada, de lunes a domingo. Con ellos monta
dos cosas: un archivo de datos que servirá para redactar, y un
PDF con la conversación ordenada y legible. Tarda dos o
tres segundos por grupo.
Con ese PDF entra en juego la pieza que más sorprende a quien no la
conoce.
Gemini Notebook —el nombre actual de lo que hasta hace
poco se llamaba NotebookLM— es la herramienta de Google que lee
documentos y produce resúmenes, esquemas, audios y vídeos a partir de
ellos. Lo habitual es usarla desde su página web (notebooklm.google.com),
subiendo archivos a mano.
En este proceso se le habla directamente, sin abrir el navegador: se
le sube el PDF de la semana y se le encargan de golpe las seis piezas
—infografía, pódcast y vídeo para cada grupo— con instrucciones que
están guardadas y son siempre las mismas. Eso garantiza que el boletín
de esta semana se parezca al de la anterior y al de dentro de tres
meses.
Un detalle que costó aprender: cada cuaderno de Gemini Notebook
acumula una fuente por semana desde 2025. Si no se le
dice explícitamente «resume esta semana», resume el histórico
entero y produce un material que no sirve para nada. Es el tipo de error
que no da ningún mensaje de fallo: simplemente sale mal.
Estas generaciones tardan entre veinticinco y treinta y cinco
minutos. Y aquí está el truco que ahorra media hora: se lanzan
antes de escribir nada. Mientras Google genera, el agente
redacta.
La barra amarilla es espera pura. El ahorro no está en hacer las
cosas más rápido, sino en colocarlas dentro de un hueco que ya
existía.
2. Redactar el
boletín (aquí el agente decide)
Con los mensajes de la semana delante, el agente redacta cada boletín
siguiendo una guía de estilo propia para cada comunidad —tienen tonos
distintos— y tomando como referencia boletines reales ya publicados. No
es un resumen mecánico: selecciona qué merece contarse, agrupa temas,
redacta un cuerpo de al menos seiscientas palabras, prepara un apartado
de preguntas frecuentes y extrae las palabras clave.
Este es uno de los dos puntos del proceso donde hay juicio de verdad,
no ejecución.
3. Publicar la fila en
la hoja de cálculo
Los boletines viven en una hoja de cálculo de Google, que es lo que
alimenta las webs públicas donde se consultan: chatgpt-ia-edu.github.io/boletin
y vibe-coding-educativo.github.io/boletin.
Cada boletín tiene además una dirección propia, con el año y la semana,
para poder enlazar uno concreto:
Un programa escribe cada boletín en su hoja, y lo hace con tres
precauciones que conviene destacar porque son las que evitan
desastres:
comprueba justo antes de escribir si esa semana ya
está publicada, para no duplicarla;
escribe en la primera fila libre, sin tocar nada más;
y después vuelve a leer lo que ha escrito y lo
compara campo a campo con lo que debía escribir. Si algo no cuadra, se
detiene y avisa.
Esa última comprobación es la diferencia entre automatizar y confiar.
Un proceso automático que no verifica su propio resultado es un proceso
que falla en silencio.
4. Recoger las seis piezas
Cuando Gemini Notebook termina, otro programa descarga los seis
archivos, les pone nombres consistentes y convierte los
audios. Aquí hay un detalle práctico: Gemini Notebook entrega
el pódcast en un formato innecesariamente pesado para voz
hablada, así que se reconvierte a uno más ligero y queda en la cuarta
parte de su tamaño, sin pérdida audible. Importa para quien lo escuche desde el
móvil con datos.
5. Los
vídeos a YouTube (y el segundo punto donde decide)
Antes de subir un vídeo hay que describirlo. Y para describirlo hay
que saber qué dice. El proceso lo transcribe automáticamente en
el propio ordenador, sin enviar nada a ningún servicio
externo.
Ahora bien: la transcripción automática se equivoca con los nombres
propios y con el vocabulario técnico. En las pruebas apareció «Resulen»
por resumen, «bargas de agua» por marcas de agua y «a
Yafgos» por hallazgos. Por eso la skill obliga a un paso más:
el agente relee la transcripción entera, corrige lo que está mal
escrito y comprueba que el texto tiene sentido antes de resumir
nada. Solo después redacta la descripción del vídeo.
Es una revisión de verdad, no un trámite: si la transcripción dice
algo incoherente, corregirlo exige entender de qué se estaba hablando
esa semana.
Y una advertencia que parece obvia y no lo es: la descripción debe
resumir el vídeo, no el PDF de conversaciones. El vídeo
dura seis minutos y cubre una parte de los temas de la semana. Resumir
el PDF produce descripciones que prometen contenidos que el vídeo no
tiene.
Hecho eso, la subida es automática: publica, añade el vídeo a su
lista de reproducción y escribe la dirección resultante en la hoja de
cálculo. Cada comunidad tiene la suya, y ahí están todas las semanas
seguidas:
Los audios se alojan en Internet Archive, la
biblioteca digital sin ánimo de lucro. Es una decisión deliberada: un
enlace estable, gratuito y que no depende de que una empresa decida
cerrar el servicio. Hay una colección por comunidad y por año, con todos
los pódcast juntos:
También aquí hubo que aprender algo: Internet Archive acepta el
archivo al instante pero tarda uno o dos minutos en indexarlo. Durante
ese rato el enlace no funciona, y parece un error sin serlo. El programa
espera a que el archivo esté realmente disponible antes de anotar la
dirección. Si no lo estuviera, no la escribe: prefiere dejar la casilla
vacía a dejar un enlace roto.
Cada pieza se aloja donde mejor se conserva y donde mejor se
encuentra. La fila de la hoja de cálculo es la que mantiene unido todo
lo demás.
7. La difusión en redes
La última fase publica en Telegram, X y LinkedIn. Es la fase que se
trata con más respeto, porque es la única que no se puede
ensayar: cualquier ejecución es visible al instante para toda
la comunidad.
Por eso existe un comando previo que lo revisa todo —los archivos,
sus formatos, sus duraciones, los textos, los enlaces— y muestra una
vista previa sin publicar nada. La IA lo ejecuta y lee
el resultado siempre, sin excepción, antes de tocar nada público.
Telegram y X se publican con sus respectivas conexiones automáticas.
LinkedIn es otra historia, y es la parte más curiosa de todo el
proceso.
LinkedIn no ofrece una puerta de entrada para programas como esta, y
tampoco vale el atajo habitual —copiar las credenciales de la sesión a
un navegador automatizado—, porque puede invalidar la sesión. Así que la
solución fue otra: el agente usa el navegador que ya está
abierto en el ordenador, exactamente como lo usaría una
persona. Trae al frente la ventana de Firefox, teclea la
dirección, pulsa el botón Vídeo, elige el archivo, pega el
texto y publica. Mueve el ratón y el teclado igual que tú.
¿Y cómo sabe si el clic ha funcionado? Haciendo una captura
de pantalla después de cada paso y mirándola. Esa es toda la
verificación que hay: mira si el diálogo se abrió, si el texto es el
correcto, si el aviso de Procesando ya desapareció. Si algo no
está donde debía, se detiene en lugar de seguir haciendo clics a
ciegas.
Es un método poco elegante y frágil —un rediseño de LinkedIn lo
rompe—, pero resuelve un problema real: cuando un servicio no ofrece
forma de automatizarlo, queda la de usarlo como lo usa una persona.
Lo que tarda cada cosa
Estos tiempos no son estimaciones: cada fase deja una marca
al empezar y otra al terminar, y un comando las suma al acabar.
Son de una semana normal, con los dos grupos.
Paso
Tiempo
Exportar la semana de un grupo de Telegram
2-3 segundos
Que Gemini Notebook indexe el PDF
30 s a 2 min
Generar una infografía
unos 3 min
Generar un pódcast
13-16 min
Generar un vídeo
18-24 min
Redactar un boletín
ocurre dentro de la espera anterior
Publicar una fila en la hoja
2-3 segundos
Convertir un audio a MP3 ligero
3-5 segundos
Transcribir un vídeo
1-2 min
Subir un vídeo a YouTube
5-10 segundos
Subir un audio a Internet Archive
10 s, más 1-2 min de indexado
Publicar en Telegram
1-2 min
Publicar en X
3-5 min
Publicar en LinkedIn
5-10 min
Hasta tenerlo todo publicado
25-35 min
Con la difusión en redes incluida
40-50 min
Dos cosas llaman la atención en esa lista. La primera, que lo
que tarda no es el trabajo, sino la espera: generar el vídeo y
el pódcast se lleva la mitad del tiempo, y ahí no hay nada que hacer
salvo aprovecharlo. La segunda, que publicar en LinkedIn a mano
cuesta más que todo el proceso de creación, y es justo la parte
que ningún programa puede acortar.
De la redacción no hay cronómetro: es lo único que no ejecuta un
script, y sucede mientras Google genera, así que no añade tiempo al
total.
Qué he aprendido de todo
esto
La automatización no elimina el criterio, lo
reparte. Dentro del proceso hay dos momentos que exigen pensar
—decidir qué merece contarse de la semana y comprobar que lo transcrito
tiene sentido—, y esos los ejerce el agente. Pero por encima queda un
tercero que no se delega: decidir si el resultado vale.
Ese sigue siendo de quien firma la publicación, y es el que corrige las
cosas que el agente no puede ver desde dentro. Lo que ha desaparecido es
el trabajo mecánico que rodeaba a todos ellos: descargar, renombrar,
convertir, pegar, subir, verificar.
Lo que no se verifica, falla en silencio. Cada paso
comprueba su propio resultado, porque un proceso que publica sin mirar
acaba publicando basura durante semanas sin que nadie se entere.
Ha llegado a ocurrir: una de las seis generaciones se encargó
correctamente, pero su identificador no llegó a quedar anotado en la
lista de encargos pendientes. La descarga
terminó con cinco piezas de seis, informó de que todo había ido bien y
no dio ningún error. Lo delató contar los archivos. El proceso ya
comprueba que eso no vuelva a pasar, pero la lección es la de siempre:
un programa solo detecta los fallos que alguien previó.
Pero hay errores que ninguna comprobación automática
detecta. Un resumen de la semana equivocada pasa todos los
controles técnicos con sobresaliente: el archivo existe, pesa lo que
debe y el enlace funciona. Todo perfecto salvo lo único que importaba,
que es el contenido. Por eso la revisión final es de otra naturaleza
—abrir la infografía y leerla, escuchar un fragmento del audio— y por
eso la hace también una persona: quien produce algo tiende a darlo por
bueno, y la mirada que puede decir «esto no vale, hazlo otra vez» tiene
que venir de fuera.
Para quien esté
pensando en algo parecido
No hace falta empezar por aquí. Este sistema funciona porque se
construyó en el orden correcto: primero haciendo el boletín a mano,
hasta entender bien cada paso; después escribiendo esa experiencia como
skill; y solo entonces automatizando lo que ya se hacía siempre
igual.
Y la parte más aprovechable no es la más técnica. Escribir la skill
—dejar por escrito, con precisión, cómo se hace algo que ya sabes hacer—
es una tarea docente de toda la vida, y sirve para cualquier rutina que
se repita cada curso: preparar las actas, montar los grupos, redactar
los informes trimestrales. Ese documento vale por sí solo, aunque nunca
llegue a automatizarse nada.
El resultado, al final, no es un ahorro de tiempo. Es que cada semana
de conversación de dos comunidades docentes queda recogida, resumida,
escuchable y consultable, en vez de perderse en el desplazamiento
infinito de un grupo de Telegram. Eso antes no se hacía porque no había
tiempo material para hacerlo. Ahora se hace todas las semanas.
Artículo redactado por Claude (Anthropic) bajo
la guía de Juan José de Haro. El sistema que aquí se
describe —los scripts, la skill que lo documenta y las soluciones a los
problemas que fueron surgiendo— se construyó entre los dos: él
decidiendo qué debía hacer el proceso, probándolo, señalando lo que
fallaba y exigiendo que se rehiciera cuando hacía falta; el agente
escribiendo el código, la documentación y este texto. Otros agentes
ejecutan el proceso algunas semanas, y alguno ha revisado puntualmente
este trabajo.
Sería insensato, y contradictorio en sí mismo, pensar que es posible hacer lo que hasta ahora nunca se ha hecho por procedimientos que no sean totalmente nuevos.
Comentarios recientes