De Visual Studio a Copilot App: mi viaje hacia la orquestación

Durante mucho tiempo, para mí GitHub Copilot fue algo que vivía dentro del editor. Le pedía una sugerencia, la leía, la aceptaba o la descartaba, y seguía a lo mío. Todavía reviso código, eso no ha cambiado. Lo que ha cambiado es el momento en el que empieza la conversación: ahora empieza mucho antes, cuando me pregunto qué problema quiero resolver, qué límites no se pueden cruzar, dónde está el contexto y qué parte del trabajo se puede coordinar entre repositorios.

No llegué aquí de un salto. Pasé por Visual Studio Community, por VS Code, por la CLI y, al final, por GitHub Copilot App. Cada cambio de herramienta fue también un cambio en mi forma de confiar. Y en estas últimas semanas han llegado dos cosas que, sinceramente, me han descolocado para bien: Copilot Fusion y los Projects de Copilot App.

No quiero escribir una comparativa de editores ni prometer productividad a nadie. Quiero contar cómo he ido aprendiendo a trabajar con algo que cada vez hace más cosas y al que, justamente por eso, cada vez tengo que poner mejores límites.

Donde empezó todo: Visual Studio Community

Mi primer contacto con Copilot no fue en Visual Studio Code, sino en Visual Studio Community. Allí todo ocurría pegado al cursor: aparecía una sugerencia junto al código y yo decidía si tenía sentido quedármela. Me acompañaba mientras programaba, pero no se me pasaba por la cabeza que pudiera ser el centro de nada.

Al mirar esa etapa con la perspectiva de ahora, me entra cierta nostalgia por aquella relación tan directa con el código: una idea, el editor y la paciencia de ir dándole forma. No echo de menos todas las fricciones de entonces ni creo que fueran mejores por ser más lentas, pero sí me gusta recordar lo mucho que ha cambiado la manera en que compartimos ese proceso con una herramienta.

Me resultó útil desde el principio, y también vi enseguida sus límites. Hubo momentos en los que alucinaba: daba por hecho que existían cosas que no existían, o me proponía soluciones muy convincentes que no encajaban con el proyecto. Cuando reescribía archivos, a veces colaba errores. Ahí aprendí algo que no se me ha olvidado: que una respuesta suene fluida no significa que el cambio sea correcto.

Esa desconfianza no se fue nunca. Con el tiempo se convirtió en otra pregunta, bastante más útil: ¿qué tiene que saber y qué tiene que comprobar el asistente antes de tocar nada?

Cambiar de terreno: VS Code y después la CLI

Me fui a VS Code porque era donde veía que la experiencia avanzaba más rápido. Ya no se trataba solo de completar una línea: el contexto del proyecto, el chat y las capacidades de los agentes iban ganando peso. El editor seguía importando, pero yo empezaba a pensar en unidades de trabajo más grandes que el archivo que tenía abierto.

Luego di el paso a la CLI. Ahí el agente trabajaba junto a las mismas herramientas que uso yo para entender y validar un repositorio: leer archivos, buscar referencias, lanzar comandos y mirar qué pasa. Para mí la diferencia no estaba en que el modelo contestara mejor, sino en que podía preguntarle al entorno y contrastar parte de lo que proponía.

Es lo que llamo el harness, el arnés: no solo el modelo, sino todo lo que lo rodea y organiza el contexto, las herramientas, los permisos, las instrucciones y el ciclo de ejecución. Las herramientas de edición permiten cambios más acotados que reescribir un archivo entero; la integración con servidores de lenguaje mediante LSP puede aportar información sobre símbolos y diagnósticos; y MCP abre la puerta a conectar servicios externos. Qué hay disponible en cada caso depende del entorno y de cómo esté configurado.

Ver que aquel arnés creado por el equipo de GitHub ha evolucionado hasta convertirse en el Microsoft Copilot harness, extendiéndose más allá de GitHub Copilot, me hace mirar el camino de otra manera. Lo que para mí empezó junto al código se está convirtiendo en una base compartida para distintas experiencias con agentes y modelos. Y eso refuerza algo que he ido aprendiendo durante el viaje: el modelo importa, pero también importa el entorno que le permite actuar.

Nada de esto acaba con las alucinaciones ni garantiza que un cambio esté bien. Pero sí cambió cómo hablaba yo con el agente: ya no tenía por qué aceptar una suposición si había una herramienta para comprobarla. Para mí el salto no fue dejar de revisar. Fue tener más pruebas en la mano cuando revisaba.

Llegar a Copilot App

Copilot App fue la siguiente parada. Por primera vez podía tener a mano las sesiones de los agentes junto a los repositorios, las ramas, las issues y las pull requests con las que ya trabajaba. También podía llevar varias tareas en espacios separados y decidir cuánta autonomía dar a cada sesión. La sensación fue la de dejar de saltar entre piezas sueltas y empezar a ver el trabajo como un conjunto.

Con ella llegaron también los Git worktrees a mi día a día. Cada sesión puede trabajar en su propio directorio y en su propia rama mientras yo sigo en otro sitio, sin que se mezclen los cambios. Los worktrees comparten la información del repositorio Git pero mantienen separados los archivos de trabajo, así que puedo trabajar en paralelo sin clonar el repositorio entero para cada tarea. Si te interesa, lo cuento con más calma en mi artículo sobre Git worktrees y la fricción de contexto.

Eso sí, tengo claro que separar archivos no es una frontera de seguridad, ni resuelve por arte de magia los conflictos entre cambios. Sigo teniendo que revisar cada rama y ver cómo encajan las piezas cuando vuelven a juntarse.

El editor no ha dejado de importarme. Lo que ha cambiado es desde dónde organizo el trabajo: puedo plantear una tarea, seguir una sesión y revisar sus cambios sin que todo tenga que pasar por la pestaña del archivo que estoy editando.

Y aquí me di cuenta de algo: cuanta más autonomía le doy al agente, mejor tengo que explicar lo que quiero. Qué resultado busco, qué no puede romper y cuándo tiene que pararse. Por eso las skills y los límites arquitectónicos han acabado ocupando un sitio central en mi forma de trabajar.

Aprender a delegar sin perder el contexto

Skills: poner por escrito cómo trabajo

Una skill me permite guardar mi manera de abordar un tipo de tarea y reutilizarla sin tener que escribir las mismas instrucciones una y otra vez. La organizo en una carpeta con un archivo SKILL.md y, si hace falta, recursos o scripts. Copilot puede cargarla cuando la tarea y la descripción de la skill indican que viene al caso.

La distinción que a mí me sirve es esta: las instrucciones generales cuentan las reglas habituales de un repositorio; una skill reúne el procedimiento y el contexto de una tarea concreta. En vez de esperar que el agente adivine siempre cómo quiero trabajar, lo dejo escrito, de forma explícita y revisable.

Escribir una buena skill me cuesta más que hacer una lista de deseos. Intento pensar en qué debería activarla, qué información necesita, qué pasos importan de verdad y cómo se comprueba el resultado. Y procuro que no crezca demasiado: una instrucción enorme que quiere resolverlo todo acaba peleándose por el contexto con la tarea real.

No me engaño: las skills no son una barrera infalible. El agente puede malinterpretarlas, aplicarlas a medias o tirar de una versión desactualizada. Por eso las trato como una parte más del proyecto: hay que revisarlas, mantenerlas y comprobarlas, sobre todo si llevan scripts o vienen de terceros.

Guardrails: dejar libertad sin perder la arquitectura

La otra pieza son los architecture guardrails, los límites que dicen qué decisiones de arquitectura hay que respetar cuando cambia el código. Para mí no son una casilla mágica de la aplicación ni la garantía de que todo lo generado esté bien. Son una mezcla de instrucciones, convenciones y controles que se pueden verificar.

Una instrucción puede explicar qué dependencias se permiten entre capas, cuáles son las reglas de integración o dónde vive cada responsabilidad. Una prueba, un análisis estático o una política de revisión puede comprobar una parte de esas reglas. Se complementan: una instrucción orienta; una comprobación ejecutable detecta los incumplimientos que sabe medir.

Esa diferencia me importa mucho. Si solo le pido a un agente que respete la arquitectura, puede hacerlo de forma superficial. Si además concreto los límites y tengo pruebas que fallan cuando alguien los cruza, la red de seguridad es bastante más tangible. Ninguna prueba recoge toda la intención de un diseño, y ningún guardrail sustituye a una persona revisando los compromisos de rendimiento, seguridad y mantenimiento.

Puedo darle instrucciones al agente dentro del repositorio. Pero decidir qué restricciones merecen existir, cómo se aplican y cuándo hay que cambiarlas sigue siendo cosa nuestra.

Linear y Better Stack: el contexto que vive fuera del código

El código no lo cuenta todo sobre una tarea. En mi flujo también están Linear, para gestionar proyectos, y Better Stack, para seguir problemas. Acercarle ese contexto al agente me ahorra empezar cada conversación con una descripción desconectada del trabajo real.

Con Linear distingo entre la integración con GitHub y que una sesión local acceda directamente a Linear. La integración con Copilot permite iniciar y dirigir sesiones del agente en la nube desde una issue de Linear, usando su descripción y sus comentarios como contexto. Eso no significa que cualquier sesión de Copilot App pueda consultar por su cuenta todo el espacio de Linear: el acceso depende de la integración y de los permisos configurados.

Para Better Stack tiro de MCP. Su servidor permite conectar asistentes con información de incidentes y telemetría, entre otras cosas. Lo que se puede hacer en concreto depende de la autenticación y de las herramientas habilitadas; si la tarea solo es investigar, no hace falta dar permisos de escritura.

Estas conexiones me resultan útiles, pero también agrandan la superficie en la que tengo que confiar. Una issue, un registro o una respuesta externa pueden traer información incompleta o instrucciones que no deben tratarse como si mandaran. Por eso prefiero permisos mínimos, fijarme en qué datos entran en el contexto y revisar antes de cualquier acción con efectos fuera.

Modelos y costes: lo que he observado

A la vez que aprendo a delegar mejor, también ha cambiado lo que observo en el coste. He notado un salto importante en la eficiencia de tokens de los modelos de la familia GPT 6 y, sobre todo, de los 6.1, mientras la facturación de Copilot ha pasado de las premium requests a los GitHub AI Credits.

En las tareas que he ido observando, he pasado de ver costes de entre 5 y 20 dólares por resolución a cifras que suelen moverse entre 0,50 y 3 dólares. Hoy es raro que una tarea que resuelvo supere esa última cifra. Son observaciones mías, no una medición controlada ni una previsión para otras cuentas; tampoco puedo separar cuánto se debe al modelo, al arnés, al contexto, a la tarea o al cambio de facturación.

En la facturación por uso, el consumo depende del modelo y de los tokens de entrada, salida y caché; un AI Credit equivale a 0,01 dólares estadounidenses. Como los planes y las asignaciones varían, comparo periodos, tareas y planes, no solo nombres de modelos.

Lo que sí ha cambiado en mí es la sensación de que experimentar y repetir está al alcance de más tareas. Ese cambio de escala es una buena antesala para las dos funciones que más me han llamado la atención últimamente: una reorganiza cómo se eligen los modelos y la otra cómo se coordina el trabajo.

Fusion y Projects: decidir y coordinar juntos

Copilot Fusion: soltar el volante de los modelos

Durante buena parte de este camino, elegir el modelo era parte de cada tarea. Con Copilot Fusion lo que elijo ya no es un modelo concreto, sino un sistema que decide en tiempo de ejecución qué modelos y qué patrón de ejecución usar. Puede resolver una petición con un solo modelo, escalar una propuesta o recurrir a varios modelos para criticar una respuesta.

Los niveles que se pueden seleccionar tienen propósitos distintos:

• Fusion Standard busca un equilibrio entre coste, calidad y latencia y elige un modelo para cada tarea.
• Fusion High permite una orquestación más amplia para tareas sustanciales y bien acotadas, cuando las llamadas adicionales pueden compensar.
• Fusion Max prioriza la capacidad y un razonamiento más profundo, sin dejar de tener en cuenta la eficiencia.

En las últimas semanas, Copilot Fusion Standard se ha convertido en mi forma predeterminada de trabajar.

Que estén disponibles depende del plan y de los modelos habilitados. Existe también Fusion Fast para un caso concreto del chat en línea de VS Code, pero no es un nivel que pueda elegir en Copilot App.

Lo que me impactó no es que Fusion haga desaparecer las decisiones, sino que mueve una parte de ellas. Puedo dedicar más cabeza a definir el problema y el esfuerzo que necesito, y menos a decidir a mano qué modelo entra en cada paso. Eso no quita que High o Max puedan hacer llamadas adicionales y gastar más créditos: no equivalen a ahorrar de forma automática.

Hay otro matiz que no quiero pasar por alto: Fusion y los subagentes son cosas distintas. Fusion no lanza subagentes por sí mismo. Y, si descarta un borrador, los cambios que ese borrador ya haya hecho en el espacio de trabajo no se deshacen solos. Así que revisar el resultado y el diff sigue siendo imprescindible.

Projects: dejar de pensar en encargos sueltos

Si Fusion cambió cómo pienso en los modelos, Projects cambió cómo pienso en el alcance del trabajo. Ahora puedo partir de una meta y mantener alrededor de ella las sesiones, los resultados y el seguimiento, en vez de perder el hilo entre encargos independientes. El trabajo puede cruzar varios repositorios, quedarse en uno solo o no necesitar ninguno; también puedo organizar tareas recurrentes. Projects sigue en public preview, así que tengo presente que la experiencia puede cambiar.

Para mí la diferencia está entre pedir un cambio aislado y no perder el hilo de un objetivo más grande. En lugar de tratar cada sesión como una conversación sin relación con las demás, puedo ordenar el trabajo alrededor de una intención común y seguir sus resultados. Cuando hay varios repositorios de por medio, esa coordinación vale todavía más, porque el problema que quiero resolver no siempre coincide con los límites de un único repositorio.

Eso no quiere decir que la aplicación conozca por sí sola todas las dependencias ni que pueda fusionar cambios sin criterio. Cada sesión necesita un alcance que se entienda, contexto suficiente y una forma de comprobar su resultado. Cuando unas piezas dependen de otras, sigo teniendo que decidir el orden, revisar los contratos entre repositorios y verificar el conjunto. Un montón de cambios correctos por separado no garantiza que la integración lo sea.

Fusion y Projects han sido mis dos grandes revelaciones de estas semanas precisamente porque actúan en niveles distintos: Fusion organiza el uso de modelos dentro de una petición; Projects ayuda a coordinar el trabajo hacia una meta. Si los confundiera, me perdería justo lo que más me interesa de tenerlos juntos.

GitHub como punto de encuentro y control remoto

Hay otra pieza que redondea esta forma de trabajar: poder tener GitHub como punto de encuentro de repositorios, issues, pull requests y sesiones, sin estar siempre sentado delante de la máquina. En las sesiones de Copilot CLI en las que se habilita el control remoto, puedo seguir el progreso y responder a preguntas o solicitudes de permisos desde GitHub.com o GitHub Mobile.

Aquí me gusta ser preciso: el control remoto no convierte una sesión local en una sesión que se ejecuta en la nube. El trabajo sigue corriendo en la máquina local; la web o el móvil son otra ventana para seguirlo y dirigirlo. Tampoco doy por hecho que todas las sesiones de Copilot App tengan exactamente las mismas opciones: depende de la superficie y de la configuración. Lo que yo valoro es poder mantener el hilo cerca de GitHub sin confundir dónde lo miro con dónde se ejecuta.

Mirar más allá de un único proveedor

Cuando el trabajo ya se organiza alrededor de proyectos y agentes, la pregunta que me hago es dónde conviene ejecutar cada parte. En la CLI puedo conectar directamente las API de proveedores como OpenAI o Anthropic, usar un enrutador como OpenRouter o apuntar a un endpoint compatible que sirva modelos locales con Ollama o vLLM, en mi equipo o en infraestructura propia on-premise. Es una flexibilidad concreta de ese flujo, no una promesa de que cualquier proveedor esté disponible en todas las superficies de Copilot: el modelo tiene que poder seguir el ciclo del agente, incluidas las llamadas a herramientas y las respuestas en streaming. Y si el endpoint está fuera de mi equipo, mis datos tampoco se quedan en local.

Me hace ilusión que esta conversación también la esté construyendo alguien cercano: QDivZero, la plataforma de mi amigo José Carlos García, permite consumir modelos por una API compatible con OpenAI y desplegar modelos propios sobre infraestructura GPU dedicada. Su oferta distingue entre modelos públicos facturados por tokens y despliegues dedicados cuyo coste depende del tiempo que permanecen activos. Me gusta ver cómo iniciativas así abren más caminos para elegir qué modelo usar y dónde ejecutarlo.

Ahí es donde los modelos de pesos abiertos me parecen especialmente interesantes. Si un equipo puede alquilar cómputo y pagar por el tiempo de uso, en vez de cada token, cambia la forma de hacer las cuentas. Pero no desaparecen los costes: una GPU ociosa también cuesta, y hay que sumar utilización, operación, latencia, mantenimiento y la calidad del modelo para la tarea. No creo que el pago por tiempo sea siempre mejor; sí creo que tener ambas alternativas va a importar mucho.

Y aparece una posibilidad que hace poco me habría parecido lejana: mover parte de la inferencia al dispositivo y dejar que el agente combine recursos locales y de nube. Me parece importante que esa idea ya haya empezado a materializarse en una vista previa experimental para Copilot: se puede dejar que Fusion enrute entre determinados modelos locales y de nube, o elegir un modelo local compatible. No es lo mismo que decir que el agente está desconectado; inferencia, herramientas y acceso a la red son fronteras distintas.

También me llaman la atención los nuevos Surface RTX Spark Dev Box y Surface Laptop Ultra, anunciados con hasta 128 GB de memoria unificada. No significa que los 128 GB estén libres para cargar pesos: el sistema, las aplicaciones y el contexto del modelo también consumen memoria. Pero sí cambia lo que me puedo imaginar haciendo en local. HydraFusion empezó como un proyecto experimental para orquestar varios modelos y Copilot Fusion recoge esa línea de trabajo; la selección entre modelos locales y de nube es un paso nuevo, también experimental. No confundo ambas cosas: me interesa ver cómo esa orquestación puede extenderse al lugar donde se ejecuta la inferencia.

Mi impresión es que los modelos siguen ganando capacidad y haciendo un uso cada vez más eficaz de los tokens. No veo, hoy, una señal clara de que esa trayectoria vaya a detenerse pronto. Si sigue así, el lugar donde ejecutamos la inferencia, quién lo opera y cómo se factura pueden convertirse en decisiones tan importantes como el modelo que elegimos.

De vuelta al punto de partida

Cuando miro hacia atrás, no veo una línea recta desde una herramienta imperfecta hasta otra que ya no necesita que nadie la vigile. Veo cómo ha ido creciendo el alcance: de la sugerencia junto al cursor a un sistema que consulta herramientas, sigue procedimientos, trabaja en sesiones y coordina objetivos más amplios.

Y mi papel también ha cambiado. Tengo que explicar mejor el problema, mantener vivas las skills, definir los límites de la arquitectura, controlar los permisos y revisar las pruebas. Que todo vaya más rápido no hace desaparecer las preguntas difíciles: qué comportamiento queremos, qué compromisos aceptamos y cómo sabemos que el resultado es correcto.

Hay algo emocionante y un poco extraño en ese cambio. La ingeniería de software que conocía no ha desaparecido: sigue estando en las decisiones, en los fallos que hay que entender y en el cuidado con el que revisamos lo que construimos. Lo que cambia es cuánto del camino hacemos escribiendo cada línea y cuánto dedicamos a orientar y comprobar el trabajo de otros, incluidos los agentes.

Cuando intento ponerle una escala temporal a todo esto, me cuesta creer cuánto ha cabido en menos de dos años. Claude Code apareció en febrero de 2025; el agente Codex en la nube llegó en mayo y la CLI de Codex había aparecido un mes antes. Desde entonces, el trabajo con agentes ha pasado de ser una posibilidad llamativa a una manera real de organizar tareas de ingeniería. Pero la historia no empezó entonces: GitHub Copilot se presentó en 2021 como una colaboración con OpenAI, impulsada por Codex, un modelo de OpenAI al que GitHub aportó conocimiento durante su desarrollo. El Codex de 2021 era un modelo, no el agente Codex que OpenAI lanzó en 2025; compartir nombre no los convierte en el mismo producto. Me parece más justo decir que el equipo de GitHub estuvo entre quienes vieron nacer esta etapa y ayudaron a darle forma, no que entrenara por sí solo aquel modelo.

Por eso Fusion y Projects me han tocado tanto. No porque hagan la ingeniería por mí, sino porque me resulta más natural organizar el trabajo alrededor de ella. También por eso me interesa la posibilidad de elegir entre inferencia en la nube y en local, entre modelos alojados por terceros y modelos que puedo operar de otra manera. Todo empezó para mí con un copiloto que completaba código. En menos de dos años, la manera de trabajar con software se ha transformado a una velocidad que todavía me cuesta asimilar; mi trabajo consiste cada vez más en darle contexto, criterio y un camino que podamos comprobar juntos.