Durante los últimos dieciocho meses hablamos mucho de modelos, contexto, memoria, MCPs, workflows y agentes. Pero hay una pregunta mucho más simple que casi siempre quedó escondida debajo de la conversación:
¿Dónde corre realmente el agente?
Porque una cosa es pedirle a un modelo que sugiera código. Otra muy distinta es darle permiso para ejecutar comandos, modificar archivos, correr tests, abrir pull requests o interactuar con infraestructura.
La diferencia entre ambas cosas es exactamente la diferencia entre un asistente y un operador.
Y es ahí donde aparece la novedad más importante de GitHub esta semana: sandboxes locales y cloud para Copilot.
No es una feature glamorosa. No mejora benchmarks. No agrega millones de tokens de contexto.
Pero probablemente sea una de las piezas más importantes que aparecieron en el ecosistema agentic este año.
El problema nunca fue el modelo
Los modelos ya son suficientemente buenos para muchas tareas de ingeniería.
Pueden:
- Escribir código
- Refactorizar módulos
- Generar tests
- Revisar PRs
- Investigar bugs
- Proponer arquitecturas
El cuello de botella dejó de ser la capacidad intelectual.
El problema pasó a ser operacional.
Porque cuando un agente necesita trabajar sobre un repositorio real aparecen preguntas incómodas:
- ¿Puede acceder a toda la máquina?
- ¿Puede ejecutar cualquier comando?
- ¿Tiene acceso a secretos?
- ¿Puede abrir conexiones externas?
- ¿Puede modificar archivos fuera del proyecto?
- ¿Qué pasa si entra en un loop?
- ¿Qué pasa si ejecuta algo destructivo?
La mayoría de las organizaciones resolvió esto de una forma bastante básica:
No dejando que el agente haga demasiado.
Y eso limita enormemente el valor que pueden generar.
La paradoja de los agentes
Todos queremos agentes más autónomos.
Pero nadie quiere entregarles acceso irrestricto.
Cuanto más poder tiene un agente:
- Más útil es.
- Más riesgo introduce.
Y esa tensión se vuelve peor a medida que los modelos mejoran.
Un agente capaz de modificar cien archivos también es un agente capaz de romper cien archivos.
Un agente capaz de desplegar una aplicación también es un agente capaz de desplegar algo incorrecto.
La industria llevaba meses chocando contra este límite.
No necesitábamos modelos más inteligentes.
Necesitábamos entornos más seguros.
Qué resuelve realmente un sandbox
La palabra “sandbox” suena aburrida.
Pero es una de las ideas más poderosas de toda la ingeniería de software.
La premisa es simple:
El agente puede hacer cosas reales, pero dentro de límites definidos.
En lugar de ejecutar directamente sobre tu laptop o sobre infraestructura crítica, el agente trabaja dentro de un entorno aislado.
Ese entorno puede controlar:
- Sistema de archivos
- Acceso a red
- Variables de entorno
- Credenciales
- Herramientas disponibles
- Tiempo de ejecución
- Consumo de recursos
En otras palabras:
el sandbox separa autonomía de privilegios.
Y eso cambia completamente la ecuación.
El salto de copiloto a operador
Hasta ahora gran parte de los workflows de IA funcionaban así:
- El agente propone.
- El humano revisa.
- El humano ejecuta.
Con un sandbox bien diseñado aparece otro modelo:
- El agente propone.
- El agente ejecuta.
- El humano valida resultados.
Parece una diferencia pequeña.
No lo es.
Es el paso que convierte a la IA de herramienta asistiva a herramienta operativa.
Por qué esto importa para los equipos
La mayoría de los equipos no tiene problemas generando código.
Tiene problemas ejecutando trabajo repetitivo.
Auditorías de dependencias
Un agente podría:
- Crear un entorno aislado
- Actualizar paquetes
- Correr la suite completa
- Detectar regresiones
- Generar un PR
Todo sin tocar tu máquina.
Expansión de cobertura
Un agente podría:
- Analizar áreas sin tests
- Generar cobertura incremental
- Ejecutar validaciones
- Abrir cambios listos para review
Sin acceso a secretos ni a sistemas productivos.
Refactors grandes
Los refactors son candidatos perfectos para agentes:
- Mucho trabajo mecánico
- Poco valor creativo
- Alto volumen de cambios
Pero también son peligrosos.
Un sandbox permite correr ese trabajo en un entorno descartable y validar el resultado antes de fusionarlo.
El verdadero paralelo con Claude Code
Lo interesante es que GitHub no está inventando un problema nuevo.
Está llegando al mismo lugar donde otras herramientas agentic ya venían empujando.
Cuando Anthropic introdujo:
- Worktrees aislados
- Subagentes
- Agent View
- Dynamic Workflows
el objetivo no era únicamente coordinación.
Era permitir que múltiples agentes trabajaran sin pisarse entre sí.
La diferencia es que GitHub está llevando esa idea más cerca del modelo operativo enterprise:
- Sandboxes
- Políticas
- Gobernanza
- Control centralizado
Dos enfoques distintos para resolver el mismo problema:
cómo dejar trabajar a los agentes sin perder el control.
Lo que viene después
Creo que estamos entrando en una nueva etapa del mercado.
La conversación durante 2024 y buena parte de 2025 fue:
¿Qué modelo es mejor?
La conversación de 2026 empieza a ser otra:
¿Qué runtime es mejor?
Porque una vez que los modelos alcanzan cierto nivel de capacidad, el diferencial ya no está solamente en la inteligencia.
Está en:
- Observabilidad
- Aislamiento
- Gobernanza
- Memoria
- Herramientas
- Orquestación
- Seguridad
En otras palabras:
infraestructura para agentes.
Y los sandboxes son una pieza central de esa infraestructura.
El takeaway
La historia de esta semana no es que GitHub agregó una feature nueva a Copilot.
La historia es que la industria finalmente está empezando a construir los mecanismos que hacen posible confiar en agentes autónomos.
Los modelos ya demostraron que pueden generar código.
Lo que todavía estamos construyendo son los sistemas que nos permiten dejarlos actuar.
Los próximos ganadores probablemente no sean los que tengan el modelo más inteligente.
Van a ser los que construyan el mejor entorno para que ese modelo trabaje de forma segura.
Y en esa carrera, los sandboxes son mucho más importantes de lo que su nombre aburrido sugiere.