Nesta semana (pelo menos) duas discussões sobre IA chamaram a atenção no mundo do software livre e de código aberto: Codeberg baniu código escrito (majoritariamente) por LLMs da sua plataforma, e a comunidade Debian está em um processo de tomada de decisão muito parecido (com desfecho desconhecido até o momento).

Lendo alguns artigos comentando sobre o caso do Codeberg, comecei a encontrar palavras para algo que realmente me incomoda nesse debate: as pessoas estão usando escrito por IA como um indicador para presumir qualidade no software.

E esse é um péssimo indicador para isso. Eu tinha essa sensação há meses, mas só encontrei as palavras para explicar isso hoje.

Uma história do final de 2025

Eu estava lendo este artigo quando a ficha caiu. Gostei da leitura (mesmo discordando de muitas das opiniões dele). O texto me lembrou de algo que escrevi há mais de meio ano, quando alguém enviou um PR que era um vibecode de baixíssima qualidade para um projeto que eu mantenho, um projeto com mais de 1.000 estrelas no GitHub.

Aquele PR específico tinha um cheirinho de coisa errada. A descrição parecia slop: idioma diferente de todas as outras contribuições do projeto, cheio de subcabeçalhos, papo de vendedor hiperverboso sobre a contribuição em si. Não tenho certeza agora — e o GitHub não está carregando — mas provavelmente estava cheio de emojis e travessões. Mas eu amo travessões, que fique claro.

De qualquer forma, dei uma olhada no código e apostei mentalmente que ele não iria funcionar. Ele sugeria consertar uma issue que havia sido dividida em 5 sub-issues. E o código era provavelmente curto demais para levar tudo isso em consideração — não que linhas de código signifiquem muito, mas eu conseguia ver que faltavam algumas abstrações que eu esperava. Então minha sensação era de que havia partes importantes faltando, talvez uma implementação ingênua? Não sei. Então decidi rodar o código e, obviamente, estava quebrado.

Essa foi a minha resposta àquele PR, àquela tentativa frustrada de carregar milhões de registros em um banco de dados (o cerne do problema que ele estava supostamente resolvendo):

Serei franco com você: este PR me passa um ar de vibecoding, e não no bom sentido. Há partes da descrição e do código que definitivamente não fazem parte da implementação sugerida nestes commits. Não me surpreende ver que rodar o seu branch não carrega um único registro no banco de dados (logs do console abaixo, no final da minha mensagem). Essa situação me faz crer que o que deve ter ocorrido é o seguinte:

O código e a descrição podem ser algo que nenhum ser humano se deu ao trabalho de escrever e, para piorar, nenhum ser humano talvez tenha sequer lido isso tudo antes de abrir o PR aqui. E isso é muito prejudicial.

Manter código aberto é tão difícil quanto exigente, e se a ideia não é ajudar, pelo menos tente não atrapalhar as pessoas que mantêm. Vibecoding é potencialmente prejudicial porque atrapalha. Vamos supor que alguém não escreva ou não leia uma contribuição antes de enviá-la a outra pessoa. Nesse caso, essa pessoa está exigindo tempo de quem mantém o projeto para fazer o trabalho que ela mesma se recusou a fazer, o trabalho que ela delegou totalmente a LLMs.

Eu não vou deixar isso acontecer neste projeto. Portanto, vamos conversar e ver como posso ajudá-lo a contribuir com esta comunidade dado o seu interesse no projeto.

Fico muito feliz que você tenha enviado a tua contribuição. Antes de prosseguirmos e de eu revisar este PR, por favor, revise a descrição e o código mais uma vez para garantir que eles sejam consistentes e descrevam com precisão o que estes commits implementam. Além disso, há muito desse trabalho já em andamento em outro PR, e seria maravilhoso se esses esforços fossem alinhados, ou se pudéssemos discutir as diferentes abordagens sugeridas lá e cá para considerar qual funcionaria melhor a curto e longo prazo.

Ficarei mais do que feliz em apoiá-lo e responder a quaisquer perguntas que você possa ter. Mas quero ter certeza de que estamos na mesma página: não vamos permitir que os LLMs roubem nosso tempo.

Para reproduzir minha resposta aqui, eu modifiquei levemente o texto acima para omitir detalhes desnecessários (e eliminar alguns erros de digitação). Mas o cerne desse argumento é o que voltou à tona hoje.

Chega de 2025, voltemos aos assuntos do momento

Entendo os esforços do Codeberg para "proteger" a comunidade e estou muito animado que uma das propostas em pauta para a comunidade Debian toque exatamente nesse mesmo argumento, porque somos humanos — devemos ser responsáveis pelas contribuições que fazemos:

As pessoas que contribuírem assumem total responsabilidade por suas contribuições, incluindo garantir o mérito técnico, a segurança, a conformidade com as licenças e a utilidade de seus envios. A pessoa que contribuir permanece como a única responsável por todas essas contribuições. Elas devem compreender totalmente as alterações propostas e estar preparadas para justificá-las.

No projeto do PR que usei como exemplo, mais tarde, adicionei uma diretriz ao guia de contribuição com base na política de contribuição do Fedora: o código enviado deve ser algo que você testou, compreende e é capaz de discutir sobre a implementação, abstrações e testes sugeridos.

Na minha opinião, e com base na minha experiência, essa mentalidade realmente faz a diferença. Trabalhei em empresas onde as pessoas ficavam animadas abrindo PRs sem sequer ler o código (talvez nem mesmo o compreendessem). Obviamente, o resultado era: bugs. Bugs para todo lado.

Assim que as coisas quebravam, era um caos, principalmente porque muitas vezes o sistema que pagava o preço de uma implementação mal feita não era onde estava o PR problemático. LLM não consegue levar em conta todo contexto onde está escrevendo código, o que não é surpresa para ninguém. Por exemplo, um bug em um consumidor pode causar um gargalo bloqueando um produtor; então a equipe que trabalhava no produtor era acionada, mas tinha pouco ou nenhum contexto sobre o que acabara de ser implementado no consumidor.

Em lugares como esse, normalmente as revisões de código também eram problemáticas: milhares de linhas de código alteradas e, se eu tivesse uma dúvida, as pessoas simplesmente respondiam com não tenho certeza, a IA escreveu assim. Isso era terrível. Mas isso não é um problema da IA; isso é um problema humano, um problema de cultura, principalmente de responsabilidade e de comunicação.

É por isso que acredito sinceramente que mirar nos LLMs não é eficaz para melhorar a qualidade do software. A qualidade do software vem da colaboração entre humanos, e não apenas da colaboração entre engenheiros de software. Envolve toda a cultura na qual a pessoa está programando, com ou sem IA: como o sucesso é medido (se for o caso), quais são a pressão e os incentivos para escrever aquele software, quais são os pontos de dor para a entrega, etc. E como todos os envolvidos negociam todas essas tensões.

A IA tem toneladas de problemas, e aprecio muito o blog do Codeberg porque ele toca em vários deles: da ecologia à moralidade, incluindo os preços de equipamentos e serviços. É uma loucura! Mas eu ainda me recuso a usar o escrito por IA como um indicador para qualidade. Prefiro criticar a IA pelas maneiras como ela pode ser potencialmente prejudicial, e essa é uma construção sociotécnica, não uma questão de qualidade de software. Requer uma perspectiva complexa, social e cultural que um simples vamos banir a IA não consegue dar conta. Trata-se de como tomamos decisões sobre software em nossa sociedade, não sobre como de fato escrevemos código.

Como disse Evan Czaplicki (em um contexto completamente diferente, para que eu não falte com a honestidade aqui), código é a parte fácil — o desafio é entender como nos organizamos e como organizamos nossos valores em torno dele.