Um time de oito devs decide trocar de agente de código. A parte fácil é a comparação: testar em dois ou três repositórios, ver preço, ver quem entende melhor o contexto do projeto. A parte difícil aparece depois. As instruções do projeto estavam salvas num arquivo de configuração que só o agente antigo lê. A automação de revisão de PR chamava a API proprietária daquele fornecedor direto. O playbook de onboarding ensinava a abrir o chat de uma extensão específica, não a rodar um comando. Trocar de agente virou reescrever três meses de processo.
Oito pontos em quatro meses
O motivo para prestar atenção nisso agora é um número. A Developer Ecosystem Survey 2026, da JetBrains, ouviu mais de 15 mil desenvolvedores profissionais no mundo todo. Entre janeiro e o período de maio a julho de 2026, a adoção do GitHub Copilot no trabalho caiu de 29% para 21%. No mesmo intervalo, o Claude Code foi na direção oposta: de 18% para 39%. Quatro meses bastaram para o líder de mercado perder oito pontos e o desafiante mais que dobrar.
Não é um dado sobre qual ferramenta é melhor. É um dado sobre velocidade de troca. Time nenhum decide qual banco de dados usar pensando em revisitar a escolha em quatro meses. Provedor de nuvem, framework de backend, ORM: tudo isso muda em anos, não em trimestres. Agente de código virou a primeira peça de infraestrutura de desenvolvimento que muda de posição no ranking mais rápido do que um projeto normal muda de sprint.
E se o seu processo depende de qual fornecedor está em primeiro lugar hoje, você está construindo em cima de areia que se move.
O erro não é o fornecedor, é o formato
O erro comum não é apostar no agente errado. É prender o processo do time num formato que só um fornecedor entende. Isso tem nome: lock-in de contexto. Diferente do lock-in clássico de infraestrutura (banco de dados proprietário, nuvem fechada), esse aqui é barato de evitar, porque a maior parte da instrução que você dá para um agente de código é texto simples.
| Depende do fornecedor | Funciona com qualquer agente |
|---|---|
| Instrução de projeto salva na configuração interna da extensão | Arquivo markdown versionado no repositório, tipo AGENTS.md ou CLAUDE.md |
| Automação de revisão chamando a API específica de um chat de IDE | Script de linha de comando que qualquer agente aciona como qualquer outra ferramenta do terminal |
| Contexto do projeto documentado numa wiki que só o assistente de um fornecedor indexa | Contexto no próprio repositório, em texto, lido por grep e por qualquer LLM |
A diferença prática aparece num comando simples. Em vez de ensinar o time a abrir um painel específico:
$ cat AGENTS.md
# Contexto do projeto
- Stack: Node 22, Postgres, filas em Redis
- Rodar testes: npm run test:integration
- Nunca commitar direto na main
Esse arquivo qualquer agente lê, porque é texto num repositório git, não uma configuração presa numa conta de fornecedor. Trocar de ferramenta de código passa a custar uma tarde de teste, não um trimestre de reescrita.
Duas decisões que o time costuma misturar
Uma é "qual agente usar esse trimestre", que muda com preço, com limite de contexto, com quem está na frente do ranking essa semana, e não precisa de cerimônia nenhuma para trocar. A outra é "onde mora a instrução do nosso processo", que precisa ser estável mesmo quando a primeira decisão muda de mês em mês. Confundir as duas é o que trava um time inteiro numa migração que não precisava existir.
Isso não é exclusivo de agente de código. A mesma lógica vale para automação de atendimento, para pipeline de dados, para qualquer camada onde uma empresa terceiriza julgamento para um modelo de IA. A pergunta que decide se a stack aguenta o próximo ranking não é "qual fornecedor escolher agora". É "o que eu perco se trocar de fornecedor daqui a quatro meses". Quando a resposta é "nada além do tempo de configurar de novo", a escolha do fornecedor deixou de ser uma aposta de longo prazo e virou o que sempre devia ter sido: um teste barato. É esse tipo de decisão de arquitetura que entra na consultoria de software da Overflow antes da primeira linha de código, junto com o resto do diagnóstico técnico.
O que fazer na segunda de manhã
Na segunda de manhã, antes de discutir qual agente é melhor, separe uma tarde para listar quantas automações do time só rodam dentro da janela de um único fornecedor de IA. Se a lista passar de duas, o problema não é escolha de ferramenta. É que o processo do time está morando dentro da conta de outra empresa, e essa empresa pode perder oito pontos de mercado no próximo trimestre sem avisar ninguém.