Una tarea de mi plugin de Moodle dejó de generar los justificantes de asistencia a examen: terminaba con un críptico "no se ha proporcionado ningún documento" y reintentaba sin parar. Lo curioso es que no fallaban todos, solo los alumnos nuevos. La universidad había cambiado de directorio sin avisarme y había dejado de dar de alta a los nuevos en el antiguo, que era justo al que mi código seguía preguntando (y que seguía respondiendo, por eso no saltaba ninguna alarma). Era fin de semana y no tenía las credenciales del directorio nuevo… hasta que caí en que Moodle ya tenía esa conexión configurada y funcionando. La lección va más allá de Moodle: cuando el sistema sobre el que trabajas ya tiene algo configurado, reutilízalo en vez de duplicarlo. Una sola fuente de verdad.

La semana pasada hablé de las herramientas con correa. Esta semana la correa ha tirado: un gobierno ordenó apagar el modelo de inteligencia artificial más potente jamás abierto al público y la empresa tuvo que desactivarlo para todo el mundo de un día para otro. Lo uso para una idea incómoda para quien construye encima de estas herramientas: dependes de algo que un tercero puede apagar cuando quiera. No te deja tirado del todo —puedes bajar a un modelo menos potente del mismo proveedor— pero el mejor desaparece sin avisar. Y no va de una empresa ni de un gobierno concretos: en Europa lo vivimos por el otro lado, con la nueva Siri que no llega por la regulación. Incluida una confesión: yo también llevo la correa.

Hoy se puede usar el modelo de inteligencia artificial más potente jamás abierto al público… pero domado. Uso ese lanzamiento como excusa para una idea más grande: cada vez trabajamos con herramientas más capaces de lo que sus propios creadores se atreven a soltar. Vienen con bozal (se niegan a hablar de ciertos temas), con vigilancia (te quitan la opción de pedir que no guarden nada) y al doble de precio. ¿Por qué tanta correa? Porque la herramienta, suelta, encuentra fallos de seguridad ella sola: muerde de verdad. Y esto no va de una marca concreta, va camino de ser el patrón. Una reflexión sobre el estado de la IA contado a través de cómo nos la entregan.

Durante años, una parte de mi plugin de Jitsi para Moodle hizo algo de lo que no me enorgullezco: en lugar de devolver datos, fabricaba páginas web enteras. El servidor escribía a mano, como una larguísima cadena de texto, el HTML y cientos de líneas de JavaScript. Este episodio va de la idea pequeña que lo cambió todo al refactorizarlo: el servidor debe entregar datos, no comportamiento. Te cuento cómo partí una función de 900 líneas en tres capas (datos, plantillas y módulos), qué destapó esa separación (un caché que tapaba una consulta que recorría la tabla de registros de todo el sistema, 21 veces más lenta de lo necesario; código muerto; una cápsula del tiempo de la app móvil) y, sobre todo, para qué sirve un trabajo que no se ve por fuera: es el cimiento exacto que el nuevo Moodle, el que va hacia interfaces reactivas con React, va a necesitar.

Llevo un tiempo sin sacar novedades en mi plugin de Jitsi para Moodle, y es a propósito: estoy pagando deuda técnica. Dos archivos enormes —uno de casi tres mil líneas— troceados en clases pequeñas, con los tests por delante. ¿Por qué ahora? Porque Moodle va a cambiar sus tripas (React entra en el núcleo con la 5.2, y los viejos callbacks dan paso a los hooks) y prefiero llegar preparado que a remolque. Por el camino, tres lecciones: los tests por delante encuentran bugs que no buscabas (aparecieron seis o siete, y hasta una "mina" que renombraba la actividad del profesor), desconfía de tus propios atajos de verificación, y "mover no es mejorar". Y una reflexión final sobre el trabajo invisible: ese que nadie aplaude, pero que decide si tu proyecto sigue vivo dentro de tres años.

Una batallita de sysadmin con dos incidencias encadenadas. Acto 1: lancé una actualización de macOS en mi Mac mini servidor y, al resetear la configuración de energía, el equipo se durmió toda la noche provocando caídas fantasma (y un revelador HTTP 000 que no era ningún hackeo). Acto 2: al día siguiente, la propia herramienta que me avisa de los problemas —el plugin de Telegram— se desbocó al 100% de CPU, con su mecanismo de autoprotección anulado justo por el fallo que debía resolver. Y un epílogo sobre cómo reportar bien un bug: el fallo ya estaba documentado, así que en vez de duplicar, aporté tres datos nuevos a un issue existente. Empieza con una disculpa por el volumen bajo de los dos episodios anteriores, ya corregido.

El 1 de junio entraron en vigor las nuevas tarifas de GitHub Copilot y, de un día para otro, los flujos agénticos cuestan entre diez y cincuenta veces más. Se acabó la barra libre de la IA. A raíz de un post de un amigo que fue jefe mío, reflexiono sobre por qué el agente en bucle no escala (ni técnica ni económicamente), qué significa orquestar de verdad —descomponer, rutear el contexto, elegir el modelo por fase, poner puertas de verificación—, los dos hábitos que ahora valen oro (documentación y verificación) y cómo Dynamic Workflows de Opus 4.8 coordina cientos de subagentes en paralelo. El futuro del coding asistido no es un agente más listo, es un buen director de orquesta.

Casi nadie disfruta documentando, pero la documentación no es un extra: es parte del producto, tan parte como el código. Lo descubrí cuando el README de mi plugin de Jitsi para Moodle superó las 600 líneas y dejó de servir. Por qué la evitamos (la maldición del conocimiento), por qué una herramienta brillante con mala documentación pierde frente a una mediocre con buena documentación, las cuatro necesidades que cubre una buena doc, por qué una doc desactualizada es peor que ninguna, y un giro muy de 2026: ahora la documentación también la leen los agentes de IA. Lo que publiqué hoy es solo un primer paso; vendrán guías paso a paso.

Cómo he cambiado mi forma de programar: ya casi no tecleo, dirijo a un agente. Tres carriles distintos: proyectos personales donde dirijo, plugins de Moodle en UDIMA donde co-programo, y desarrollo para Apple en Xcode donde la integración de Claude con SwiftUI, UIKit, Combine y el resto de frameworks es brutalmente buena. También lo que no me convence todavía: dependencia de un único proveedor, modelos que cambian cada pocos meses, y el riesgo de aceptar sin leer.

Qué son los agentes de IA, cómo funcionan por dentro, tipos (un solo objetivo, conversacional, multi-agente, workflows), cómo construirlos (APIs, frameworks como LangChain o CrewAI, plataformas no-code como n8n, y productos ya listos), por qué la velocidad importa más que la inteligencia en producción, y por dónde empezar si partes de cero.