Durante os últimos dezoito meses falamos muito sobre modelos, contexto, memória, MCPs, workflows e agentes. Mas há uma pergunta muito mais simples que quase sempre ficou escondida debaixo da conversa:
Onde realmente roda o agente?
Porque uma coisa é pedir a um modelo que sugira código. Outra completamente diferente é dar permissão para executar comandos, modificar arquivos, rodar testes, abrir pull requests ou interagir com infraestrutura.
A diferença entre as duas coisas é exatamente a diferença entre um assistente e um operador.
E é aí que aparece a novidade mais importante do GitHub esta semana: sandboxes locais e na nuvem para o Copilot.
Não é uma feature glamourosa. Não melhora benchmarks. Não adiciona milhões de tokens de contexto.
Mas provavelmente seja uma das peças mais importantes que apareceram no ecossistema agentic este ano.
O problema nunca foi o modelo
Os modelos já são suficientemente bons para muitas tarefas de engenharia.
Podem:
- Escrever código
- Refatorar módulos
- Gerar testes
- Revisar PRs
- Investigar bugs
- Propor arquiteturas
O gargalo deixou de ser a capacidade intelectual.
O problema passou a ser operacional.
Porque quando um agente precisa trabalhar em um repositório real aparecem perguntas incômodas:
- Pode acessar toda a máquina?
- Pode executar qualquer comando?
- Tem acesso a secrets?
- Pode abrir conexões externas?
- Pode modificar arquivos fora do projeto?
- O que acontece se entrar em um loop?
- O que acontece se executar algo destrutivo?
A maioria das organizações resolveu isso de forma bastante básica:
Não deixando o agente fazer muita coisa.
E isso limita enormemente o valor que podem gerar.
O paradoxo dos agentes
Todos queremos agentes mais autônomos.
Mas ninguém quer dar a eles acesso irrestrito.
Quanto mais poder tem um agente:
- Mais útil é.
- Mais risco introduz.
E essa tensão fica pior conforme os modelos melhoram.
Um agente capaz de modificar cem arquivos também é um agente capaz de quebrar cem arquivos.
Um agente capaz de desdobrar uma aplicação também é um agente capaz de desdobrar algo incorreto.
A indústria vinha batendo contra esse limite há meses.
Não precisávamos de modelos mais inteligentes.
Precisávamos de ambientes mais seguros.
O que realmente resolve um sandbox
A palavra “sandbox” soa chata.
Mas é uma das ideias mais poderosas de toda a engenharia de software.
A premissa é simples:
O agente pode fazer coisas reais, mas dentro de limites definidos.
Em vez de executar diretamente no seu laptop ou em infraestrutura crítica, o agente trabalha dentro de um ambiente isolado.
Esse ambiente pode controlar:
- Sistema de arquivos
- Acesso à rede
- Variáveis de ambiente
- Credenciais
- Ferramentas disponíveis
- Tempo de execução
- Consumo de recursos
Em outras palavras:
o sandbox separa autonomia de privilégios.
E isso muda completamente a equação.
O salto de copiloto a operador
Até agora grande parte dos workflows de IA funcionava assim:
- O agente propõe.
- O humano revisa.
- O humano executa.
Com um sandbox bem projetado aparece outro modelo:
- O agente propõe.
- O agente executa.
- O humano valida resultados.
Parece uma diferença pequena.
Não é.
É o passo que converte a IA de ferramenta assistiva para ferramenta operativa.
Por que isso importa para os times
A maioria dos times não tem problemas gerando código.
Tem problemas executando trabalho repetitivo.
Auditorias de dependências
Um agente poderia:
- Criar um ambiente isolado
- Atualizar pacotes
- Rodar a suite completa
- Detectar regressões
- Gerar um PR
Tudo sem tocar na sua máquina.
Expansão de cobertura
Um agente poderia:
- Analisar áreas sem testes
- Gerar cobertura incremental
- Executar validações
- Abrir mudanças prontas para review
Sem acesso a secrets nem a sistemas produtivos.
Refactors grandes
Os refactors são candidatos perfeitos para agentes:
- Muito trabalho mecânico
- Pouco valor criativo
- Alto volume de mudanças
Mas também são perigosos.
Um sandbox permite rodar esse trabalho em um ambiente descartável e validar o resultado antes de fazer o merge.
O verdadeiro paralelo com Claude Code
O interessante é que o GitHub não está inventando um problema novo.
Está chegando no mesmo lugar onde outras ferramentas agentic já vinham empurrando.
Quando a Anthropic introduziu:
- Worktrees isoladas
- Subagentes
- Agent View
- Dynamic Workflows
o objetivo não era única e exclusivamente coordenação.
Era permitir que múltiplos agentes trabalhassem sem se atrapalhem.
A diferença é que o GitHub está levando essa ideia mais perto do modelo operativo enterprise:
- Sandboxes
- Políticas
- Governança
- Controle centralizado
Duas abordagens distintas para resolver o mesmo problema:
como deixar os agentes trabalhar sem perder o controle.
O que vem depois
Acho que estamos entrando em uma nova fase do mercado.
A conversa durante 2024 e boa parte de 2025 foi:
Qual modelo é melhor?
A conversa de 2026 começa a ser outra:
Qual runtime é melhor?
Porque uma vez que os modelos alcançam certo nível de capacidade, o diferencial já não está apenas na inteligência.
Está em:
- Observabilidade
- Isolamento
- Governança
- Memória
- Ferramentas
- Orquestração
- Segurança
Em outras palavras:
infraestrutura para agentes.
E os sandboxes são uma peça central dessa infraestrutura.
O takeaway
A história desta semana não é que o GitHub adicionou uma feature nova ao Copilot.
A história é que a indústria finalmente está começando a construir os mecanismos que tornam possível confiar em agentes autônomos.
Os modelos já provaram que conseguem gerar código.
O que ainda estamos construindo são os sistemas que nos permitem deixá-los agir.
Os próximos ganhadores provavelmente não serão os que tiverem o modelo mais inteligente.
Vão ser os que construírem o melhor ambiente para esse modelo trabalhar de forma segura.
E nessa corrida, os sandboxes são muito mais importantes do que seu nome chato sugere.