Problema
La IA ha reducido el coste de abrir un issue, proponer un parche y responder a una revisión. No ha reducido en la misma proporción el coste de comprobar que el problema existe, entender el cambio, reproducirlo, discutir diseño y mantenerlo durante años.
Ese desacople crea una transferencia silenciosa. El autor genera en minutos una contribución que obliga al maintainer a gastar horas. Si el autor tampoco entiende el código, cada pregunta vuelve al modelo y la conversación consume todavía más atención sin acumular conocimiento en la comunidad.
El repositorio parece más activo. El sistema de mantenimiento está más endeudado.
Tesis
La unidad económica del open source no es el pull request. Es la atención cualificada necesaria para aceptar responsabilidad futura sobre ese cambio.
LLVM denomina contribución extractiva al output que cuesta más revisar de lo que aporta al proyecto. El concepto es más preciso que «AI slop» porque permite gobernar conducta, no adivinar autoría. Un parche humano también puede ser extractivo; uno asistido por IA puede aportar valor si su autor lo entiende, lo prueba y responde por él.
La política correcta no prohíbe herramientas. Devuelve el coste de comprensión a quien propone el cambio.
Framework
Evalúa cada contribución con cuatro contratos:
- Problema: existe, está reproducido y merece prioridad.
- Comprensión: el autor puede explicar enfoque, límites y alternativas.
- Evidencia: pruebas, benchmarks o reproducciones sostienen el cambio.
- Responsabilidad: alguien seguirá presente después del merge.
La regla de LLVM es que una contribución debe valer más para el proyecto que el tiempo que exige revisarla. Su política permite herramientas de IA con humano en el loop, exige transparencia cuando existe contenido generado sustancial y prohíbe agentes que actúan en los espacios del proyecto sin aprobación humana. También protege las etiquetas good first issue como oportunidades de aprendizaje.
Rustup formula una obligación parecida: quien abre el PR debe revisarlo, poder explicarlo con sus propias palabras y no delegar la conversación con maintainers al modelo.
Por que importa ahora
GitHub reconoció públicamente que los maintainers reciben más contribuciones de baja calidad, con frecuencia generadas por IA, y está explorando permisos más granulares, requisitos previos al PR, mejor triage y atribución de asistencia. Python exige que quien use LLM para buscar vulnerabilidades verifique la realidad de cada reporte antes de enviarlo.
Las respuestas convergen porque el problema no es estilístico. Es de capacidad. Cuando crear propuestas se aproxima a coste cero, la apertura total sin filtros puede convertir el tiempo del maintainer en un recurso público que cualquiera consume mediante automatización.
Esto afecta también a empresas. Un equipo interno con diez agentes y dos revisores reproduce la misma economía: producción barata aguas arriba, responsabilidad cara aguas abajo. La política open source funciona como anticipo del operating model corporativo.
Anti-ejemplo
Un bot encuentra cien issues etiquetados como fáciles, genera cien PR y celebra una tasa alta de tests verdes. Cada maintainer debe comprobar si el issue sigue vigente, si el test mide el comportamiento correcto y si el parche encaja con la dirección del proyecto.
El bot no paga el coste de falsos positivos ni mantiene el cambio. Ha externalizado su evaluación a personas voluntarias.
Añadir otro bot que resuma los cien PR no corrige la economía. Sólo comprime la cola.
Protocolo (3 pasos)
- Exige prueba de comprensión. El autor describe problema, decisión, riesgos y evidencia con sus propias palabras.
- Presupuesta revisión. Limita tamaño, concurrencia y áreas sensibles según capacidad real de maintainers.
- Haz reversible la apertura. Usa plantillas, etiquetas, permisos y cierre temprano cuando una contribución no devuelve más valor que atención consume.
| Contrato | Evidencia del autor | Protección del proyecto |
|---|---|---|
| problema | reproducción mínima | no revisar fantasmas |
| comprensión | explicación y alternativas | responsabilidad humana |
| calidad | tests y alcance pequeño | revisión posible |
| transparencia | asistencia declarada | triage informado |
| mantenimiento | owner después del merge | deuda con responsable |
Relacionado
- Más agentes, menos WIP: la capacidad de revisión es el nuevo límite
- Factory 2.0: el ingeniero ya no escala solo código, escala fabricas de software
- Safe Outputs: el patrón para dar trabajo a un agente sin darle permiso de escritura
Fuentes consultadas
- LLVM: AI Tool Use Policy
- GitHub Community: soluciones para contribuciones de baja calidad
- Rustup Developer Guide: AI policy
- Python Developer’s Guide: Security policy
Proximo paso
Mide los últimos veinte PR por minutos de creación y minutos de revisión. Si el segundo número crece mientras el primero cae, fija un contrato de contribución antes de añadir otro agente al repositorio.