Filtro de triagem de PRs para mantenedores de OSS sobrecarregados
Um gate de CI que pontua e filtra PRs de baixo esforço ou gerados em massa por IA antes que consumam o tempo de revisão dos mantenedores de software open source.
I want to build a small, bootstrappable product. Help me plan and start the MVP.
Product: PR triage gate for overwhelmed OSS maintainers
What it is: A CI gate that scores and filters low-effort/AI-dumped PRs before they consume open-source maintainer review time.
Who pays: Maintainers and engineering leads at funded open-source projects and foundations (e.g., projects like Plotly, QGIS-scale, or corporate OSS offices) with an infrastructure/community budget, paying $200–800/mo for CI add-ons.
Closest alternatives: CodeRabbit, GitHub Copilot code review, Greptile, human triage / stale-bot automation
The gap: Existing AI reviewers review code quality; none act as a maintainer-side contribution gate that enforces a project's declared AI policy, flags low-effort/unverifiable submissions, and requires submitter-side proof (repro, test, video walkthrough) before any human time is spent.
Why now: The LLM contribution flood is a 2025–26 phenomenon: major projects (QGIS now, others considering) are enacting blanket bans as a stopgap precisely because no tooling exists to ration reviewer attention, and maintainers publicly say they'd rather keep contributing open if filtering were cheap.
Moat to build toward: Policy-as-code rule sets tuned per project plus accumulating labeled data on low-effort vs. genuine contribution patterns across many repos; workflow lock-in once embedded in a project's merge pipeline.
Um briefing pronto para colar no Claude Code, Cursor ou qualquer agente de programação (em inglês).
A favor
- EX.1O QGIS proíbe formalmente contribuições de IA porque o volume de PRs gerados por IA supera a capacidade de revisão humana e corrói a confiança dos revisores.Do artigo ↗
- EX.2Um mantenedor do Plotly descreve relatórios de issues de 3 páginas gerados por IA, sem revisão ortográfica, e PRs plausíveis mas fracos consumindo o tempo dos revisores, o que os leva a deixar de lado contribuintes eventuais.Ler o comentário ↗
- EX.3Um comentarista explica a assimetria de volume: a IA permite que contribuintes de baixo esforço gerem conteúdo 100 vezes mais rápido do que os mantenedores conseguem avaliar, e a maior parte é sutilmente ruim.Ler o comentário ↗
- EX.4O gargalo deslocou-se da escrita de código para a verificação de alinhamento, ou seja, para ter certeza de que uma mudança faz o que se pretendia, e isso é pior justamente nos PRs de desconhecidos.Ler o comentário ↗
O excesso de contribuições geradas por LLMs é um fenômeno de 2025 e 2026: grandes projetos (o QGIS agora, e outros avaliando) estão adotando proibições generalizadas como medida paliativa justamente porque não existe ferramenta para racionar a atenção dos revisores. Mantenedores afirmam publicamente que preferiam manter o projeto aberto se a triagem fosse barata.
Contra
O excesso de contribuições por LLMs é um problema novo, medido e que está levando grandes projetos a proibições generalizadas. Revisores de IA existentes analisam código, e não aplicam uma política de contribuição do lado do mantenedor. É uma lacuna real, embora monetizar mantenedores de OSS continue sendo o elo mais fraco.
Conjuntos de regras como código, ajustados por projeto, somados a dados rotulados sobre padrões de contribuição de baixo esforço versus genuínos em muitos repositórios. Há também lock-in do fluxo de trabalho uma vez que a ferramenta esteja no pipeline de merge do projeto.
Os revisores de IA existentes avaliam a qualidade do código; nenhum atua como um gate do lado do mantenedor que aplique a política de IA declarada por um projeto, sinalize submissões de baixo esforço ou não verificáveis e exija do autor provas (reprodução, testes, vídeo explicativo) antes de qualquer tempo humano ser gasto.
Construa em 3 passos
- 1Construir uma GitHub Action que pontue PRs recebidos com base em sinais de esforço (testes incluídos, issue vinculada, passos de reprodução, histórico do autor, razão entre diff e tamanho do PR, heurísticas de estilo de IA) e solicite automaticamente as provas faltantes antes da revisão humana
- 2Disponibilizar um arquivo de configuração de política (YAML) para que os projetos declarem sua política de IA e de contribuição, e o gate a aplique com limites configuráveis
- 3Realizar piloto gratuito com 3 a 5 projetos OSS de porte médio, publicar dados de antes e depois sobre o tempo de revisão dos mantenedores e então cobrar por painéis de equipe e implantação para toda a organização
Traduzido do inglês. Ler o original