Contribuições bem-sucedidas para projetos de código aberto são uma espécie de moeda. O Git Hub em particular incentiva isso de várias maneiras: mostrando avatares de contribuidores nas páginas de repositórios, mostrando suas contribuições aos seus seguidores através do feed de atividades e sinalizando contribuições por dia no gráfico de atividades do seu perfil. Gerentes de contratação em potencial frequentemente notam isso.

Recrutadores frequentemente encontram e selecionam candidatos dessa forma. Se você é um desenvolvedor de software (existente ou aspirante) procurando trabalho, ajustar esses sinais pode frequentemente trabalhar a seu favor. Como mantenedor de código aberto, é bastante perceptível como o padrão de contribuições externas mudou no último ano.

Estamos muito mais propensos a receber pull requests em vez de issues. Se recebemos issues, elas frequentemente vêm com uma análise gerada por IA anexada. Estamos recebendo muito mais relatórios de vulnerabilidades de segurança do que nunca e, frequentemente, eles até vêm com propostas de correção geradas por IA anexadas.

Não duvido que algumas dessas contribuições venham de pessoas que estão genuinamente interessadas no que fazemos, mas a parte cínica de mim acredita que uma quantidade substancial disso é porque as pessoas estão percebendo que a IA pode ser usada para manipular o Git Hub em seu próprio benefício. Agora é fácil pedir ao Claude para gerar uma lista de projetos de código aberto interessantes, depois pedir ao Claude para encontrar alguns problemas neles e, em seguida, pedir ao Claude para levantar alguns PRs para corrigi-los. Você nem precisa usar os projetos ou se importar com eles, mas pode facilmente criar a ilusão para os estranhos de que você se importa, ou de que encontrou um problema, ou de que dedicou tempo para corrigi-lo.

Na internet, ninguém sabe que você é um cachorro, mas com a ajuda dos LLMs, você pode sem esforço exagerar suas habilidades humanas no seu perfil do Git Hub. Recentemente, um contribuidor com praticamente nenhuma contribuição no Git Hub desde o final de 2018 até algumas semanas atrás, sem engajamento prévio com nosso projeto que conheçamos, levantou três PRs separados para corrigir erros de ortografia e gramática em comentários. Claude fez as correções, presumivelmente escreveu as descrições dos PRs, até assinou os commits em nome do usuário e então gentilmente inseriu sua co-autoria nos trailers das mensagens de commit.

Talvez até tenha aberto os PRs ele mesmo, quem sabe. Eu ficaria fascinado em saber se o prompt era para "ir e encontrar problemas" ou se focava em problemas de ortografia e gramática em particular por qualquer razão. As mudanças foram inofensivas e corretas, mas isso não me fez sentir melhor em aceitar ou mesclá-las.

Em vez disso, não pude deixar de me perguntar: por que isso, por que agora? Por que, de todos os issues, TODOs e FIXMEs em nossa base de código, eles estão submetendo isso? E então percebi que essas contribuições não tinham nada a ver com nosso projeto. Fechei os três PRs sem comentário. Talvez isso tenha sido irracional, mas verdadeiramente, simplesmente não estou interessado em encorajar as pessoas a tomarem nosso tempo com esse tipo de trabalho inútil.

Não quero criar um precedente de aceitar PRs que materialmente não melhoram nada, nem quero que nossa lista de contribuidores se torne uma recompensa por pedir a um robô para corrigir erros de digitação. O mesmo padrão surgiu com os relatórios de vulnerabilidades de segurança. CVEs tradicionalmente creditam seus relatores, mas todos os relatórios que recebemos recentemente foram obviamente gerados por IA.

Correções de segurança são sempre importantes, claro, mas novamente me pego pensando se isso está acontecendo porque as pessoas se importam com as correções ou porque estão procurando um crédito fácil. Temos sido muito mais seletivos ultimamente ao avaliar a severidade de tais relatórios e, em alguns casos, recusando emitir avisos CVE para itens de baixa severidade. Tenho alguns sentimentos sobre o fato de que a divulgação privada está morrendo de qualquer forma, sobre o qual posso escrever em outra ocasião, mas o esforço envolvido em coordenar correções privadas, avisos de divulgação e lançamentos é substancial o suficiente para exigir que sejamos seletivos.

Em última análise, o código aberto é construído sobre confiança.