O que é a falácia do custo zero no open source

Durante décadas, o mundo do software repetiu o mantra: open source e de graça. Não ha licença, não ha mensalidade, e qualquer um pode baixar e usar. Mas essa definição sempre foi incompleta. O software em si pode ser grátis, mas a infraestrutura para roda-lo, as pessoas para mante-lo e a integração com outros sistemas nunca foram.

Em julho de 2026, a Thoughtworks publicou uma análise intitulada "The zero-cost fallacy: open-source software in the agentic era" que reacendeu esse debate. Com mais de 100 pontos no Hacker News e dezenas de comentários, o artigo argumenta que, na era dos agentes de IA autónomos, o custo oculto do open source ficou ainda maior e mais difícil de ignorar.

A chegada dos agentes de IA que constroem e deployam software de forma semi-automática cria novos vetores de custo: tokens de LLM para cada dependência instalada, licenças que modelos de IA não sabem verificar, vulnerabilidades em bibliotecas que agentes incluem sem revisão humana. O "grátis" do open source esta ficando cada vez mais caro.

Como funciona o problema de custo na era agentica

Um agente de IA moderno, ao executar uma tarefa de desenvolvimento, pode facilmente instalar dezenas de dependências open source. Cada npm install ou pip install gerado por um agente carrega consigo um custo composto que vai além do tamanho do pacote:

Custo de tokens: cada dependência processada pelo LLM para entender, instalar e integrar consome tokens. Em projetos com centenas de dependências, esse custo se acumula rapidamente. Um agente que reconstruiu o contexto de um projeto com 300 dependências pode gastar dezenas de dólares em tokens numa única execução.

Custo de manutenção: open source não e mantido por si só. Cada biblioteca tem um mantenedor (ou muitas vezes, um mantenedor sobrecarregado) que precisa responder a issues, revisar PRs e lançar patches de segurança. Quando o seu agente inclui 50 novas bibliotecas, você assumiu 50 novos relacionamentos de dependência que vao precisar de atualizações ao longo do tempo.

⚠️
Atenção

Agentes de IA não verificam automaticamente a licença de cada dependência que instalam. Uma biblioteca com licença AGPL ou GPL pode criar obrigações legais que invalidam o modelo de negócio do seu produto. Audite licenças regularmente.

Custo de segurança: cada dependência open source e uma superfície de ataque potencial. O famoso ataque ao XZ Utils em 2024 mostrou como um mantenedor mal-intencionado pode comprometer bibliotecas amplamente usadas. Agentes que adicionam dependências automaticamente ampliam essa superfície sem revisão humana.

Principais vetores de custo identificados

A análise da Thoughtworks identifica quatro categorias principais onde o "custo zero" do open source se dissolve na prática:

  • Tokens de LLM: processar, entender e integrar dependências open source em um contexto agentico consome tokens proporcionais a complexidade de cada biblioteca. Frameworks grandes como Spring Boot ou Django podem custar centenas de milhares de tokens só para serem compreendidos pelo agente.
  • Overhead de atualizações: o Dependabot e ferramentas similares criam dezenas de PRs de atualização por semana em projetos ativos. Revisar, testar e mergear cada um consome tempo de engenheiro, mesmo que seja um agente fazendo a revisão automática.
  • Risco de compliance: licenças como MIT, Apache 2.0, GPL e AGPL tem implicações jurídicas diferentes. Em empresas de SaaS, usar uma biblioteca AGPL pode exigir open sourcear todo o produto. Agentes raramente fazem essa verificação antes de instalar.
  • Debito técnico emergente: quando agentes escolhem bibliotecas por disponibilidade e não por qualidade de manutenção, o projeto acumula dependências abandonadas que mais tarde precisarão ser substituídas com custo alto.

Como começar: auditando o custo real das suas dependências

O primeiro passo e ter visibilidade. A maioria dos times não sabe quantas dependências diretas e transitivas seus projetos tem. Ferramentas de análise de dependências revelam a magnitude do problema.

Passo 1: Gere um inventario completo de dependências com ferramentas adequadas para sua stack.

# Node.js - listar todas as dependências incluindo transitivas
npm list --all --depth=5 2>/dev/null | wc -l

# Python - checar licenças de todas as dependências
pip install pip-licenses
pip-licenses --format=markdown --order=license

# .NET - listar pacotes com licença
dotnet list package --include-transitive

Passo 2: Classifique cada dependência por: frequência de atualização, atividade do mantenedor, número de contributors e tipo de licença. Dependências com mantenedor único e inativo são as de maior risco.

Passo 3: Se você usa agentes de IA no desenvolvimento, configure restrições explicitas no prompt de sistema para que o agente prefira dependências auditadas e evite adicionar novas sem revisão humana explicita.

💡
Dica

Mantenha uma lista de dependências aprovadas (allowlist) para cada projeto. Instrua seus agentes de IA a usar apenas dependências dessa lista, solicitando aprovação explicita antes de adicionar qualquer nova biblioteca.

Exemplo prático

Imagine uma startup brasileira de fintech usando um agente de IA para acelerar o desenvolvimento do seu backend Node.js. Em uma semana, o agente adiciona 23 novas bibliotecas para resolver problemas de validação, cache, logging e autenticação.

Sem revisão, a equipe só percebe três meses depois que uma das bibliotecas usa licença LGPL com restrições específicas, outra não tem mais mantenedor ativo ha 14 meses, e uma terceira tem uma vulnerabilidade crítica publicada no CVE. O custo para resolver: duas semanas de engenheiro sénior substituindo dependências e um sprint extra de testes.

# Exemplo de restrição em prompt de sistema para agente
SISTEM: Ao adicionar dependências ao projeto, siga estas regras:
1. Use apenas bibliotecas da lista em /docs/approved-deps.md
2. Para adicionar dependência nova: liste nome, versão, licença, último commit, número de contributors
3. Nunca instale dependências com licença GPL, AGPL ou similar sem aprovação explicita
4. Prefira bibliotecas com mais de 2 contributors ativos nos últimos 6 meses

Com esse prompt, o agente ainda acelera o desenvolvimento, mas com guardrails que eliminam os custos ocultos mais críticos.

Comparação com a visão tradicional

A visão tradicional do open source sustenta que a liberdade de usar, modificar e distribuir e o suficiente para justificar o uso. Na era pre-IA, essa visão funcionava porque a escala de adoção de dependências era limitada pela velocidade humana.

Na era agentica, a comparação relevante não e mais "open source grátis vs. software proprietário pago". A comparação certa e: custo total de propriedade de um ecossistema de dependências open source autonomamente gerenciado por agentes vs. custo de dependências menores e mais controladas, possivelmente pagas.

Empresas como a Vercel e a Cloudflare já experimentam modelos híbridos: dependências críticas proprietárias (com SLA e suporte garantido) combinadas com open source apenas para componentes de baixo risco. Esse modelo pode fazer sentido económico mesmo que o software proprietário tenha custo de licença.

Pontos positivos e limitações dessa análise

Pontos positivos: a Thoughtworks articula bem um problema real que muitos times ignoram. A análise ajuda CTOs e tech leads a ter uma conversa mais honesta sobre os custos de dependências na era agentica.

Limitações: a análise pode soar como argumento para software proprietário, o que não e a intenção. O open source continua sendo a base de toda a infraestrutura moderna e sua substituição por alternativas proprietárias criaria dependências de vendor ainda mais caras. A solução e gestão melhor, não abandono.

🔴
Cuidado

Não use essa análise como argumento para evitar open source. O custo real de dependências proprietárias (lock-in, aumentos de preço, falta de controle) geralmente supera os custos ocultos do open source bem gerenciado.

Casos de uso reais

Startup em fase inicial: usa agentes de IA para velocidade máxima e aceita o debito técnico de dependências não auditadas. Faz sentido a curto prazo, mas precisa de um sprint de auditoria antes da primeira rodada de investimento ou lançamento público.

Scale-up com compliance: precisa de controle rigoroso de licenças (financeiras, saúde, governo). Mantem allowlist de dependências aprovadas, usa FOSSA ou similar para auditoria automática, e instruí agentes a nunca adicionar dependências sem aprovação.

Empresa enterprise: já tem processo de aprovação de software. O desafio e adaptar esse processo para a velocidade dos agentes de IA, que podem adicionar dependências mais rápido do que o comité de aprovação consegue revisar.

Time de plataforma: fornece uma camada de bibliotecas internas aprovadas para outros times. Ao controlar o que entra nessa camada, controlam indiretamente o que os agentes dos times de produto podem usar.

Dicas e boas práticas

💡
Dica

Use o Software Composition Analysis (SCA) integrado ao seu CI/CD. Ferramentas como FOSSA, Snyk ou Mend fazem auditoria automática de licenças e vulnerabilidades em cada PR, inclusive os gerados por agentes.

🚀
Pro tip

Para projetos com agentes de IA, calcule o custo de token por dependência antes de iniciar. Um modelo simples: estime quantas vezes o agente vai processar o contexto do projeto por mes e multiplique pelo número de dependências vezes o tamanho médio de contexto por biblioteca. Isso revela o custo real de cada adição.

💡
Dica

Prefira dependências com mais de 100 contributors no GitHub e commits nos últimos 3 meses. Isso não garante qualidade, mas reduz significativamente o risco de abandono e de ataques de supply chain.

⚠️
Atenção

O Dependabot e GitHub Dependabot introduziram em julho de 2026 um "package cooldown" que atrasa atualizações de dependências por alguns dias. Isso da tempo para a comunidade detectar problemas antes de você atualizar. Habilite essa funcionalidade nos seus repositórios.

Vale a pena repensar o uso de open source?

Sim, mas o objetivo não e usar menos open source. E usar de forma mais consciente. A falácia do custo zero existia antes dos agentes de IA e continuara existindo depois. O que muda e a escala e a velocidade com que os custos ocultos se acumulam.

Para times que usam agentes de IA no desenvolvimento, o próximo passo e implementar uma política de dependências que inclua: allowlist de bibliotecas aprovadas, integração de SCA no CI/CD e instruções explicitas nos prompts de agentes para solicitar aprovação antes de adicionar novas dependências.

Open source continua sendo a fundação do desenvolvimento moderno. O que mudou e que agora precisamos de uma camada de governanca proporcional a velocidade com que agentes podem adicionar complexidade ao nosso ecossistema.