Escrever Código Era o Filtro. O Flathub Reconstruiu Um por Quinze Minutos.

“Antes, escrever código funcionava como um filtro natural porque exigia uma quantidade não trivial de esforço e investimento de tempo. Isso agora acabou.” A frase é de Jiří Eischmann, contribuidor ligado ao GNOME e mantenedor do Meshy, escrevendo de Brno em 23 de julho de 2026. É a sentença mais útil publicada sobre IA e código aberto neste mês, e quase ninguém a está lendo como uma afirmação sobre controle.

Vale ler assim. O custo de produzir um patch era, na prática, trabalho de governança. Ninguém o projetou para isso, ninguém votou nele, nenhum mantenedor o listou num arquivo CONTRIBUTING. Mas ele ficava na porta de entrada de todo projeto e cumpria a única função que processo nenhum a jusante consegue cumprir: mantinha a taxa de chegada de contribuições mais ou menos proporcional à atenção humana disponível para julgá-las. Quem se dispunha a gastar duas noites num patch já havia demonstrado, só por esse ato, intenção, alguma compreensão da base de código e um motivo para responder perguntas depois. A capacidade de revisão nunca foi dimensionada pelo tamanho do espaço de problemas. Foi dimensionada pelo custo de entrada.

Remova o custo de entrada e todo processo construído sobre ele passa a operar fora da faixa para a qual foi calibrado. Esse mecanismo é o que merece discussão, acima do volume, porque é ele que determina quais correções podem funcionar.

Capacidade Não Se Recupera a Jusante

Já contamos a história do volume por vários ângulos: a enxurrada de relatórios sobre o curl, governança de mantenedor depois do incidente do Bun e verificação virando o trabalho de fato. Todos esses textos, os nossos incluídos, recorrem à mesma classe de resposta: ampliar a capacidade de julgar. Mais revisores. Triagem melhor. Agentes de revisão. CI mais rápido.

Olhe o que essa resposta pressupõe sobre a aritmética. Um submissor com um modelo produz um patch de 4.000 linhas numa tarde. Eischmann descreve exatamente isso: um pull request no gvfs reintroduzindo suporte a Google Drive, claramente gerado por IA, funcional em nível básico e ainda assim exigindo revisão linha por linha, porque “funcional em nível básico” não é padrão que alguém coloca em produção. O suporte a Google Drive havia sido removido no GNOME 50 justamente por falta de mantenedor. O patch não forneceu o mantenedor que faltava. Forneceu mais trabalho para o mantenedor que já estava ausente.

O segundo exemplo é mais afiado. Um pull request no Meshy adicionando suporte a macOS: 9.000 linhas alteradas, das quais “vários milhares de linhas eram apenas substituições completamente inúteis de aspas simples por aspas duplas.” Eischmann gastou uma hora revisando. O submissor nunca respondeu.

Essa hora é o número que importa. O custo de produção caiu algo como duas ordens de magnitude. O custo de revisão caiu zero, porque revisar é julgar se código desconhecido está correto, e nenhuma ferramenta mudou muito o preço desse julgamento. Qualquer estratégia que mexa só no lado da revisão está tentando fechar uma divergência de cem vezes com esforço linear. Não fecha. Restaurar a proporcionalidade tem que acontecer onde a proporcionalidade morava, ou seja, no portão de entrada.

O Flathub Precificou o Portão em Quinze Minutos

O Flathub distribui “vários milhares” de aplicativos. A contagem de Eischmann para as pessoas que cuidam das revisões de submissão: três. Pela aritmética acima, isso deveria ser uma catástrofe. Não é, e a razão é uma decisão de design que quase ninguém copiou.

Para colocar um aplicativo no Flathub você abre um ticket de inclusão. O ticket faz um conjunto curto de perguntas e exige um vídeo demonstrando o aplicativo efetivamente funcionando. A avaliação de Eischmann: “Realmente não é exigente, e qualquer pessoa consegue montar isso em 15 minutos. Ainda assim, até isso é esforço demais para criadores de slop de IA.”

Quinze minutos de esforço irredutivelmente humano, aplicados na entrada, defenderam uma fila que três pessoas conseguem drenar. É o controle antislop mais barato que alguém já publicou, e funciona por motivos que vale enunciar com precisão:

• Não pode ser delegado à própria coisa que causa o volume. Um modelo escreve o patch. Ele não grava a captura de tela de um software rodando numa máquina, o que exige compilar, instalar e olhar.
• O preço fica abaixo do limiar do contribuidor legítimo e acima do limiar do submissor automatizado. Quinze minutos são nada para quem quer o próprio aplicativo distribuído. São fatais para um fluxo cuja economia inteira depende de custo marginal zero por submissão.
• Produz evidência que o revisor usa. A demonstração já é a primeira linha da revisão, pronta, feita pela única parte que deveria fazê-la.
• Falha de forma explícita. Sem vídeo, sem ticket. A recusa dispensa leitura de diff e dispensa discussão.

Compare com a resposta que a maioria das organizações está construindo: um documento de política pedindo que contribuidores declarem uso de IA e expliquem o próprio código. O Kubernetes seguiu esse caminho, e cobrimos o caso em responsabilidade por contribuição com IA. Regras de declaração valem a pena. São também autodeclaradas, não verificáveis, e custam nada ao submissor para serem satisfeitas. Um piso de esforço é verificável por construção: ou o artefato existe, ou não existe.

Generalize: Contribuição Interna e Entrega de Fornecedor

O padrão transfere direto, e dois lugares numa empresa normal precisam dele neste trimestre.

Política de contribuição interna. Escolha os repositórios em que um merge ruim é caro e prenda um piso de esforço ao template de pull request. Não uma checklist mais longa. Um questionário curto (o que quebra se isto estiver errado, o que você rodou para se convencer de que funciona) mais uma gravação ou transcrição de terminal mostrando a mudança funcionando contra algo real. Dois minutos de vídeo do autor poupam vinte minutos do revisor reconstruindo intenção, e é o único artefato que quem não leu o próprio diff é incapaz de produzir.

Submissões de fornecedores e terceirizados. Toda entrega que chega como pull request de fora da folha de pagamento deve carregar o mesmo pedágio, escrito no contrato. Fornecedores são a população com o incentivo mais forte para inflar contagem de linhas e o incentivo mais fraco para mantê-las revisáveis.

Eischmann também entrega aos revisores uma lista de cheiros útil para os diffs que chegam. Reescrita em massa de estilo sem relação com o objetivo declarado. Edições fora do escopo declarado. Mudanças sobrescrevendo trabalho recente da branch principal. Qualquer um desses justifica fechar um pull request em menos de um minuto, e autoridade do mantenedor para recusar rápido é metade do controle. O piso de esforço reduz as chegadas; a recusa rápida evita que o resto consuma atenção que não conquistou.

O Repositório Curado Está Voltando

A previsão de Eischmann é a parte que deveria despertar quem passou uma década em ecossistemas de pacotes: “é possível que fontes curadas de software, como os repositórios de distribuições Linux, voltem.” Tratávamos curadoria como problema resolvido e abandonado. Repositórios de distro perderam para gerenciadores de pacotes de linguagem e app stores precisamente porque curadoria era lenta, opinativa e cara. Esse custo agora é uma vantagem. Um porteiro que diz não vale ser pago quando a alternativa é submissão ilimitada.

Dois efeitos de segunda ordem apontam na mesma direção. O comportamento com dependências está migrando para vendoring e reescrita, pela lógica que Eischmann nomeia: “por que depender de uma biblioteca externa grande quando você não precisa nem de 10% da funcionalidade dela.” E o mecanismo de aplicação do copyleft enfraquece quando um modelo lava uma implementação GPL dentro de uma base proprietária, já que a obrigação sempre foi disparada por cópia rastreável. Demos uma primeira passada nisso em software livre na era dos agentes. A linha de tendência comum aos três é um recuo do compartilhamento aberto e sem atrito na direção de perímetros menores e confiáveis.

O problema de sucessão é o de cauda mais longa. Eischmann: “Software de código aberto nunca foi apenas sobre o resultado final; era também sobre o processo. Isso contrasta fortemente com o mundo da IA, onde tudo é sobre o resultado.” A revisão era como mantenedores eram formados. Um contribuidor aprendia a base de código sendo corrigido em público ao longo de meses. Um pipeline processando patches anônimos de 9.000 linhas de submissores que nunca respondem não produz sucessores. Scott Powell, fundador do MeshCore, citado por Eischmann, resumiu o sentimento sem rodeios: “Então, vejo o código aberto, na era da IA, como oferecer seu sangue, suor e lágrimas para que outros o explorem, de inúmeras formas.”

A previsão de Eischmann não é pessimista, e merece ser citada ao lado do resto: “a segurança geral do software de código aberto mantido vai melhorar, e o ecossistema se beneficiará no fim.” A palavra “mantido” carrega a frase. É uma afirmação sobre projetos que ainda têm alguém no portão.

Faça Isto Agora

Pegue seus três repositórios mais consequentes. Para cada um, responda uma única pergunta: o que um submissor precisa gastar antes de um humano gastar qualquer coisa?

Se a resposta for “nada”, instale o piso esta semana. Um formulário de cinco perguntas e uma gravação obrigatória da mudança funcionando, aproximadamente quinze minutos do tempo de quem submete, cobrados como requisito de merge em vez de pedido. Coloque a mesma cláusula no próximo contrato de fornecedor que você assinar. Depois dê aos revisores autoridade escrita e explícita para fechar, sem discussão, qualquer pull request que apresente reescrita em massa não relacionada, edições fora do escopo declarado ou sobrescrita de trabalho recente da branch principal.

Quinze minutos na entrada é um controle leve. Foi o único que sempre funcionou, e por trinta anos ninguém precisou instalá-lo de propósito.

---

Fontes

• Jiří Eischmann. “How AI Is Changing Open Source.” Julho de 2026.
• The Pragmatic Engineer. “The Pulse: New trend, concern about massive increase in code review load.” Julho de 2026.

A Victorino ajuda organizações de engenharia a desenhar portões de contribuição e controles de revisão que sobrevivem ao volume de submissão em velocidade de máquina: contato@victorino.com.br | www.victorino.com.br