- Início
- The Thinking Wire
- O Paradoxo Collina: Quando o Evangelista da IA Provoca a Revolta
O Paradoxo Collina: Quando o Evangelista da IA Provoca a Revolta
Em 15 de março de 2026, Matteo Collina publicou “Software Engineering Splits in Three.” O argumento: a IA está criando três camadas distintas de engenharia de software. Tier 1 para empresas de tecnologia, Tier 2 para grandes corporações com guardrails, Tier 3 para o que ele chamou de “software plumber.” O ensaio foi compartilhado, debatido e amplamente aceito como um mapa razoável do futuro.
Três dias depois, o próprio Collina se tornou o caso de estudo mais revelador da tese que escreveu.
O PR que mudou a conversa
Em janeiro de 2026, Collina abriu o PR #61478 no repositório do Node.js. O objetivo: implementar o node:vfs, um sistema de arquivos virtual. Os números: 21.373 linhas adicionadas, 120 arquivos, assistido por Claude Code. Até 22 de março, o PR acumulava 249 comentários de revisão e continuava aberto.
O volume não é acidental. Ferramentas como Claude Code produzem código em escala que revisores humanos não conseguem absorver com a mesma velocidade. Collina conhece essa dinâmica melhor que quase qualquer pessoa no ecossistema Node.js. Ele é membro do Technical Steering Committee, CTO da Platformatic e criador do Fastify. Quando abriu a issue #1509 na OpenJS Foundation em junho de 2025, o tema era exatamente esse: como lidar com desenvolvimento assistido por IA em projetos open source.
O problema é que conhecer a dinâmica não resolveu a dinâmica.
A petição
Fedor Indutny, membro emérito do TSC do Node.js, respondeu com uma petição direta: banir código gerado por IA do core do Node.js. Em poucos dias, mais de 90 pessoas assinaram. A lista inclui Kyle Simpson (autor da série You Don’t Know JS), Andrew Kelley (criador da linguagem Zig), Jan Lehnardt (membro do PMC do CouchDB). Não são desenvolvedores juniores reclamando de mudança. São arquitetos de sistemas críticos que mantêm infraestrutura usada por milhões.
A reação superficial é chamar Collina de hipócrita. Ele escreveu sobre os riscos da IA na engenharia e, dias depois, gerou o tipo exato de PR que sobrecarrega revisores. Mas essa leitura é preguiçosa.
Por que não é hipocrisia
A posição de Collina, quando você lê com cuidado o que ele publicou desde 2025, é consistente: IA com julgamento humano. O ensaio sobre três camadas não argumenta contra o uso de IA. Argumenta que cada camada exige diferentes níveis de supervisão. Tier 1 pode usar IA com autonomia alta porque tem infraestrutura de revisão proporcional. Tier 3 pode usar IA com autonomia alta porque o custo de falha é baixo. Tier 2, onde a maioria das organizações opera, precisa de guardrails proporcionais ao risco.
O problema aparece quando você aplica essa lógica ao open source. Um PR de 21 mil linhas no core do Node.js não é Tier 3. É infraestrutura que roda em servidores de produção no mundo inteiro. Mas o Node.js também não é uma empresa de Tier 1 com equipes de revisão dimensionadas para absorver PRs dessa escala. O projeto opera com voluntários. O tempo deles é finito. Cada hora gasta revisando código assistido por IA é uma hora que não vai para outra contribuição.
Como analisamos na mudança de fase da engenharia de software, o gargalo já não é produção de código. É revisão. Collina sabe disso. Escreveu sobre isso. E mesmo assim, seu PR reproduziu exatamente a assimetria que identificou.
Isso não é contradição pessoal. É evidência de que o problema é sistêmico. Se alguém com a experiência e a consciência de Collina produz um PR que sobrecarrega revisores, a falha não está no indivíduo. Está na ausência de regras claras sobre como código assistido por IA entra em projetos open source.
O precedente já existe
O Node.js não é o primeiro projeto a enfrentar essa questão. O QEMU baniu código de IA em 2025. O kernel do Linux exige tags “Assisted-by” para qualquer contribuição com assistência de IA. FreeBSD e Gentoo estão debatendo políticas semelhantes.
Cada projeto está inventando suas próprias regras. Não existe um framework comum. Não existe consenso sobre o que “assistido por IA” significa na prática. Um desenvolvedor que usa autocomplete do Copilot está na mesma categoria de alguém que gera 21 mil linhas com Claude Code? A maioria das políticas atuais não distingue os dois cenários.
Malte Ubl, CTO da Vercel, fez uma observação que ilumina a pressão: “O custo de produção de software tende a zero.” Se isso for verdade (e os dados apontam nessa direção), a quantidade de código submetida a projetos open source vai aumentar de forma acelerada. O volume de revisão necessário acompanha essa curva. A capacidade de revisão dos mantenedores, não.
O ângulo que ninguém menciona
Collina é CTO da Platformatic, uma empresa que vende infraestrutura para desenvolvedores Node.js. O ensaio “Software Engineering Splits in Three” não declara esse interesse comercial. Isso não invalida os argumentos. Mas contexto importa. Quando alguém propõe um modelo de três camadas onde a camada do meio precisa de “ferramentas e guardrails,” e essa mesma pessoa vende ferramentas e guardrails, o leitor merece saber.
Esse tipo de transparência ainda não é norma no ecossistema de thought leadership técnico. Deveria ser.
O que a petição revela
Os 90 signatários não estão resistindo à IA por medo ou nostalgia. Como exploramos no problema de identidade dos desenvolvedores frente à IA, a resistência nasce de uma percepção concreta: o trabalho de revisão recai sobre mantenedores que já operam no limite. Um PR de 21 mil linhas assistido por IA cria um dilema para quem revisa. Rejeitar sem ler parece arbitrário. Ler integralmente consome dias. Aceitar sem revisão rigorosa compromete a integridade do projeto.
A petição de Indutny é uma tentativa de resolver esse dilema pela via mais simples: proibição total. É uma resposta compreensível, mas insuficiente. Proibir código assistido por IA em 2026 é como proibir stack overflow em 2010. A prática já existe. A questão é como governá-la.
Os 104 estrelas e 81 forks do repositório da petição indicam que o sentimento é real e distribuído. Mas sentimento não é política. O Node.js precisa de regras operacionais: limites de tamanho para PRs assistidos por IA, requisitos de documentação sobre o papel da ferramenta, processos de revisão escalonados proporcionais à complexidade.
Três perguntas que todo projeto open source precisa responder
Primeiro: qual é o tamanho máximo de um PR assistido por IA que seus mantenedores conseguem revisar com rigor? Se a resposta é “não sabemos,” o projeto está vulnerável ao próximo PR de 21 mil linhas.
Segundo: como você distingue assistência por IA (autocomplete, sugestões pontuais) de geração por IA (blocos inteiros de funcionalidade)? A distinção importa porque a carga de revisão é radicalmente diferente.
Terceiro: quem arca com o custo de revisão? Se o contribuidor usa IA para multiplicar sua produtividade por dez, mas o revisor contínua operando na velocidade humana, o benefício é privado e o custo é coletivo. Esse desequilíbrio corrói projetos por dentro.
O que muda a partir daqui
O paradoxo de Collina vai se repetir. Desenvolvedores competentes e bem-intencionados vão submeter PRs assistidos por IA que sobrecarregam revisores. Não por má-fé. Porque as ferramentas incentivam volume e os projetos não têm regras para absorvê-lo.
A solução não é banir IA. É construir governança proporcional ao risco. Projetos open source que sustentam infraestrutura crítica (Node.js, Linux, QEMU) precisam de políticas formais antes que o volume de código assistido por IA ultrapasse a capacidade de revisão. Para muitos, esse ponto já passou.
Collina descreveu três camadas de engenharia. O que ele não descreveu é que o open source não cabe confortavelmente em nenhuma delas. É mantido por voluntários (Tier 3 em recursos), usado em produção global (Tier 1 em consequências) e opera sem os guardrails institucionais do Tier 2. Essa é a lacuna que a petição de Indutny expõe. Não hipocrisia individual, mas um déficit coletivo de governança que nenhum ensaio resolve sozinho.
Fontes
- Collina, M. “Software Engineering Splits in Three.” Março 2026.
- Indutny, F. “No AI Code in Node.js Core.” Março 2026.
- Collina, M. “Who Is Responsible for AI-Generated Code?” Março 2026.
Victorino Group ajuda organizações a construir frameworks de governança para desenvolvimento assistido por IA: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa