The lost reference

El 28 de octubre GitHub anunció la disponibilidad general de Copilot Fusion. En vez de escoger un modelo para cada tarea, eliges Fusion y el sistema decide qué modelos y patrones de ejecución utilizar. La documentación de GitHub describe opciones como resolver con un modelo, escalar una respuesta para que otro la revise o generar una respuesta y pedir a otro modelo que la critique.

El modelo sigue importando, pero cambia la pregunta. Durante estos últimos años hemos comparado nombres y versiones: ¿cuál razona mejor?, ¿cuál escribe mejor código?, ¿cuál tiene más contexto? Ahora aparece otra pregunta, más arquitectónica: ¿qué sistema decide cómo usar modelos, datos y herramientas para completar el trabajo?

En un artículo anterior sobre qué es un harness y dónde vive, expliqué por qué dos herramientas con el mismo modelo pueden comportarse de forma distinta. Aquí quiero dar un paso más: ¿qué cambia cuando el propio sistema empieza a elegir y combinar modelos?

Cuando comparamos herramientas de IA solemos empezar por el modelo. Que si este modelo razona mejor, que si aquel tiene más contexto, que si el nuevo benchmark lo coloca tres puntos por encima del anterior. Es lógico: el nombre del modelo es la parte visible, la que aparece en la documentación, en los selectores y, por supuesto, en el marketing.

Pero hay una pregunta que cada vez me parece más importante: cuando dos herramientas utilizan el mismo modelo y producen resultados muy diferentes, ¿qué estamos comparando realmente?

La respuesta corta es que no estamos usando solo un modelo. Estamos usando un sistema completo alrededor de él: instrucciones, contexto, memoria, herramientas, permisos, formatos de entrada y salida, bucles de validación, reintentos y condiciones de parada. A ese andamiaje se le suele llamar harness.

Y ese harness puede convertir un modelo competente en una herramienta muy útil o en un compañero que lleva veinte minutos leyendo archivos irrelevantes con una seguridad en sí mismo francamente admirable.

Cuando pienso en agentes, skills y subagentes, me viene Matrix a la cabeza. No porque Copilot vaya a desenchufarnos de una cápsula —eso espero—, sino porque la película nos dejó un mapa mental bastante útil: el Arquitecto, Neo, el código de Matrix y programas con objetivos propios.

Y ahora la pregunta práctica: si le pido a Copilot que revise la seguridad de una API, ¿qué debería crear: instrucciones, una skill, un agente o un subagente? La respuesta rápida es «depende». Voy a tirar de la analogía para aclararlo, con una salvedad: Matrix es una metáfora, no un diagrama de arquitectura literal.

El sábado 17 de octubre por la mañana nos reunimos en el Colegio Salesianos La Cuesta, en La Laguna, para una nueva edición de los GitHub Copilot Dev Days. El evento, organizado conjuntamente por TenerifeDev y Guarandinga Tech, empezó a las 9:30 y se alargó hasta las 13:30, con una agenda repleta de sesiones sobre desarrollo e inteligencia artificial.

A las 9:45, Emiliano Montesdeoca del Puerto, Team Lead en Intelequia, y yo compartimos la charla «GitHub Copilot: agentes, skills y subagentes». En la agenda aparecía con nuestros nombres y cargos: Santiago Porras Rodríguez, Software Architect en ENCAMINA, y Emiliano Montesdeoca del Puerto, Team Lead en Intelequia. El objetivo era poner un poco de orden entre conceptos que a menudo se mezclan y explicar qué diferencia hay entre escribir instrucciones, definir un agente, crear una skill o delegar una tarea en un subagente. No son cuatro maneras de llamar a lo mismo, ni hace falta usarlos todos a la vez.

Si usas Copilot, Claude Code o el asistente que toque en tu IDE, seguramente ya notaste dos cosas:

1. Vas mas rapido.
2. Si te confias, te estampas mas rapido.

Y no lo digo en plan “la IA nos va a quitar el trabajo”. Lo digo en plan ingenieria de trinchera: he visto codigo que en demo parecia impecable y en produccion abria puertas que nadie queria abrir.

Llevo unas semanas dándole vueltas al ritmo al que estamos desarrollando software desde que herramientas como GitHub Copilot, Claude Code y compañía se han sentado con nosotros en la mesa. Y sí, aceleran. A estas alturas negarlo sería como discutir que el fuego quema o que una daily mal llevada puede durar más que una migración de SharePoint.

Pero también me está quedando cada vez más claro que esa aceleración tiene trampa. La IA te ayuda a escribir código más rápido, sí, pero también puede empujarte a una especie de desconexión peligrosa: empiezas a aceptar cambios que “parecen bien”, confías en que lo que ha generado hace lo que crees que hace, y cuando quieres darte cuenta estás conduciendo un coche a toda velocidad sin tener realmente las manos en el volante.

Este artículo cierra una serie de tres. Los anteriores cubren qué es Spec Driven Development y qué es Context Engineering. Si llegas aquí sin leerlos, la comparación que sigue va a ser menos útil.

Si ya los has leído, la pregunta que probablemente tienes es: ¿cuándo uso uno, cuándo uso el otro, y qué pasa cuando los combino? Aquí va la respuesta.

Si llevas un tiempo trabajando con IA, seguramente habrás visto en algún README, en algún hilo de Twitter o en alguna charla de meetup el consejo universal: “dale más contexto a la IA”. Lo dice todo el mundo con esa convicción de quien ha descubierto el agua caliente.

Y sí, dar contexto ayuda. El problema es que “dar contexto” como gesto vago no es lo mismo que hacerlo bien. Y hacerlo bien tiene nombre, tiene disciplina, y ese nombre no es el que circula por ahí.