Eu uso o Vim há mais de dez anos. E durante todo esse tempo, uma coisa me irritou profundamente: a quantidade absurda de configuração necessária pra deixar o editor do jeito que eu quero. Plugins, keybindings, LSP configs, tudo manual. Mas a real é que eu aguentava porque a alternativa era pior: aceitar o que a JetBrains ou a Microsoft decidiam que era melhor pra mim.

Essa dinâmica mudou. E mudou de um jeito que ninguém previu.

O argumento que ninguém esperava

David Crawshaw, criador do Tailscale e do exe.dev, publicou um post que explodiu no Hacker News esta semana com quase 400 pontos. O título é direto: “Devtools must be open source”. Mas o argumento dele não é o que você imagina.

Crawshaw não está repetindo o mantra clássico de “open source é melhor porque é transparente” ou “comunidade é tudo”. O ponto dele é muito mais pragmático e, honestamente, mais assustador pra quem vende software proprietário: agentes de IA tornaram a customização de software tão barata que não faz mais sentido usar ferramentas que você não pode modificar.

Leia de novo: a customização ficou tão barata que o modelo de negócio de software fechado perdeu uma das suas maiores vantagens.

Como funcionava antes (e por que a gente aceitava)

Cinco anos atrás, manter software personalizado era caro. Você precisava de um time de devs pra construir, outro pra manter, e a cada atualização do upstream era aquele drama de merge. O ROI simplesmente não fechava pra maioria dos casos.

Por isso existiam sistemas de plugins. O VS Code tem extensões. O Vim tem plugins. O Jira tem apps. Essas arquiteturas de extensibilidade existem porque o custo de modificar o código-fonte diretamente era proibitivo. Então os criadores ofereciam “ganchos” controlados: APIs de plugin, arquivos de configuração, temas. Você podia personalizar, mas só até onde eles deixavam.

A última linha da tabela é o que mudou tudo.

O agente como camada de configuração

Aqui é onde a coisa fica interessante. Crawshaw argumenta que agentes de IA não são apenas ferramentas de geração de código. Eles são, na prática, a nova camada de configuração de software.

Pensa assim: em vez de abrir um menu de Settings e marcar checkboxes, você diz pro agente “quando eu abrir um PR, roda o linter, remove imports não usados e formata com tabs de 4 espaços”. O agente não configura o software. Ele modifica o código-fonte do software pra fazer o que você quer.

# Exemplo real do Shelley (agente open source)
shelley personalize "strip unimportant code from diffs,
  focus on architecture changes,
  run meat.dev preprocessing in background"

Isso só funciona se o código-fonte estiver disponível. Se o seu editor é proprietário, o agente fica limitado às APIs de extensão que a empresa decidiu expor. E essas APIs são, por definição, um subconjunto do que o software pode fazer.

O caso do Claude Code vs. alternativas abertas

Eu sei que isso é um pouco irônico vindo de um artigo num site que usa ferramentas de IA pra produzir conteúdo. Mas o paralelo é inevitável.

O Claude Code é proprietário. É polido, funciona bem, tem integração profunda com Git e entende o contexto do projeto como poucos. Mas você não pode modificar seu comportamento além do que a Anthropic permite via CLAUDE.md e skills. Quer mudar como ele constrói o contexto de um repositório monorepo gigante? Azar. Quer integrar com uma ferramenta interna da sua empresa que ninguém mais usa? Espera sair na próxima release (ou não).

Do outro lado, ferramentas como OpenCode (MIT license) e Aider rodam com 75+ provedores de IA, aceitam modelos locais e, mais importante, você pode modificar qualquer comportamento. O OpenCode já tem 161 mil stars no GitHub, contra 132 mil do Claude Code (dados de junho de 2026). E o Aider, que existe desde 2023, continua crescendo porque permite coisas como trocar de modelo no meio de uma sessão, rodar offline com Ollama, e customizar absolutamente tudo via código.

# Com uma ferramenta open source, você pode:
# 1. Trocar o modelo sem pedir permissão
# 2. Modificar como o contexto é construído
# 3. Adicionar integrações que o criador nunca imaginou
# 4. Rodar 100% local, sem enviar código pra nuvem
# 5. Auditar cada token que sai da sua máquina

A diferença econômica também pesa. O Claude Pro custa US$ 100/mês pra acesso ilimitado ao Sonnet. Com ferramentas open source, você paga apenas os tokens de API que consumir, sem markup de assinatura. Pra muitos devs solo ou startups pequenas, essa diferença paga o almoço do mês.

A questão não é se o Claude Code é bom (é). A questão é se faz sentido depender de uma ferramenta que você não controla quando a alternativa é cada vez mais viável.

O efeito cascata: Terraform, Redis e a vingança dos forks

Se esse argumento parece teórico, olha o que aconteceu na prática com infraestrutura.

Em agosto de 2023, a HashiCorp mudou a licença do Terraform de MPL para BSL. Dois meses depois, surgiu o OpenTofu, um fork mantido pela Linux Foundation. Os céticos disseram que não ia durar.

Três anos depois, o OpenTofu está na versão 1.12.2, foi aceito na CNCF, tem 3.900+ providers e 23.600+ módulos. Mais que isso: ele tem features que o Terraform não tem, como criptografia de estado nativa, avaliação antecipada de variáveis e iteração de providers com for_each.

A mesma história se repetiu com o Redis. Depois de duas mudanças de licença em 18 meses, o Valkey (fork comunitário) atraiu mais de 700 contribuidores e 5 milhões de pulls no Docker.

O padrão é claro: quando uma empresa muda as regras, a comunidade faz o fork e segue em frente. E com agentes de IA, a velocidade desse processo acelera exponencialmente, porque o agente pode adaptar o fork às suas necessidades em minutos, não meses.

Software sob medida: do luxo à commodity

Crawshaw faz uma observação que eu acho brilhante. Ele diz que categorias inteiras de produto precisam ser reinventadas: task managers, CMSs, CRMs. A ideia é que, em vez de comprar um Jira e aceitar suas 47 tipos de issue, você monta seu próprio sistema juntando bibliotecas modulares e deixa o agente costurar tudo.

O blog dele, aliás, é um exemplo disso. Foi construído com software sob medida, escrito pelo Shelley (o agente open source dele), porque era mais fácil juntar e personalizar bibliotecas do que usar um CMS pronto.

Isso pode parecer extremo, mas pensa nos números: agentes de IA já reduzem o tempo de codificação manual em 30 a 50%. O Claude Code sozinho é responsável por mais de 10% dos commits públicos no GitHub, com picos de 326 mil commits por dia. A projeção é chegar a 20% até o fim de 2026.

Se metade do código já está sendo escrita por agentes, a barreira pra criar software personalizado praticamente desaparece.

E não é só sobre criar do zero. É sobre manter. Crawshaw destaca que agentes conseguem fazer rebase automático das suas modificações locais com o upstream. Ou seja: você faz o fork, personaliza o que quiser, e o agente cuida de manter tudo sincronizado quando o projeto original lança uma atualização. O pesadelo de merge conflicts que matava forks pessoais simplesmente sumiu.

Eu já vi isso funcionando na prática. Um colega fez um fork do Neovim com umas 30 modificações pessoais, e um agente mantém tudo atualizado com o upstream há seis meses sem intervenção humana. Zero conflitos não resolvidos. Isso era impensável em 2023.

O problema real: vendor lock-in em esteroides

Aqui é onde eu fico preocupado. Porque a mesma tecnologia que liberta também pode aprisionar.

Quando você constrói todo o seu workflow ao redor de uma ferramenta proprietária, a cada feature que o agente adiciona pra você, mais dependente você fica. É o vendor lock-in tradicional, mas potencializado pela velocidade de customização.

Com ferramentas open source, o risco é diferente. Você pode trocar o agente sem perder as customizações, porque elas estão no código-fonte que você controla. Com ferramentas proprietárias, se a empresa muda o preço, a API ou simplesmente fecha, suas customizações vão junto.

A lição do Terraform se aplica aqui: não importa o quão boa é a ferramenta se você não controla os termos de uso.

O mercado de 2026: cinco categorias de ferramentas de código

O mercado de agentes de IA pra desenvolvimento se dividiu em cinco categorias distintas em 2026:

A tendência é clara: a última categoria está crescendo mais rápido que todas as outras. Não porque os devs odeiam pagar (muitos pagam US$ 100/mês no Claude Pro sem pestanejar), mas porque a flexibilidade de poder modificar a ferramenta se tornou mais valiosa do que qualquer feature proprietária.

Na prática: como migrar sem drama

Se você está convencido mas não sabe por onde começar, aqui vão três passos pragmáticos:

1. Identifique suas dependências proprietárias

Liste todas as ferramentas de dev que você usa e classifique: open source, source-available, ou proprietário. Preste atenção especial nas que guardam dados (IDE configs, histórico de chat com IA, snippets salvos).

2. Teste uma alternativa open source por semana

Não precisa migrar tudo de uma vez. Troque o Postman pelo Bruno. Teste o OpenCode no lugar do Claude Code por um projeto pequeno. Use o Helix em vez do VS Code por um dia.

3. Automatize com agentes

Configure um agente open source (Shelley, Aider, OpenCode) pra manter suas customizações. Peça pra ele sincronizar seu fork com o upstream automaticamente. Se algo quebrar, ele conserta.

# Exemplo: agente mantém seu fork sincronizado
aider --auto-rebase upstream/main \
      --apply-local-patches patches/ \
      --run-tests after-merge

Quem está fazendo certo (e quem vai sofrer)

Algumas empresas já entenderam o recado. A Vercel mantém o Next.js e o Turbopack totalmente open source, mesmo lucrando com a plataforma de hospedagem. O shadcn/ui, que passou de 106 mil stars no GitHub, tem uma filosofia radical: em vez de instalar um pacote, você copia os componentes pro seu projeto. Você é dono do código. Sem dependência, sem lock-in, sem versão incompatível.

O Continue, um assistente de IA para código, é open source e te deixa escolher qual modelo usar. A filosofia é simples: a ferramenta é sua, o modelo é sua escolha, os dados ficam na sua máquina.

Quem vai sofrer? Empresas que vendem devtools proprietários sem um diferencial absurdo de UX ou integração. Se o seu produto pode ser replicado por um agente em cima de bibliotecas open source, sua proposta de valor está com prazo de validade.

O futuro pertence ao código que você pode ler

Eu não sou ingênuo. Ferramentas proprietárias não vão desaparecer amanhã. O VS Code, que é parcialmente open source mas com telemetria e extensões proprietárias da Microsoft, vai continuar dominando por anos. O Cursor levantou centenas de milhões e está crescendo rápido.

Mas o argumento de Crawshaw é difícil de refutar: se um agente pode modificar qualquer software cujo código-fonte está disponível, então software fechado é, por definição, software menos útil. Não porque é ruim, mas porque limita o que o agente pode fazer por você.

E no ritmo em que agentes estão evoluindo, essa limitação vai pesar cada vez mais. Já existem agentes que escrevem agentes. Já existem agentes que mantêm forks. Já existem agentes que montam stacks inteiras sob medida pra um único dev. Cada uma dessas capacidades funciona melhor com código aberto.

A pergunta que todo dev deveria se fazer agora não é “qual a melhor ferramenta?”, mas sim: “eu tenho acesso ao código da ferramenta que estou usando?”. Porque se a resposta for não, pode ser que você esteja pagando por uma prisão confortável.

Fonte de inspiração: Devtools must be open source, de David Crawshaw