GitHub Copilot deixa de ser autocomplete e vira uma plataforma de agentes de código

O marco mais claro dessa virada é o modo agente. Em fevereiro de 2025, o GitHub anunciou recursos agentivos para implementar mudanças em vários arquivos e sugestões de “próxima edição”. A equipe do VS Code descreveu o Copilot agent mode como um par programador autônomo, capaz de analisar a base de código, ler arquivos relevantes, propor edições, executar comandos e testes no terminal, observar erros de compilação ou lint e iterar até concluir a tarefa.

Na prática, isso muda a conversa entre pessoa e ferramenta. Em vez de pedir apenas a continuação de uma expressão, o desenvolvedor pode pedir uma alteração coerente: atualizar um padrão de chamada de API, refatorar um componente, ajustar testes ou investigar um caminho de erro. O trabalho humano passa a se concentrar mais em delimitar a tarefa, revisar o plano, conferir o diff e validar o resultado.

Edição multiarquivo: mais poder, mas com revisão

A ponte mais importante entre autocomplete e agentes completos é a edição em vários arquivos. Na atualização de outubro de 2024 do Copilot no VS Code, o GitHub apresentou a edição multiarquivo em prévia, ativada pela configuração github.copilot.chat.edits.enabled, permitindo iniciar uma sessão de edição com IA e pedir ao Copilot mudanças em múltiplos arquivos do workspace.

O padrão descrito não é “o Copilot reescreve o repositório em silêncio”. O fluxo documentado é centrado em revisão: o Copilot propõe edições, aplica essas mudanças diretamente no editor e permite que a pessoa desenvolvedora as revise no contexto do código ao redor. A documentação da Microsoft para o Visual Studio descreve uma experiência parecida no Copilot Edits, combinando chat com revisão inline, resumo dos arquivos afetados, mudanças propostas, diffs no editor e controles para aceitar ou rejeitar alterações individuais.

Isso é crucial porque refatorações em vários arquivos só são úteis quando a superfície de revisão é boa. Uma mudança aparentemente simples pode quebrar imports, testes, tipos ou premissas em outra parte do sistema. Pelo que as fontes mostram, a arquitetura de edição do Copilot não deve ser vista como autonomia invisível, mas como um ciclo: pedir, propor, comparar, aceitar, rejeitar e refinar.

Copilot Workspace reforça o trabalho orientado por intenção

O Copilot Workspace levou a mesma lógica para mais perto do fluxo nativo do GitHub. O manual do GitHub Next descreve o Workspace como um assistente de IA “centrado em tarefas”, contextual, integrado ao GitHub e consciente do repositório, da issue e do pull request associados à tarefa.

No changelog de fevereiro de 2025, o GitHub também destacou melhorias de follow-ups e busca de arquivos no Copilot Workspace, voltadas a geração de código multiarquivo e repositórios grandes com dependências complexas. Segundo a descrição, o recurso de follow-up faz uma checagem pela base de código e edita automaticamente os arquivos necessários quando detecta pendências relacionadas.

Em termos práticos, fluxos desse tipo transformam “corrija esta issue” em um ciclo mais estruturado: entender a tarefa, identificar arquivos relevantes, propor ou refinar um plano, gerar mudanças e continuar procurando ajustes relacionados. É algo mais próximo de refatoração orientada por intenção do que de autocomplete. Ainda assim, continua dependendo de revisão humana, testes e disciplina de controle de versão.

VS Code vira a mesa de comando do Copilot agentivo

As atualizações recentes do Copilot no VS Code deixam a direção ainda mais clara. O changelog de abril de 2026 informa que o Copilot passou a buscar por significado em qualquer workspace e a rodar consultas no estilo grep em repositórios e organizações do GitHub. O mesmo registro menciona o recurso experimental /chronicle, usado para consultar histórico de chat, além de cache de prompts, carregamento adiado de ferramentas para reduzir uso de tokens e diffs inline no chat para agentes.

O changelog de março de 2026 aponta para a mesma tendência: ele lista o Autopilot, em prévia pública, para sessões de agente totalmente autônomas, e diz que a ferramenta #codebase passou a executar buscas puramente semânticas contra um índice único gerenciado automaticamente.

Esses recursos importam porque um agente de programação vale tanto quanto o contexto que consegue recuperar. Um assistente que busca por significado, encontra arquivos relevantes, mostra diffs inline e consegue consultar histórico de conversa está mais preparado para trabalhar no nível do repositório do que uma ferramenta que enxerga apenas o cursor atual.

A escolha do modelo virou parte do fluxo de desenvolvimento

O Copilot também está se tornando uma espécie de roteador de modelos. A documentação de comparação de modelos do GitHub afirma que o Copilot suporta múltiplos modelos de IA e que o modelo escolhido afeta a qualidade e a relevância das respostas do Copilot Chat e das sugestões inline. O GitHub também observa que os modelos diferem em latência, tendência a alucinações e desempenho em tarefas específicas.

Isso significa que escolher modelo deixou de ser um detalhe invisível de implementação. Um modelo rápido pode fazer sentido para completions rotineiros; um modelo mais forte em raciocínio pode ser melhor para depuração, refatoração ou tarefas agentivas em múltiplas etapas. A documentação também diz que, em IDEs compatíveis, o Copilot Chat pode usar um modo Auto para selecionar um modelo com base na disponibilidade, mantendo a possibilidade de escolha manual.

O suporte a BYOK vai na mesma direção, mas também exige cuidado na leitura. As notas de lançamento de março de 2025 do VS Code descrevem BYOK em prévia para usuários Copilot Pro e Copilot Free, permitindo usar chaves de API próprias de provedores como Azure, Anthropic, Gemini, OpenAI, Ollama e OpenRouter; a mesma nota diz que o GitHub explorava suporte para clientes Copilot Business e Enterprise. Isso deve ser entendido como suporte a BYOK em contextos específicos de VS Code/Copilot, não como prova de que todos os planos aceitam qualquer fluxo de “traga seu próprio modelo”.

Depreciações de modelos agora afetam o dia a dia

Quanto mais o Copilot passa por chat, edições inline, modo ask, modo agente e completions, mais uma troca de modelo impacta o trabalho cotidiano. O changelog de maio de 2026 do GitHub diz que o Grok Code Fast 1 será descontinuado em todas as experiências do GitHub Copilot — incluindo Copilot Chat, edições inline, modos ask e agent, além de completions de código — em 15 de maio de 2026. O mesmo changelog informa que o GPT-4.1 tem depreciação prevista nessas experiências em 1º de junho de 2026.

Esse não parece ser um evento isolado. Em janeiro de 2026, o GitHub disse que avalia regularmente e aposenta modelos mais antigos em favor de modelos mais novos, listando depreciações em Copilot Chat, edições inline, modos ask e agent e completions de código.

Um resumo de lançamento de terceiros aponta o GPT-5.5 como alternativa sugerida para a depreciação do GPT-4.1. Mas as fontes primárias fornecidas confirmam com mais clareza o evento de depreciação do que todos os caminhos de migração. Elas não confirmam, de forma clara, uma migração de GPT-5.2 para GPT-5.5. Antes de planejar mudanças com base nessa premissa, equipes devem verificar a disponibilidade de modelos e as políticas administrativas diretamente nos changelogs e controles do Copilot.

Por que a qualidade preocupa desenvolvedores

A preocupação não é apenas trocar o nome de um modelo. A própria documentação do GitHub diz que a escolha do modelo afeta a qualidade e a relevância das respostas do Copilot, e que diferentes modelos variam em latência, alucinações e desempenho por tipo de tarefa. Se um modelo é retirado de chat, edições inline, modo agente e completions, o impacto pode aparecer em todos esses pontos: sugestões podem parecer mais rápidas ou mais lentas, explicações podem ficar mais ou menos confiáveis e edições agentivas podem exigir outro nível de revisão.

Por isso, a rotatividade de modelos virou tema de governança, não só uma atualização de produto. Times que usam Copilot para refatoração, geração de testes ou pull requests conduzidos por agentes precisam acompanhar quais modelos estão habilitados, quais serão descontinuados e como a qualidade varia nos próprios repositórios.

Como equipes devem se adaptar

Para desenvolvedores individuais, o modelo mental mais seguro é: delegar, mas verificar. Use o Copilot para explorar código desconhecido, sugerir refatorações e gerar edições multiarquivo, mas mantenha testes, checagem de tipos, revisão de código e inspeção manual de diffs no fluxo. A própria orientação do GitHub sobre refatoração começa por entender o código existente antes de modificá-lo, com o Copilot ajudando a explicar trechos selecionados pelo chat inline.

Para lideranças de engenharia, a prioridade é definir onde o Copilot agentivo pode atuar. Edições multiarquivo e modo agente são úteis para mudanças mecânicas, migrações e atualização de testes, mas também aumentam a área a ser revisada. Políticas de modelo, rastreabilidade e planos de rollout pesam mais quando o Copilot edita vários arquivos ou executa comandos no terminal do que quando sugere uma única linha.

Para times de plataforma, depreciações de modelo devem ser tratadas como upgrades de dependência. Vale revisar changelogs, testar fluxos críticos com modelos substitutos, atualizar políticas administrativas e documentar quais superfícies do Copilot serão afetadas. Como as depreciações do GitHub podem atingir chat, edições inline, modo ask, modo agente e completions, o raio de impacto é maior do que o de um recurso isolado do IDE.

Em resumo

O GitHub Copilot está evoluindo para um ambiente de desenvolvimento agentivo e consciente do repositório. A evidência mais forte aparece no modo agente, na edição multiarquivo, nos follow-ups do Copilot Workspace, na busca semântica, nos diffs inline, nos experimentos de BYOK e na seleção entre múltiplos modelos.

Mas o entusiasmo precisa continuar ancorado nos fatos. A tendência confirmada não é “o Copilot pode reescrever tudo sozinho com segurança”. É que o Copilot está se tornando um sistema orientado por revisão para transformar intenção de desenvolvimento em mudanças propostas no repositório. As equipes que melhor aproveitarem essa transição serão as que souberem delimitar tarefas, revisar diffs com rigor, medir a qualidade dos modelos e tratar migrações de modelo como parte normal da operação de engenharia.