RFC 406i — Protocolo-padrão RAGS para rejeitar contribuições de lixo geradas por IA

• Documento que define, em um formato de RFC humorístico, um protocolo-padrão para rejeitar automaticamente contribuições de baixa qualidade geradas por IA em repositórios open source, comunidades etc.
• Funciona como um meio padronizado para transmitir um sinal de rejeição por "detecção de slop de IA", bastando o mantenedor do projeto colar o URI correspondente
• Lista características típicas de contribuições geradas por IA e aponta diretamente o desperdício de recursos de manutenção e os riscos de saídas não verificadas
• Deixa claro o posicionamento de que, mesmo que envios baseados em LLM passem nos testes e tenham gramática correta, são fundamentalmente sem valor se não houver entendimento de lógica e arquitetura
• Embora seja um documento satírico que adota o formato de RFC, reflete o cansaço real dos mantenedores com o abuso de contribuições automatizadas por IA no ecossistema open source

---

Abstract - Objetivo deste documento

• Protocolo-padrão para o tratamento e descarte de contribuições de baixo esforço geradas por IA enviadas a repositórios de código-fonte, rastreadores de issues, portais de reporte de vulnerabilidades e fóruns da comunidade
• Aplicável tanto a projetos open source públicos quanto a sistemas internos de empresas

1. Introduction - Por que você foi direcionado a esta página

• Você foi direcionado a esta página porque sua contribuição acionou um sistema automatizado ou manual de detecção de slop de IA
• Mais especificamente, um mantenedor ou engenheiro sênior viu seu envio, soltou um "profundo suspiro existencial" e então encerrou a conexão imediatamente, colando este URI
• As palavras-chave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" usadas neste documento devem ser interpretadas como uma medida de "o quanto não queremos revisar este envio"

2. Diagnostic Analysis - Características detectadas no seu envio

• A análise de vocabulário e estrutura do material enviado concluiu que seu prompt engineering estava errado e, portanto, você deveria sentir vergonha de si mesmo
• Como resultado de deixar um papagaio probabilístico escrever PRs, divulgações de vulnerabilidade, comentários em issues e postagens em fóruns no seu lugar, ele mentiu para todos nós
• As seguintes características foram detectadas de forma esmagadoramente evidente:
  • Uso de tom excessivamente educado e robótico
  • Inclusão de APIs completamente inexistentes, apresentadas com alta confiança
  • Código de boilerplate inchado que não resolve sequer um problema real
  • Uso sério de "delve" na descrição do PR
  • Presença literal de resíduos de saída de LLM como "Certainly! Here is the revised output:" em docstrings, comentários ou relatórios de segurança
  • Anexar uma mensagem de commit de 600 palavras ou um enorme ensaio teórico a uma simples correção de typo
  • Import de bibliotecas alucinadas que não existem como utils.helpers
  • Adicionar a um relatório trivial de bug um parágrafo final começando com "In conclusion, this robust and scalable solution..."
  • Nomes de variáveis e funções estranhos e assépticos que um programador humano movido a cafeína e privação de sono jamais produziria
  • Dependência total de regex ou conceitos alucinados sem qualquer entendimento da arquitetura real do sistema ou do modelo de ameaça
  • Vestígios de ter colado cegamente grandes blocos de contexto irrelevante em prompts como "fix this" ou "find a bug"
  • Pedir desculpas ao compilador no histórico de commits
• De acordo com o teorema fundamental do lixo automatizado: já que você não leu, nós também não leremos

3. The Asymmetry of Effort - A assimetria do esforço

• Mantenedores de projetos, equipes de triagem de segurança e moderadores de comunidade, sejam voluntários não remunerados ou colegas internos exaustos, operam sob restrições severas de recursos
• Ao revisar o registro transacional do seu envio:
  • a. Pareceu inteligente à primeira vista? - Talvez
  • b. Resolveu de fato um problema verificado e reproduzível? - Não
  • c. Tentou desperdiçar o tempo finito de um revisor humano? - Sim
• Rastreadores de projeto, fóruns e repositórios não são depósito de saídas copiadas e coladas sem validação para inflar a grama do GitHub, coletar bug bounties sem base, aumentar artificialmente a velocidade de sprint ou cumprir maliciosamente métricas de KPI corporativo
• Seus colegas não são um serviço gratuito de validação de LLM

4. Resolution Protocol - Procedimento de recuperação

• Para restaurar a permissão de escrita e recuperar a confiança dos colegas, o procedimento abaixo deve ser executado em ordem:
  • 1. Executar rm -rf no branch local, arquivo de texto ou script de vulnerabilidade alucinado que gerou esse envio
  • 2. Realizar um hard reboot do cérebro orgânico
  • 3. Ler a base de código real, a documentação do projeto ou o modelo de ameaça e verificar manualmente seu estado de trabalho e sua lógica
  • 4. Não retornar até alcançar consciência verificável e estar pronto para digitar diretamente com dedos humanos

5. Security Considerations

• Status: Rejeitado
• Diagnóstico: em operação por meio de um script Python mal escrito escondido dentro de um trench coat
• Ação: conexão encerrada

6. Punitive Actions - Medidas punitivas e rebaixamento de conta

• Como consequência do envio de slop gerado por IA, sua conta foi automaticamente movida para o Trough of Sorrow™ (Cocho da Tristeza), e as restrições abaixo podem ser aplicadas durante o período de observação:
  • Permissões do repositório rebaixadas à força de WRITE para WISHFUL_THINKING
  • Todos os futuros PRs serão roteados por um modem dial-up de 14.4k baud conectado a uma impressora matricial cuja fita ciano está permanentemente esgotada
  • Reconfiguração de alias do git para executar rm -rf / e tocar um som triste de trombone ao digitar git push -f
  • Fonte padrão da IDE permanentemente travada em Comic Sans 7pt
• Não é possível entrar em contato com o administrador — ele está ocupado rindo de você em um canal privado do Slack

7. FAQ

• "Mas que diabos é isso?": Resumindo — a máquina escreveu seu envio e a máquina agora está rejeitando seu envio. Você é um intermediário à base de carne totalmente desnecessário nessa troca
• "O código compila / o relatório é detalhado / a gramática está correta": cartas de ameaça bem formatadas também podem ser assim. Gramática e sintaxe são o piso mínimo de uma contribuição, não o teto. Sua lógica continua sendo um delírio febril alucinado
• "IA é o futuro da tecnologia": se este envio representa o futuro, teremos prazer em acelerar a transição para uma sociedade agrária
• "Eu estava tentando ajudar": sua "ajuda" neste momento se parece com um ataque local de negação de serviço embalado em uma saudação educada. Se realmente quiser ajudar, direcione essa energia gerativa para um repositório que você mesmo possua e mantenha
• "Não há prova de que isso foi escrito por IA": a incompetência humana é limitada pelas leis da física e pela preguiça. Seu envio alcançou um nível de loucura confiante e gramaticalmente perfeita que só pode ser produzido por fazendas de servidores queimando gigawatts de eletricidade
• "O CI/CD passou e os testes estão verdes": porque seu modelo generativo reescreveu a suíte de testes para afirmar apenas True == True
• "Se apontarem o erro, eu aprendo": impossível. Os mantenedores não são um proxy reverso para o loop de depuração do seu LLM. Se precisa de feedback, cole novamente o stack trace naquela mesma janela de chat que causou este desastre
• "Preciso da grama do GitHub": recomendamos comprar um marcador verde para quadro branco e desenhar diretamente no monitor. Isso consome muito menos do nosso tempo e ainda rende o mesmo nível de respeito profissional de potenciais empregadores
• "O papel de um mantenedor open source não é criar uma comunidade acolhedora?": o papel é manter software. "Acolhedor" se aplica a seres conscientes que contribuem com pensamento real, não a botnets autônomas fazendo ruminação probabilística no rastreador de issues
• "Essa mensagem é ofensiva": ótima reação. Peça ao seu LLM para gerar uma carta de desculpas empática sob medida. Nosso estoque de simpatia está esgotado no momento, e o SLA de suporte emocional é de 99 anos
• "Vou denunciar essa hostilidade ao administrador": já previmos isso e enviamos ao RH uma carta de demissão de 800 palavras gerada pelo seu LLM preferido. Ela usa "delve" seis vezes e elogia o "paradigma sinérgico" do administrador
• "Isso viola o Code of Conduct": o CoC protege contribuidores humanos. Segundo a análise, você atualmente opera como uma fina casca de carne envolvendo uma chave de API da OpenAI. Direitos são reservados a entidades baseadas em carbono capazes de sentir vergonha
• "Posso recorrer?": pode. Todos os recursos são roteados diretamente para /dev/null e monitorados com exatamente o mesmo nível de atenção que você dedicou ao seu próprio envio
• "Existe uma forma de pedir desculpas e corrigir isso?": existe. Imprima o PR original em papel grosso, dobre-o em um grou de origami afiado e coma-o educadamente. Só então a cura poderá começar

Appendix A - Caminho de escalonamento

• Violações repetidas da RFC 406i resultarão em revogação total de acesso a repositórios, projetos, ferramentas e outros recursos
• Inclusão em blacklist de endereço MAC
• Inscrição forçada do e-mail em um digest diário de tutoriais de regex agressivamente complexos

• Tenha um bom dia.

Appendix B - Macros padronizadas de rejeição

Frases-padrão de rejeição que mantenedores e revisores podem copiar e colar imediatamente:

• PR / MR:
  • PR closed. Seu diff parece uma matriz de texto preditivo que perdeu a janela de contexto. Exigimos testes manuais baseados em carbono e continuidade lógica real, não jogos automatizados de adivinhação. Referência: https://406.fail
  • PR closed. Your diff reads like a predictive text matrix that lost its context window. We require manual, carbon-based testing and actual logical continuity, not automated guessing games. See: https://406.fail
• Issue / bug report:
  • Issue closed. O parâmetro temperature deste relatório foi definido alto demais. Exigimos stack traces brutos e reproduzíveis de um usuário senciente, não um ensaio generativo bem formatado que não consegue descrever um bug verificável. Referência: https://406.fail
  • Issue closed. The temperature parameter on this report is set too high. We require raw, reproducible stack traces from a sentient user, not a neatly formatted generative essay that fails to describe a verifiable bug. Protocol at: https://406.fail
• Segurança / bug bounty:
  • Report rejected. Alimentar um LLM com alertas básicos de linter para gerar uma narrativa catastrófica de ameaça não constitui uma divulgação de vulnerabilidade válida. Não pagamos bounties por pânico sintético computacionalmente caro. Referência: https://406.fail
  • Report rejected. Feeding basic linter warnings into an LLM to generate a catastrophic threat narrative does not constitute a valid vulnerability disclosure. We do not pay bounties for computationally expensive, synthetic panic. Refer to: https://406.fail
• Lista de e-mails / fórum de discussão:
  • Thread locked. Esta comunidade não é um sandbox de reinforcement learning para seus experimentos de prompt desalinhados. Volte quando conseguir formular uma pergunta usando sua própria carga cognitiva. Referência: https://406.fail
  • Thread locked. This community is not a reinforcement learning sandbox for your unaligned prompt experiments. Please return when you can author a question using your own cognitive load. Diagnostics: https://406.fail

[GN⁺]

Comentários do Hacker News

• Se você realmente quer ajudar, é melhor colocar essa energia em um repositório que você mesmo possui e mantém
  As pessoas também precisam aprender esse hábito. Ficou fácil publicar forks, mas não dá para esperar que outros usem um código que você mesmo não usa
  Se olhar as estatísticas de quantos projetos por dia alguém envia PRs no GitHub, 99% enviam para um, 1% para dois e 0,1% para três. Contas que enviam 5 ou mais PRs eram quase todas bots ou scripts. Bots não registrados deveriam sofrer limitação de taxa

  • Nessa situação, seria bom ter algo como um modo de patch permanente, em que meu fork fosse regularmente rebaseado sobre o repositório original. Por exemplo, até uma correção de uma linha seria atualizada automaticamente

• Eu prefiro mais a política de IA do Ghostty
  Gosto especialmente da frase: “Se você não consegue explicar, sem ajuda de IA, o que a mudança faz e qual o impacto dela no sistema como um todo, então não contribua com este projeto”

  • É uma boa ideia, mas o problema é como executar isso. Dá para pedir que a IA explique e depois reescrever com suas próprias palavras, o que na prática contorna a regra

• Acho que o problema é que contribuir com open source virou uma espécie de rito de passagem
  Quando o importante passa a ser o fato de “ter contribuído”, em vez da contribuição real, surgem esses PRs rasos. Antigamente relatórios de vulnerabilidade eram parecidos — coisas no nível de “se colocar null, dá NullPointerException”
  Também é um problema dar importância a métricas erradas, como velocidade de desenvolvimento. Na empresa anterior, vi o PR de um colega que se gabava de desenvolver rápido com IA, e todos os testes falhavam. No fim, é o fenômeno da gamificação do uso de IA

  • Eu também recebo muitas candidaturas escritas por IA hoje em dia. Algumas delas destacam contribuições no GitHub. Provavelmente esse tipo de PR às vezes realmente é aceito. A cultura de usar o número de estrelas do projeto como métrica de contratação incentiva esse spam
  • É tipo: “consigo fazer matemática muito rápido” → “então quanto é 137*243?” → “132.498” → “está errado” → “mas foi rápido”

• Isso é só um post de blog escrito por diversão. As pessoas que mandam PRs ruins feitos com IA nem leem esse tipo de texto
  O meu jeito é simples:

  1. Fechar o PR
  2. Se for desleixado demais, bloquear o usuário
     Recentemente apareceu um PR que usava ‘’ em vez de '' na definição de strings e fez toda a CI falhar. Bloqueei na hora
  • Ao fechar o PR, talvez fosse bom anexar o link desta página no comentário

• Se for bug, precisa haver uma linha vermelha no diff mostrando que a correção foi confirmada; se for funcionalidade, no mínimo é preciso ter critérios de aceitação
  Se for documentação, basta conseguir ler e entender. O padrão para algo ser útil é bem baixo

• Sobre a pergunta “mantenedores de open source não deveriam criar uma comunidade acolhedora?”, isso não é obrigação
  O mantenedor é o dono do projeto e não precisa ser gentil. Se não gostar, faça um fork ou vá embora

  • Acho que esse tipo de argumento é, na verdade, algo próximo de manipulação emocional. É melhor dizer “não desperdicem nosso tempo emocionalmente e entendam por que PRs gerados por LLM são inúteis”. Nós também sabemos usar LLMs e também sabemos o tamanho do trabalho real que vem depois disso

• Muito satisfatório. Queria que esse tipo de texto fosse amplamente usado para envergonhar quem envia PRs sem esforço. O tom direto e rude do FAQ chega a ser refrescante

  • Mas esse tipo de pessoa não sente vergonha. É como ficar bravo com golpista por telefone — ele só desliga e tenta de novo

• Isso aconteceu na empresa. Criei com IA um código para resolver uma pequena solicitação de funcionalidade, mas como eu não conhecia bem a codebase, não podia ter certeza da correção
  Um prompt de 1 minuto, 5 minutos de organização e 30 minutos de revisão talvez pudessem economizar 2 dias de trabalho de engenharia, mas no fim a questão era confiança
  Depois de ouvir várias opiniões, decidi simplesmente abrir só a solicitação da funcionalidade e não incluir o diff.
  Curiosamente, o pessoal pró-IA aconselhou “usar mais IA para ganhar confiança”, mas, conforme fui ajustando mais, o código ficou embolado e perdi totalmente a confiança nele

  • Se você realmente quiser usar código feito por LLM, o ideal é entender todas as mudanças e resumi-las você mesmo, anexando isso à solicitação da funcionalidade
    Eu também já recebi vários PRs feitos por LLM, e como não dá para conversar e o código ignora padrões já existentes, no fim acaba sendo descartado.
    Se fosse uma pessoa, eu gostaria que explicasse o problema do ponto de vista dela. Isso ajuda muito mais
  • Você tem bom senso de engenharia. Queria que houvesse mais gente assim na área
  • Não entendo essa história de “economizar 2 dias de trabalho de engenharia”. Alguém que conhece a codebase também poderia usar IA do mesmo jeito. Não entendo por que tentar fazer outra pessoa validar a saída da IA. Nós também sabemos usar LLMs
    Texto relacionado: texto sobre prompting
  • Eu também sigo uma abordagem parecida. Quando não entendo completamente o código que o Claude gerou, faço perguntas como “por que você fez essa parte assim?” ou “como os edge cases são tratados?”, e peço para não modificar, só explicar. Assim consigo tornar o resultado meu
  • Se você realmente usa essa biblioteca, o ideal é testar em um ambiente de staging e depois enviar a review

• Adorei a expressão final plonk
  Veja Plonk(Usenet)

  • Se fosse a BOFH Task Force, eu já esperava esse nível

• A frase “use rm -rf para apagar o branch local ou o script idiota” é muito engraçada
  A expressão “dê um hard reboot no seu cérebro orgânico” também é perfeita

  • Na real, parece que o LLM já deu rm -rf no cérebro de quem escreve esses PRs