Filtro de triaje de PRs para mantenedores de OSS desbordados
Un gate de CI que puntúa y filtra PRs de bajo esfuerzo o generados en masa con IA antes de que consuman el tiempo de revisión de los mantenedores de código abierto.
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.
Un brief listo para pegar en Claude Code, Cursor o cualquier agente de programación (en inglés).
A favor
- EX.1QGIS prohíbe formalmente las contribuciones de IA porque el volumen de PRs supera la capacidad humana de revisión y erosiona la confianza de los revisores.Del artículo ↗
- EX.2Un mantenedor de Plotly describe resúmenes de issues de 3 páginas generados por IA sin revisar y PRs plausibles pero débiles que consumen tiempo de revisión, lo que les tienta a abandonar las contribuciones de colaboradores ocasionales.Leer el comentario ↗
- EX.3Un comentarista explica la asimetría de volumen: la IA permite a colaboradores de bajo esfuerzo generar contenido 100 veces más rápido de lo que los mantenedores pueden evaluarlo, y la mayor parte es sutilmente mala.Leer el comentario ↗
- EX.4El cuello de botella ha pasado de escribir código a verificar la alineación, es decir, asegurarse de que un cambio hace lo que se pretendía, y eso es lo peor en PRs de desconocidos.Leer el comentario ↗
La avalancha de contribuciones generadas con LLM es un fenómeno de 2025–26. Grandes proyectos (QGIS ya, y otros lo están considerando) están aplicando prohibiciones generales como medida provisional precisamente porque no existen herramientas para racionar la atención de los revisores. Los mantenedores afirman públicamente que seguirían aceptando contribuciones abiertas si el filtrado fuera barato.
En contra
La avalancha de contribuciones con LLM es nueva, está medida y empuja a grandes proyectos hacia prohibiciones generales. Además, los revisores de IA existentes evalúan código en lugar de hacer cumplir una política de contribución del lado del mantenedor, así que el hueco es real, aunque monetizar a mantenedores de OSS sigue siendo el punto débil.
Conjuntos de reglas como código (policy-as-code) ajustados a cada proyecto, junto con datos etiquetados sobre patrones de contribución de bajo esfuerzo frente a contribuciones genuinas que se acumulan en muchos repositorios. Una vez integrado en el flujo de merge de un proyecto, el producto genera bloqueo.
Los revisores de IA existentes evalúan la calidad del código. Ninguno actúa como gate del lado del mantenedor que haga cumplir la política de IA declarada por el proyecto, marque envíos de bajo esfuerzo o no verificables y exija pruebas del remitente (reproducción, test o vídeo explicativo) antes de dedicar tiempo humano.
Constrúyela en 3 pasos
- 1Crear una GitHub Action que puntúe los PRs entrantes según señales de esfuerzo (tests incluidos, issue enlazado, pasos de reproducción, historial del autor, relación entre tamaño del diff y del PR, heurísticas de estilo IA) y que solicite automáticamente las pruebas que falten antes de la revisión humana
- 2Publicar un archivo de configuración de políticas (YAML) para que los proyectos declaren su política de IA y de contribución, y para que el gate la aplique con umbrales configurables
- 3Hacer un piloto gratuito con 3–5 proyectos OSS de tamaño medio, publicar datos de tiempo de revisión antes y después, y luego cobrar por paneles para equipos y despliegue a nivel de organización
Traducido del inglés. Leer el original