É terça-feira de manhã e você abre um e-mail da ferramenta de IA para programar que sua equipe adotou no ano passado. Seu plano vai mudar. O uso que sua equipe faz toda semana agora custa bem mais, ou bate no limite já na quarta-feira, ou os novos termos de dados não cobrem mais o código do seu cliente do jeito que seu contrato previa.
Você faz as contas de uma troca e o resultado assusta. Não porque a ferramenta em si seja difícil de substituir, mas por causa de tudo o que você construiu em volta dela: os comandos personalizados, os arquivos de regras, a etapa de revisão no CI, o doc de onboarding que ensina quem chega a escrever prompts para ela. Tudo isso fala o dialeto de um único fornecedor.
É nesse momento que muitas equipes percebem que escolher uma ferramenta de IA para programar deixou de ser uma decisão de produtividade faz tempo. Agora é uma decisão de risco.
Sua ferramenta de IA já é infraestrutura
Um ou dois anos atrás, um assistente de IA era algo que alguém da equipe testava num branch à parte. Se ele sumisse, você perdia um pouco de autocompletar.
Hoje ele faz trabalho de verdade. Escreve os primeiros rascunhos das migrações, gera testes, revisa pull requests e responde perguntas sobre o codebase que antes iam para a única pessoa que lembra por que aquele módulo existe. Sua equipe construiu os hábitos em volta dele.
Algo de que sua equipe depende tanto merece as perguntas que você faria sobre um banco de dados ou um provedor de nuvem. O que acontece se o preço dobrar? O que acontece se os termos mudarem? Quanto tempo você levaria para substituí-lo?
Para a maioria das ferramentas fechadas, a resposta para essa última é “mais do que a gente gostaria”.
O que realmente te prende
Trocar de ferramenta é a parte fácil: instalar uma nova leva uma tarde. O difícil é tudo o que fica preso a ela, e isso está em três lugares:
- O modelo. Muitas ferramentas fechadas estão presas aos modelos de um único provedor, ou passam pelo próprio backend. Quando esse provedor muda preços, limites ou qualidade, a mudança chega até você, queira ou não.
- Os termos. Políticas de retenção de dados e de treinamento podem mudar com um plano novo ou um dono novo. Se você trabalha com código que não é seu, como o de um cliente, isso não é nota de rodapé.
- Seus artefatos de trabalho. Bibliotecas de prompts, regras de projeto, agentes personalizados e integrações costumam viver num formato que só aquela ferramenta lê. É aí que mora a maior parte do custo de troca.
Vale dizer: o fornecedor não é o vilão dessa história. Os preços mudam porque rodar modelos é caro e os modelos de negócio ainda não se assentaram. Mas o jeito de trabalhar da sua equipe continua dependendo de decisões nas quais você não tem voto.
O que muda com um agente aberto e independente de modelo
É aí que entram ferramentas como o OpenCode. O OpenCode é um agente de programação de código aberto que roda no seu terminal e funciona com vários provedores de modelos, incluindo os que você mesmo hospeda.
Ele não promete ser mais polido que as ferramentas fechadas. Promete que quem controla o stack é você. Na prática, isso te dá algumas opções concretas que você não tinha antes:
- Troque o modelo sem trocar a ferramenta. Se um provedor aumenta os preços ou sai um modelo melhor em outro lugar, você muda uma linha de configuração. Seus comandos e hábitos ficam onde estão.
- Mantenha o código sensível em casa. Para um repo que não pode sair da sua rede, você pode apontar o agente para um modelo próprio e manter o mesmo fluxo de trabalho.
- Leia o código. Quando o agente tem acesso ao shell da sua máquina, poder ver exatamente o que ele faz é uma vantagem real de segurança.
- Faça um fork se o projeto tomar um rumo que não te agrada. Projetos de código aberto também mudam de direção. A diferença é que a última versão boa continua ao seu alcance.
Seu custo de saída cai bastante, e isso limita o quanto o próximo e-mail de um fornecedor pode te prejudicar.
O que essa liberdade te custa
Se você está avaliando isso para a sua equipe, vale saber onde está se metendo.
Mais configuração. Você escolhe o modelo, gerencia as API keys, monta a configuração e decide como tudo isso se encaixa nas suas políticas de segurança. Uma ferramenta fechada toma a maioria dessas decisões por você.
Menos polimento. Um onboarding caprichado, uma experiência fluida no IDE e uma interface consistente são exatamente onde as ferramentas comerciais colocam dinheiro. Prepare-se para mais momentos de “que estranho” e mais visitas ao issue tracker.
Sem linha de suporte. Quando algo quebra, você tem a documentação, uma comunidade e o código-fonte. Para algumas equipes, isso basta. Para outras, significa que a pessoa que colocou tudo para funcionar vira a linha de suporte.
Você continua pagando pelos modelos. Ser independente de modelo não significa ser de graça. Você troca uma conta por outra, e agora comparar provedores é tarefa sua.
Você também vai notar que o mesmo agente parece outro dependendo do modelo, o que é informação útil, mas também mais trabalho.
Isso é atrito de verdade, e não some em uma semana.
Quando vale a pena pagar esse preço
Esse trade-off faz mais sentido quando alguma destas situações vale para você:
- Você já se queimou com uma mudança surpresa de preço ou de política, e lembra quanto tempo durou a correria.
- Você trabalha com código sob regras de dados rígidas: repos de clientes, setores regulados, qualquer coisa que não deva sair da sua rede.
- Sua equipe usa IA tão a fundo que trocar de ferramenta significaria reescrever fluxos de trabalho reais, não só reinstalar uma extensão.
- Você tem pelo menos uma pessoa na equipe que gosta de cuidar das ferramentas e tem tempo para isso.
Faz menos sentido se sua equipe é pequena, está satisfeita com a ferramenta atual, o código não é sensível e trocar leva uma tarde. Nesse caso, o polimento provavelmente vale mais para você do que a opção de saída.
Um jeito barato de reduzir seu risco este mês
Você não precisa migrar sua equipe para descobrir em que pé está. Três passos pequenos já te dizem quase tudo o que você precisa:
- Anote seu custo de saída. Liste o que você teria que reconstruir se a sua ferramenta atual dobrasse de preço amanhã. Se a lista for curta, está tudo bem. Se for longa, esse é o seu risco, por escrito.
- Mantenha suas instruções portáveis. Coloque as regras e convenções do projeto em arquivos Markdown simples dentro do repo, em vez de um formato que só uma ferramenta lê. A maioria dos agentes, abertos ou fechados, consegue lê-los.
- Rode uma tarefa real num agente de código aberto. Escolha algo do seu backlog, aponte o agente para o modelo que você já usa e compare o resultado. Assim você descobre quanto atrito enfrentaria de verdade, antes que vire urgência.
Se você ainda está comparando as ferramentas fechadas entre si, escrevemos a visão de um engenheiro sobre Claude Code vs. Cursor. Qualquer que seja a sua escolha, vale saber quanto custaria substituí-la antes que chegue o próximo e-mail com preços novos.
