Em janeiro, um time que estava montando o fluxo de desenvolvimento escolheu a ferramenta de IA para codar mais usada do mercado. Fez sentido: todo mundo usava, a comunidade era grande, a curva de aprendizado do resto do time ia ser curta. Quatro meses depois, essa mesma ferramenta perdeu um terço da base.
O dado é da JetBrains, publicado em agosto de 2026 dentro da série de pesquisa sobre adoção de agentes de código. Comparando janeiro com o período de maio a julho, o Cursor caiu de 18% para 12% de adoção entre desenvolvedores profissionais. No mesmo intervalo, o Claude Code foi de 18% para 39%, mais que dobrou, e passou a ser a ferramenta mais usada para 31% dos desenvolvedores entrevistados no mundo. Nos Estados Unidos a adoção chegou a 47%. O GitHub Copilot, que segurou a liderança do mercado por anos, hoje roda na metade da frequência de uso do Claude Code, segundo o mesmo levantamento.
Quem escolheu pelo ranking de janeiro escolheu certo, por um trimestre. Depois trocou de time perdedor.
Não é sobre acertar o vencedor
O ponto não é prever qual ferramenta vai liderar em 2027. Ninguém acerta isso com consistência, nem a própria JetBrains, que pesquisa o mercado o ano inteiro e ainda assim registra reviravoltas de um levantamento para o outro. A OpenCode, ferramenta de código aberto sem marca grande por trás, chegou a 7% de adoção e 42% de conhecimento entre os desenvolvedores nesse mesmo período. Não teve o orçamento de marketing das concorrentes maiores, e ganhou espaço assim mesmo.
O ponto é: se o líder muda a cada trimestre, escolher pelo líder é aceitar trocar de ferramenta a cada trimestre. E toda troca de ferramenta de IA para codar tem um custo que não aparece na conta de licença. Mora nas regras de projeto que você escreveu especificamente para o assistente antigo, no pipeline de CI que chama o binário dele, na revisão de código que aprendeu os erros típicos daquela ferramenta e passou a confiar demais nela.
Onde moram as regras do seu projeto
Pergunta prática, que a maioria dos times não faz até precisar trocar: as instruções que você deu para a IA (padrão de commit, convenção de nomes, o que ela pode tocar sem revisão) estão num arquivo versionado no repositório, ou estão dentro da configuração proprietária da ferramenta?
# AGENTS.md (na raiz do repo, versionado)
- Commits em português, no imperativo, sem corpo.
- Nunca alterar arquivos em /infra sem aprovação explícita.
- Todo PR precisa de teste que cubra o caminho feliz e um caso de erro.
Se essas regras vivem num arquivo assim, trocar de ferramenta é reapontar o editor. Se vivem dentro do prompt de sistema salvo na conta do Cursor, ou nas memórias proprietárias de outro produto, trocar é reescrever do zero, e o time vai adiar a troca mesmo quando a ferramenta antiga já não é a melhor opção. O lock-in de ferramenta de IA para codar não mora no contrato de licença. Mora em onde o conhecimento do projeto foi guardado.
Tem um sintoma simples de quando isso já deu errado: alguém pergunta por que o time segue um padrão específico de código, e a resposta é "foi assim que a ferramenta configurou", sem ninguém lembrar o motivo original. A regra virou lenda oral em vez de linha versionada. Nesse ponto, trocar de ferramenta não é só reescrever prompt, é reconstruir uma decisão que ninguém mais sabe explicar.
O critério que sobrevive à troca de ranking
| Pergunta | O que ela revela |
|---|---|
| As regras do projeto estão em arquivo versionado ou na configuração da ferramenta? | Quanto você perde ao trocar |
| O CI chama a ferramenta por CLI ou API aberta, ou só roda dentro do IDE dela? | Se o pipeline trava junto com o editor |
| Quem avalia o código gerado é um critério seu (teste, checklist, revisão) ou o julgamento da própria ferramenta? | Se a qualidade sobrevive à troca |
Nenhuma dessas perguntas pergunta qual ferramenta é a melhor hoje. Perguntam quanto custa deixar de usá-la amanhã, e essa é a pergunta que continua valendo depois que o próximo levantamento da JetBrains sair.
Na Overflow, a régua de troca é essa: dói trocar, ou é só reconfigurar o editor? Quando dói, o problema raramente é a ferramenta que caiu no ranking. É onde as regras do projeto ficaram guardadas. É um dos critérios que a gente usa ao ajudar empresas a decidir onde a IA entra na operação, antes de recomendar qualquer produto específico.
Segunda de manhã
Abra o repositório e procure onde estão as instruções que o time deu para a ferramenta de IA que usa hoje. Se estiverem dentro da configuração dela, mova para um arquivo de texto versionado essa semana, antes de precisar trocar sob pressão. Depois, escolha um dia para rodar o fluxo de trabalho com outra ferramenta e anote o que quebra. O que quebrar é exatamente o que está te prendendo, e vale mais que qualquer ranking para decidir a próxima troca. Se nada quebrar, ótimo: significa que a próxima pesquisa da JetBrains, seja lá o que ela mostrar, não vai custar um fim de semana de retrabalho para o time.
