GitHub Copilot CLI: a Microsoft acaba de copiar o Claude Code (e isso é bom)

A Microsoft pegou uma carona pesada na Anthropic. Em 9 de março de 2026, ela lançou o GitHub Copilot CLI — uma ferramenta de linha de comando que move o Copilot na mesma direção arquitetural do Claude Code da Anthropic. Para quem faz vibe coding, isso é um marco: até dois ou três meses atrás, Copilot e Claude Code tinham filosofias diferentes. Agora, a fronteira entre eles está dissolvendo.

Eu trabalho na Microsoft, faço apresentações internas para o meu time sobre o que eu chamo de "The New Way of Working" com Claude Code, e posso afirmar com tranquilidade: o GitHub Copilot CLI fechou a maior parte dessa lacuna em uma única release.

Neste artigo: o que mudou, por que o CLI muda o jogo (e não só o chat do IDE), demo prática construindo uma aplicação multi-agente em poucos minutos, e o que isso significa para o desenvolvedor.

A diferença filosófica entre Copilot e Claude Code (até agora)

Até este lançamento, a divisão era clara:

• GitHub Copilot: assistente de desenvolvedor. Você escreve código, ele autocompleta, sugere, dá insights linha-a-linha. Trabalho colaborativo dentro do IDE.
• Claude Code: agente de desenvolvedor. Você joga uma ideia, ele escreve o código inteiro. Você revisa, ajusta, pede mudanças. Trabalho delegado, com você como revisor.

A Microsoft, com o GitHub Copilot CLI, está movendo o Copilot na direção do segundo modelo. É a versão Microsoft do agente autônomo de desenvolvimento. E não é coincidência: a Microsoft também fechou recentemente uma parceria com a Anthropic, e hoje você pode consumir modelos Claude (incluindo o Opus 4.6) diretamente pelo Azure AI Foundry.

Por que CLI e não apenas chat dentro do IDE

A pergunta natural é: "por que sair do conforto da interface gráfica e voltar para uma 'telinha preta' estilo MS-DOS?"

A resposta tem a ver com autonomia de execução. Quando o agente vive dentro de um IDE como o Visual Studio Code, o sandbox da plataforma força permissões granulares — "posso editar este arquivo? posso executar este comando? posso instalar esta dependência?" — interrompendo o fluxo a cada passo.

No CLI, o agente tem muito mais espaço para operar autonomamente. Você dá o objetivo, ele executa. Você concede uma autorização ampla por sessão (approve all for this session) e ele segue até o fim sem te perguntar nada.

Para quem é desenvolvedor raiz, é o ambiente natural. Para quem prefere a interface visual, o chat do IDE continua disponível — agora também com modelos Claude integrados.

A arquitetura agentic comum: agentes, subagentes e skills

Antes da demo, vale entender o framework conceitual — que não foi criado nem pela Anthropic nem pela Microsoft, mas virou padrão de mercado e ambas adotaram:

• Agente = o maestro. Recebe o objetivo, orquestra, decide o que precisa ser feito.
• Subagentes = os músicos. Cada um é especializado em um domínio (descobrir rotas, consultar clima, formatar respostas).
• Skills = ferramentas pontuais. Funções específicas que os subagentes invocam.

Os arquivos de configuração também espelham essa convergência: o Claude Code usa claude.md, o GitHub Copilot CLI usa copilot-instructions.md. Mesmos princípios, sintaxes parecidas. Migrar de um pro outro é trivial.

Por que esse arquivo de configuração é o ponto mais importante

Pensa que você está navegando de navio do Rio de Janeiro até Londres. Sem direção precisa, você vai pedir "vai pra Inglaterra" e o navio pode te depositar em qualquer ponto entre Europa e África. Aí você gasta semanas de retrabalho ajustando o curso.

Quando você escreve um copilot-instructions.md detalhado — convenções do projeto, padrões de código, restrições, exemplos do output esperado — você está dando coordenadas precisas. O agente pode errar 10% do destino, mas vai chegar próximo o suficiente para o ajuste final ser cirúrgico.

A regra prática: quanto mais tempo você investir nesse arquivo no início, menos tempo vai gastar em retrabalho no final. É 5x ou 10x a alavancagem.

Demo: construindo um planejador de rotas de ciclismo multi-agente

Para mostrar na prática, vou construir uma aplicação Python multi-agente. Setup:

# Como administrador
winget install --id GitHub.Copilot.CLI

# Após instalar, abra um novo terminal
copilot

# Login
/login
# (autorize via browser usando o código exibido)

Crio uma pasta vazia, abro o copilot dentro dela, e digo:

"Vamos criar um projeto. Quero um website... na verdade, vamos criar um agente sobre cycling — um planejador de rotas de ciclismo."

O Copilot CLI imediatamente começa a planejar:

• Faz perguntas sobre o tipo de agente (coding assistant? developer tool?)
• Define a linguagem (Python)
• Estrutura a hierarquia: orquestrador + 6 subagentes + skills

Em menos de 10 minutos, ele gerou:

• Estrutura de diretórios completa
• 7 agentes (orquestrador + preferências + descoberta de rota + clima + recomendação + scoring + busca de rota + formatação)
• Skills isolados por responsabilidade
• README.md descrevendo o sistema multi-agente
• Arquivos de configuração + dependências

Tudo em alguns enters, com permissão approve all for the session ativa.

A grande mudança: deploy direto via Azure Skills

Aqui está o que torna esse lançamento ainda mais relevante para quem trabalha com Microsoft. A Microsoft adicionou também skills nativos para Azure dentro do GitHub Copilot CLI.

O que isso significa na prática? Antes, o problema clássico era:

1. Agente gera o código
2. Você tenta implementar na nuvem
3. Falha por incompatibilidade de configuração
4. Volta pro agente, ele "corrige", tenta de novo
5. Falha de novo
6. Loop até passar (ou você desistir)

Com os skills de Azure, o código sai mais próximo de pronto na primeira tentativa — porque o agente já conhece os padrões da plataforma e gera o output já contemplando deploy. Isso é um salto de produtividade gigante para quem desenvolve em cloud Microsoft.

(Vou gravar um vídeo dedicado a isso em breve, vale acompanhar o canal.)

A lição mais importante: o trabalho mudou de "escrever código" para "especificar"

Vou ser direto sobre o que eu vejo todos os dias trabalhando dentro da Microsoft com soluções agentic:

O desenvolvedor raiz que ficava marretando código na unha vai precisar adotar esse modelo. Não é se vai. É quando.

Mas isso não significa que desenvolvedores vão sumir. Significa o oposto: a vantagem do desenvolvedor experiente vai ficar maior, não menor. Por quê?

Porque a vantagem agora não está em digitar código mais rápido. Está em saber especificar o que pedir:

• Conhecer trade-offs de arquitetura para definir constraints corretos no copilot-instructions.md
• Identificar casos extremos que o agente não vai antecipar sozinho
• Validar que o output gerado realmente atende os requisitos não-funcionais (segurança, performance, manutenibilidade)
• Saber quando o agente está indo na direção errada antes de gastar 10 minutos rodando

O preconceito contra vibe coding é o mesmo preconceito que a indústria teve contra IDEs gráficos nos anos 90, contra autocomplete inteligente nos anos 2000, contra Stack Overflow nos anos 2010. Em todos os casos, perdedor foi quem se recusou a evoluir o método de trabalho.

Próximos passos para você

1. Instale o GitHub Copilot CLI no seu ambiente de desenvolvimento (5 minutos)
2. Migre um projeto pequeno para o fluxo agentic — algo de baixa criticidade onde dá pra experimentar sem risco
3. Invista 1-2 horas escrevendo um copilot-instructions.md detalhado para esse projeto. Convenções, padrões, exemplos. Esse é o arquivo de maior alavancagem.
4. Mantenha o cérebro crítico ligado — agentes geram código rápido, mas a responsabilidade do que vai pra produção continua sua

A direção é clara. Quem chega primeiro pega vantagem competitiva. Quem chega tarde corre atrás.

Este artigo foi gerado a partir do meu vídeo no YouTube. Assista a versão completa para a demo completa de instalação e construção da aplicação multi-agente em tempo real.