GitHub abre el capó de Copilot en VS Code: por qué el harness importa más que la guerra de modelos

Cada vez que sale un modelo nuevo, la conversación se va al mismo sitio: quién razona mejor, quién se equivoca menos, quién tiene más contexto. El problema es que un agente de coding no vive solo del modelo.

El propio equipo de Visual Studio Code lo explicó sin rodeos el 15 de mayo de 2026 al publicar cómo funciona el coding harness detrás de Copilot. La tesis del post es simple y bastante útil: lo que de verdad experimenta el developer no es el modelo aislado, sino la capa que arma contexto, expone tools, ejecuta acciones y evalúa el loop.

Qué es el harness y por qué debería importarte

La definición oficial es mejor de lo que suele circular en marketing. VS Code describe el harness como la capa que:

• arma el prompt con sistema, contexto, historial y memoria;
• decide qué herramientas puede tocar el agente;
• ejecuta esas tools;
• y devuelve el resultado para que el loop continúe.

Eso cambia bastante la forma correcta de evaluar agentes. Si el modelo “piensa bien” pero el harness le da contexto pobre, tools mal descritas o un loop torpe, el resultado final también será mediocre.

Por eso el post insiste en tres responsabilidades:

1. context assembly;
2. tool exposure;
3. tool execution.

No son detalles internos. Son exactamente las piezas donde suelen nacer muchos fallos que luego la gente atribuye al modelo.

La pista más útil para builders

La mejor línea del post no está en una feature nueva, sino en el cambió de criterio. VS Code lo plantea casi como una corrección de enfoque: preguntar “qué modelo es mejor” se parece a preguntar qué motor es mejor sin mirar el carro.

Eso le pega directo a cómo muchos equipos están comprando herramientas hoy. Si eliges agente solo por benchmark o por fama del modelo, te puedes comer tres problemas:

• mala selección de contexto;
• herramientas demasiado crudas o demasiado numerosas;
• y loops que no corrigen bien después de un fallo.

En cambió, cuando miras el harness, la discusión se vuelve más concreta:

• ¿qué ve el agente antes de actuar?;
• ¿qué tools se activan y en qué condiciones?;
• ¿cómo se validan argumentos, errores y resultados?;
• ¿y qué evals sostienen el comportamiento cuando cambias modelo?

Dónde sí cambia decisiones reales

1. En agentes con muchas tools

El post recuerda que tools como read_file, apply_patch, run_in_terminal o semantic_search no viven solas. El harness decide cuándo se muestran, cómo se describen y cómo se ejecutan.

Eso importa más que parece. Un catálogo amplio sin criterio puede romper contexto o inducir llamadas malas. Un catálogo más pequeño pero mejor descrito suele dar mejores resultados.

2. En sesiones largas

Cuando el trabajo se estira, el modelo depende todavía más de que el harness mantenga coherencia: historial, resultados intermedios, memoria y herramientas activas. Si esa capa falla, la sesión se vuelve cara y errática aunque el frontier model sea bueno.

3. En evaluación continua

VS Code conecta el harness con la parte menos glamorosa y más sería del producto: cómo lo evalúan cuando cambian modelos y workflows. Esa disciplina es la diferencia entre una demo que luce bien y un agente que no se degrada en producción.

Demanda actual sin inventar volumen

Aquí la demanda se ve por intención, no por una cifra inventada. Hay búsquedas cualificadas alrededor de:

• copilot harness
• agent loop vscode
• tools vs model coding agent
• how vscode agents work

Además, el propio ecosistema se está moviendo en esa dirección: más agentes, más MCP, más sesiones remotas y más trabajo multiagente. En ese contexto, entender el harness deja de ser curiosidad de producto y se vuelve criterio de compra.

Mi lectura práctica

Yo usaría esta nota para corregir una mala pregunta muy extendida. Si hoy estás comparando Copilot, Claude, Codex u otros agentes, no preguntes solo “qué modelo es mejor”. Pregunta también:

1. qué contexto arma la herramienta;
2. cómo expone y limita sus tools;
3. cómo ejecuta y valida cambios;
4. y cómo evalúa regresiones cuando cambia el stack.

Si todavía estás en la fase más básica de instalar, instruir y revisar a un agente, empieza por el curso gratis. Y si te interesa ver cómo esa lógica baja a una experiencia concreta con varios proveedores encima del mismo editor, sigue con VS Code y los agentes de terceros.

La conclusión útil no es abstracta: en coding agents, el modelo importa mucho, pero el harness decide si ese modelo trabaja como herramienta sería o como demo cara.