Armin Ronacher advierte contra los issues redactados por IA

El 24 de mayo, Armin Ronacher —creador de Flask, Jinja2, Rye y figura central del ecosistema Python— publicó un artículo en su blog sobre lo que denomina «PI OSS» (Post-Intelligence Open Source). Simon Willison lo recogió en su weblog el mismo día. El texto no habla de productividad ni de herramientas; habla de un problema concreto que sufren los mantenedores: recibir issues que no fueron escritos por la persona que encontró el bug, sino generados por un modelo de lenguaje con toda la jerga y ninguna de la información útil.

Ronacher lo describe con precisión quirúrgica: el problema observado existe, pero alguien lo metió en «una máquina trituradora» (clanker) que lo reformuló, infló el contexto, añadió hipótesis de causa raíz incorrectas, propuso estrategias de implementación que no vienen al caso y enumeró clases de error que pueden o no ser relevantes. Todo ello redactado con una seguridad que no se corresponde con el conocimiento real del informante.

El problema no es la IA, es la delegación sin criterio

Lo que Ronacher critica no es que alguien use Claude o cualquier otro modelo para mejorar su redacción. Es la delegación completa del pensamiento: la persona que encontró el bug no reflexiona sobre lo que vio, se limita a paste-and-prompt y envía el resultado. El modelo, entrenado para sonar útil y completo, fabrica un informe que parece exhaustivo pero que omite o distorsiona lo único que el mantenedor necesita: qué hizo exactamente el usuario, qué esperaba y qué obtuvo.

La consecuencia práctica es que el mantenedor debe ahora desmontar la narrativa generada para llegar al hecho desnudo, si es que está ahí. En proyectos con alta carga de issues eso es tiempo que no existe.

Su propuesta es sencilla y no requiere ninguna herramienta adicional:

1. Ejecuté este comando.
2. Esperaba que ocurriera esto.
3. Ocurrió esto en su lugar.
4. Aquí está el error o log exacto.

Cuatro puntos. Sin analogías. Sin diagnóstico. Sin sugerencias de implementación que nadie pidió.

Por qué esto importa ahora

El volumen de issues en repositorios activos lleva meses creciendo más deprisa que el número de mantenedores. Con herramientas como Claude Code integrando subagentes capaces de leer repositorios, ejecutar tests y abrir pull requests en nombre del usuario, el riesgo de que la interfaz entre humano y proyecto desaparezca del todo es real. Cuando el agente abre el issue, ¿quién sabe realmente qué pasó?

Esto no es un problema teórico. Proyectos como CPython, Werkzeug o el propio Rye de Ronacher reciben contribuciones de personas con niveles de experiencia muy distintos. Parte del valor del issue tracker es precisamente esa señal humana: la torpeza en la descripción, el detalle aparentemente irrelevante que resulta ser la clave, la pregunta que revela un malentendido en la documentación. Un modelo optimizado para sonar competente elimina esa señal.

Qué pueden hacer los mantenedores (y los usuarios)

Algunos proyectos ya han actualizado sus plantillas de issue para pedir explícitamente que el texto sea del propio autor, no generado. Es una medida fácil de ignorar, pero al menos marca una expectativa.

Desde el lado del usuario, la recomendación implícita de Ronacher es usar la IA antes de abrir el issue, no para redactarlo, sino para entender mejor el problema. Si el modelo te ayuda a aislar la causa, escribe el issue tú mismo con esa información. Si no logras aislarlo, describe lo que observaste sin inventar causas.

Para quienes trabajan con Claude Code en flujos de desarrollo propios, vale la pena revisar si algún hook o subagente del pipeline está abriendo issues automáticamente en nombre del equipo. La automatización tiene sentido para tareas repetibles y bien definidas; el reporte de un bug encontrado en producción raramente lo es.

---

El artículo de Ronacher no pide que nadie deje de usar IA. Pide que los humanos sigan siendo los responsables de lo que firman. Es una distinción que el ecosistema open source va a tener que aprender a defender, porque los mantenedores no tienen por qué asumir el coste de la comodidad ajena.