Ya no explico mi didáctica. La escribí una sola vez.

Hace poco escribí una frase más corta que cualquier correo de aquella tarde: "Revísame los ejercicios del módulo de contabilidad."

Lo que volvió no fue una opinión. Fue una tabla. 26 ejercicios, cada uno puntuado según cinco criterios, los cuatro más flojos arriba, con el motivo por el que eran flojos.

Lo importante no es la velocidad. Lo importante es que aquella tarde no dediqué ni una palabra a explicar qué hace bueno a un ejercicio. Esos cinco criterios los había escrito meses antes, una sola vez. Desde entonces están ahí, y la IA va a buscarlos sola en cuanto una pregunta suena a eso.

Me preguntan a menudo qué tiene de especial mi sistema. La respuesta que se espera es una cifra: 18 servicios conectados, unas cuarenta skills, un servidor de Moodle con más de noventa herramientas. Pero la cifra no es la respuesta. La respuesta es un engranaje entre dos mitades que pasa desapercibido, porque por separado ninguna de las dos impresiona.

Dos mitades que por separado sirven de poco

Empecemos por los términos, breve y sin dar nada por supuesto.

MCP significa Model Context Protocol. Es una norma de enchufes. Una IA sabe hablar y escribir de fábrica, pero no puede tocar nada. Un servidor MCP es un programa pequeño que se pone delante de un sistema real, pongamos Moodle, y le ofrece a la IA una lista de maniobras: crear un curso, renombrar una sección, llenar un cuestionario de preguntas, leer las notas. En cuanto ese servidor está enchufado, la IA puede ejecutar esas maniobras en tu sistema real, con tus permisos reales. MCP le da manos.

Las skills son la otra mitad. Técnicamente, una skill es una carpeta con un archivo de texto dentro. Arriba del archivo hay dos líneas: un nombre y una descripción de cuándo aplica esa skill. Debajo, en lenguaje normal, está cómo se trabaja aquí. Qué criterios rigen. En qué orden. Qué separa un buen resultado de uno mediocre. Nada de código, nada de programar. La IA lee ese archivo solo cuando la descripción encaja con la tarea planteada. Una skill le da criterio.

La diferencia queda clara con una sola pregunta:

Construí las dos mitades una después de otra, y viví cada una por separado. Ambas decepcionaron.

Primero la mitad MCP. Sobre eso ya escribí, en 12 servidores, un protocolo. La sensación de teclear por primera vez "Crea un cuestionario sobre incumplimientos del contrato de compraventa" y encontrar treinta segundos después un cuestionario terminado fue enorme. Y me duró unas tres semanas. Entonces me di cuenta de que estaba produciendo muchísima mediocridad muy deprisa. Las preguntas eran correctas y aburridas. Los cursos eran completos y sin vida. Le había dado manos a una IA y había olvidado decirle qué considero yo un buen trabajo.

La mitad de las skills a solas es igual de insatisfactoria, solo que al revés. Una IA que conoce tu modelo de calidad pero no alcanza nada te entrega una recomendación excelentemente argumentada. Que luego ejecutas tú. El domingo por la tarde. A mano.

A la segunda vez, ya es una skill

La pregunta obvia: ¿cómo sé cuándo algo debe convertirse en una skill?

Mi umbral está más abajo de lo que la mayoría supone. Está en la segunda vez.

Cuando le explico lo mismo a una IA por segunda vez, eso ya no es casualidad, es un patrón. No lo explico dos veces porque el modelo sea olvidadizo, sino porque tengo una exigencia que a mí mismo me resulta tan evidente que nunca la he formulado. Justamente esas exigencias son las valiosas. Son la diferencia entre mi trabajo y un trabajo cualquiera.

La primera vez, explicar es normal. La segunda vez, explicar es un descuido que va acumulando intereses.

En la práctica significa: ya no escribo la explicación en el chat, sino en un archivo. La segunda vez eso cuesta unos cuatro minutos más que explicarlo. La tercera vez sale gratis. A partir de la cuarta es ganancia, y para siempre, porque el archivo no se cansa ni se va de vacaciones.

Y luego viene la parte que subestimé al principio: una skill no sirve de nada si no se encuentra. La IA no lee cuarenta archivos antes de responder. Lee las líneas de descripción y decide con ellas qué archivo llega a abrirse siquiera.

O sea: la descripción no es el envoltorio. Es la herramienta. Una skill excelente con una descripción vaga es un libro en una biblioteca sin catálogo. Por eso en mis descripciones están las palabras que uso de verdad cuando estoy cansado: "ficha de trabajo", "handout", "crear curso", "fin de sesión", "hemos terminado". No las palabras que aparecerían en una documentación.

Por qué solo el producto de ambas sostiene algo

Puedes imaginarte el asunto como cuatro campos, y los cuatro aparecen en el día a día.

Ninguno de los dos. Le describes tu problema a la IA, responde con inteligencia y después lo haces todo tú. Es el caso normal para la mayoría, y no es poco. Pero es asesoría, no trabajo.

Solo manos. La IA llega a todas partes y no sabe qué es bueno. Entonces produce muchísimo material muy rápido, material que pasa el trámite y no llega a nadie. Es la esquina más peligrosa, porque se siente como productividad. Ves el volumen y se te escapa que la calidad no creció con él.

Solo criterio. La IA conoce tu estándar y no puede aplicarlo en ninguna parte. El resultado es un buen plan. Ejecutarlo te toca a ti.

Ambos. Y aquí ocurre algo que no se siente como una suma. Como el criterio está depositado de forma permanente, cambia el carácter de mis instrucciones. Ya no digo qué hay que hacer. Digo qué quiero conseguir. De "Crea un cuestionario con ocho preguntas sobre incumplimientos del contrato de compraventa, dos de opción múltiple, con enunciados orientados a la acción, nada de preguntas de pura memoria" se pasa a "Móntame la entrada del módulo 3."

La frase se acortó. Pero no se volvió más imprecisa, porque la precisión se mudó. Ahora vive en archivos y no en mi memoria a corto plazo.

Ese es el rendimiento real, y no es un ahorro de tiempo. Es un desplazamiento: de instruir a decidir.

Cuatro rasgos de mi sistema

Aquí no describo mis skills. Te servirían de poco, porque contienen mis asignaturas, mi centro y mi identidad corporativa. Describo las cuatro ideas que hay detrás, porque esas sí se trasladan.

Una skill lleva un modelo, no una secuencia de pasos

La skill que aquella tarde puntuó los 26 ejercicios no contiene ninguna instrucción. Contiene un modelo con cinco criterios: ¿hay un ancla narrativa de la que cuelgue el ejercicio? ¿Hay algo que ver? ¿Qué profundidad tiene el pensamiento que se exige? ¿Qué hace realmente la alumna, aparte de leer? Y: ¿qué pasa cuando se equivoca, se castiga el error o se explica?

Cinco preguntas. Ningún procedimiento, ningún orden, ninguna indicación técnica.

La diferencia es mayor de lo que parece. Una secuencia de pasos envejece con la herramienta para la que se escribió. Un modelo sobrevive al cambio de herramienta, porque describe en qué se reconoce un buen trabajo y no qué botón se pulsa. Mi análisis de cursos trabaja con un modelo de cuatro competencias, mi revisión de ejercicios con esos cinco criterios, mis documentos escolares con la identidad corporativa del centro. En los tres casos escribí una convicción profesional, no un manual de uso.

Y aquí es donde el profesorado tiene una ventaja que desconoce. Esos modelos ya están en sus cabezas. Simplemente nunca han tenido un formato en el que pudieran transmitirse.

Medir y mejorar son dos herramientas separadas

Yo trabajo por parejas. Una skill que analiza secciones de curso y otra que las optimiza. Una que puntúa ejercicios y otra que los reelabora. Siempre dos, nunca una.

Es deliberado, y me costó llegar ahí. Una herramienta que mide y repara a la vez se mide con benevolencia. Tiene interés en el resultado. Encuentra los problemas que sabe resolver y pasa por alto de forma fiable aquellos para los que no tiene solución. Al final recibes un informe en el que todo se ve bien, porque todo lo malo se arregló calladamente por el camino y ya nadie sabe cómo de mal estaba antes.

Herramientas separadas obligan a una parada intermedia: veo la medición antes de que se cambie nada. Puedo objetar. A veces el ejercicio más flojo es justo el que mejor funciona en clase, porque tiene una historia que ningún criterio recoge. Esa decisión es mía, y solo es mía si veo los números antes de la intervención.

Una skill dirige, no interviene por sí misma

Mi skill más extensa construye situaciones de aprendizaje completas. Investiga fuentes, planifica la didáctica, genera material, comprueba su calidad y al final publica en varias plataformas. Lo que hace por sí misma es: nada de eso.

Describe un orden y entrega cada paso a las manos que saben hacerlo. La investigación a la vía de investigación, el material a la generación de medios, la publicación a la conexión con Moodle y al portal de módulos. La skill es directora de orquesta, no músico.

Suena a sutileza, pero es la razón de que la cosa lleve meses funcionando. Si cambia una conexión, cambia una conexión. El flujo sigue vigente. Si hubiera escrito la ejecución dentro de la skill, tendría que tocarla cada vez que cambiara cualquiera de los sistemas implicados.

El mismo alcance, identidades distintas

Esta es la parte de mi sistema que menos explico y que considero la más importante.

Mis conexiones no van directas a los servidores, sino a través de una capa intermedia delgada. Hace una sola cosa: decide con qué llave se trabaja, según el contexto en el que yo esté sentado en ese momento. El centro es un contexto. El blog es otro. La administración de servidores es un tercero. La asociación en la que colaboro es un cuarto y está estrictamente separada del centro.

El efecto es doble. Primero, después veo en un registro qué pasó en qué contexto. Segundo, y esta es la ganancia real, una sesión pensada para el blog no puede llegar por accidente a datos del alumnado. No porque yo sea disciplinado, sino porque la llave para eso no existe en esa sesión.

La misma lógica se aplica a la confusión más peligrosa de todas. Tengo dos instalaciones de Moodle: un campo de pruebas local y la real, con cursos reales y alumnado real. Se llaman distinto a propósito, y la regla está escrita: si no está claro cuál se quiere decir, se pregunta, no se adivina.

La forma de trabajar alrededor

Hasta aquí hemos hablado de herramientas. Pero lo que más ha cambiado en mi caso no son las herramientas, sino tres hábitos que las rodean. No cuestan nada y funcionan sin un solo servidor.

El primero: cada proyecto recibe una carpeta donde consta qué se hizo aquí y por qué. En mi caso son documentos de diseño fechados, planes de ejecución e informes sobre lo que salió al final. En el proyecto de infraestructura hay ya dieciséis de esos diseños.

El motivo no es el orden. El motivo es que una ventana de chat muere.

Una sesión de IA tiene una memoria que termina con ella. Todo lo que habéis elaborado juntos en tres horas, cada callejón sin salida, cada ponderación, cada motivo por el que al final os decidisteis por el segundo mejor camino, después ya no está. Si vuelves en seis semanas, tienes delante a alguien que ve tu proyecto por primera vez. Y tú tampoco recuerdas ya el motivo, solo la decisión.

Una carpeta de proyecto es la respuesta a eso, y tiene un destinatario en el que uno no piensa de inmediato: el siguiente agente. No escribo esos documentos para mí. Los escribo para que la siguiente sesión los lea y alcance en cinco minutos el estado que la vez anterior nos costó tres horas. Ese es justo el punto en el que unas cuantas buenas tardes sueltas se vuelven algo acumulativo. Mi trabajo no crece porque yo teclee más rápido, sino porque cada sesión se apoya en lo que dejó la anterior.

El segundo hábito: todo está bajo control de versiones. En mi caso es Git, replicado en GitHub, y vale igual para el código que para los materiales de clase, las skills y la documentación.

Esto suele venderse como un asunto de orden, y por eso casi nadie escucha. Pero no es un asunto de orden. Es la condición para poder trabajar con valentía.

El orden es este: primero la seguridad, después la libertad. Si dejo que una IA trabaje sin supervisión en cuarenta archivos a la vez es solo porque un único comando recupera el estado de hace un momento. Cada cambio es una propuesta, no una intervención. Sin ese billete de vuelta me volvería prudente, y la prudencia es exactamente lo que destruye esta forma de trabajar. Entonces solo pruebas aquello que ya te veías capaz de hacer, y esa es la barrera sobre la que escribí en Tres barreras que ya no existen.

Y hay algo que solo importa más tarde: el control de versiones hace que el trabajo sea heredable. En Lo reconstruí describí por qué las administraciones recelan de lo construido en casa, y la objeción es legítima. Un repositorio que alguien puede clonar y darle a leer a una IA es la mitad de la respuesta. Una carpeta en tu escritorio no es ninguna.

El tercer hábito es el más antipático: anoto lo que he medido, con fecha, y anoto también lo que resultó ser falso.

En mi documentación de proyecto hay frases como: "Medido el 16.08. en el sistema real, la nota anterior sobre esto no era reproducible." Parece burocracia. Pero es lo que con más fiabilidad me protege del trabajo duplicado. Una suposición refutada que no está escrita en ninguna parte vuelve. Vuelve garantizado, dentro de cuatro meses, cuando ya nadie recuerda que se comprobó una vez, y entonces se comprueba otra vez.

Con las sesiones de IA vale por partida doble, porque una IA te da la razón con gusto. Adoptará tu vieja suposición equivocada y construirá encima si es lo único que hay en tus notas y no hay nada al lado.

Por qué esto funciona mejor en los centros que en otros sitios

Ahora la parte que de verdad me importa.

Oigo a menudo que mi sistema es una excepción porque soy administrador y tengo servidores. Eso vale para la cifra. Para el núcleo no vale, y por un motivo que casi nunca aparece en el debate sobre la IA en la escuela.

El profesorado ya posee la mitad más difícil. No a medias, sino completa y con una profundidad que en otros sitios se compra cara. Un compañero que lleva quince años dando Lengua tiene un modelo interno completo de qué separa un buen enunciado de uno malo, dónde tuerce el rumbo una clase en ese punto, qué errores son productivos y cuáles solo frustran, cómo se plantea lo mismo para tres niveles distintos. Nunca lo ha escrito, porque nunca hubo destinatario. Se lo puedes contar a un profesor en prácticas, y ya está.

Ahora hay destinatario. Y el trabajo de traducción no consiste en programar, sino en una frase: escribe en lenguaje normal lo que le explicarías a alguien en prácticas.

La otra mitad, el alcance, también está ya en los centros, solo que sin que se note. Hay una plataforma de aprendizaje, un sistema de correo, listas de clase, un paquete ofimático, un sistema de archivo. Son exactamente los sistemas a los que se les pueden acoplar manos. El esfuerzo es real, pero es único y compartible. Y tampoco tiene que ir primero.

Aquí encaja el añadido honesto: el sistema mínimo razonable consta de cero servidores. Una sola skill, un archivo de texto con tu criterio de calidad, sin ninguna conexión, ya te da el efecto del primer apartado. Tus instrucciones se acortan, tus resultados ganan consistencia. Las manos puedes añadirlas años después, o nunca.

El precio honesto

Hay tres cosas que no funcionan, y en textos así se suelen callar.

Las skills se pudren. Una skill que apunta a una interfaz que ha cambiado es peor que ninguna skill, porque genera falsa confianza. Algunas de mis descripciones son ya más antiguas que los sistemas a los que se refieren. Eso cuesta tiempo de limpieza con regularidad, y en eso no soy bueno.

Demasiadas skills se anulan entre sí. Con unas cuarenta, ya solo decide la línea de descripción qué se encuentra. Dos skills con descripciones parecidas son peor que una, porque entonces se tira de la que por casualidad suena mejor. La colección necesita cuidados o se desmadra.

La velocidad no trae calidad consigo. Es la lección que más me ha costado. Tuve que construir la revisión de calidad de forma expresa, como herramienta propia, porque la rapidez por sí sola solo genera más material. Quien crea que los buenos resultados aparecen en cuanto desaparece la fricción producirá mediocridad silenciosa en gran cantidad.

Y la cuarta cosa, que no es un precio sino un límite: todo esto sigue colgando de una sola persona. Tengo herramientas, no una institución. Lo que construyo me sobrevive únicamente porque está versionado y documentado. Eso es mejor que nada y menos que un plan de sucesión.

El primer paso cuesta veinte minutos

Si esto te ha llegado y no sabes por dónde empezar: no por un servidor. No por una conexión. No por una lista de herramientas.

Empieza por el archivo.

Coge la única cosa que esta semana has explicado por segunda vez. Escribe en lenguaje normal en qué reconoces que está bien hecha. No cómo se hace, sino en qué se reconoce lo logrado. Escribe una línea sobre cuándo debe aplicarse, con las palabras que usas cuando estás cansado. Deja el archivo en una carpeta que tu IA lea.

Eso es todo. Veinte minutos, sin servidor, sin presupuesto, sin permiso.

Y cuando la vez siguiente a la próxima notes que ya no tienes que teclear esa explicación, habrás construido la mitad más difícil de conseguir. Las manos son técnica. El criterio eras tú.

Dirk Schulenburg, Hamburgo. Escribe las cosas para no tener que decirlas dos veces.

Sobre este texto: el guion, el primer borrador y los ejemplos de mi propio sistema surgieron en conversación con Claude. La tesis, la selección de las diez prácticas y la edición final son mías.