Ladybird cierra sus PRs públicos: ¿la respuesta más honesta al código generado por IA?

El pasado 5 de junio, Simon Willison recogió en su blog una cita de Andreas Kling, fundador del proyecto de navegador independiente Ladybird, que resume con bastante precisión un dilema que muchos mantenedores de proyectos open source están empezando a enfrentar en voz alta: la IA ha roto una de las heurísticas más antiguas del software libre.

La decisión es directa: Ladybird deja de aceptar pull requests públicos. A partir de ahora, solo contribuyen al código personas que el equipo haya incorporado de forma explícita. No es una medida provisional ni está abierta a debate.

El esfuerzo ya no garantiza buena fe

Durante décadas, un parche grande era señal implícita de que alguien había invertido tiempo real y tenía un interés genuino en el proyecto. Esa correlación ha desaparecido. Como explica Kling en su entrada original:

> «Un parche sustancial solía implicar un esfuerzo sustancial, y ese esfuerzo era un indicador razonable de buena fe. Esa suposición ya no se sostiene.»

El problema no es que el código generado por IA sea necesariamente malo. El argumento de Kling es más matizado: lo que importa no es cómo se escribió el código, sino quién asume la responsabilidad una vez que entra en el proyecto. Ladybird está dejando de ser un experimento y convirtiéndose en un navegador para usuarios reales. En ese contexto, la trazabilidad de responsabilidades pesa más que la apertura del proceso de contribución.

> «Si el código fue escrito a mano es irrelevante. Lo que importa es quién es responsable de él una vez que entra en el navegador.»

Un síntoma que se repite

Ladybird no es el primer proyecto que reacciona así. Desde 2024 hemos visto a varios mantenedores endurecer los requisitos de revisión, añadir políticas explícitas sobre contribuciones asistidas por IA o directamente cerrar issues por avalancha de reportes generados automáticamente. Lo que hace llamativa la decisión de Kling es su radicalidad: en lugar de intentar filtrar el ruido caso a caso, elimina el canal por el que llega.

Desde el punto de vista práctico, esto tiene consecuencias reales. Ladybird perdería potencialmente contribuciones valiosas de personas externas al equipo. Pero el razonamiento inverso también aplica: un equipo pequeño dedicando tiempo a revisar PRs de origen incierto es un equipo que no está construyendo el navegador.

¿Qué modelo de gobernanza queda?

La pregunta que deja abierta esta decisión es cómo escalan proyectos ambiciosos si cierran la puerta a contribuciones externas no supervisadas. Ladybird apuesta por un modelo más parecido al desarrollo corporativo cerrado que al open source clásico: un grupo reducido y conocido de personas que responden por cada línea de código.

Es un modelo legítimo, y probablemente más sostenible para un proyecto con las ambiciones técnicas de Ladybird que intentar gestionar una comunidad de contribución masiva en un contexto donde verificar la autoría y la intención de un parche se ha vuelto más costoso. Pero implica renunciar a una de las promesas fundacionales del software libre: que cualquiera puede mejorar el código.

En ClaudeWave seguimos de cerca este tipo de decisiones porque afectan directamente a cómo se construyen y mantienen las herramientas que rodean al ecosistema de agentes e integraciones. Si los proyectos open source que sirven de base infraestructural empiezan a cerrar sus procesos de contribución como respuesta a la presión del código generado por IA, las implicaciones para la cadena de dependencias son amplias. No es alarmismo: es un cambio de modelo que conviene entender antes de que sea la norma.