- El motor de juegos de código abierto Godot decidió prohibir en su política de contribuciones el código escrito por IA y los envíos realizados por agentes de IA, ya que los Pull Request generados por IA aumentan la carga de revisión
- Los mantenedores consideran que revisar PR generados por IA vuelve aún más desgastante una tarea ya tediosa, y además reduce el efecto de formar a nuevos colaboradores como futuros mantenedores
- La nueva política rechazará explícitamente el código escrito por IA, los Pull Request enviados por agentes de IA y el texto generado por IA incluido en la comunicación entre personas
- Los colaboradores podrán usar IA solo de forma auxiliar para “menial things” y deberán revelar su uso; se permitirá la traducción automática basada en un texto original escrito por una persona
- La Godot Foundation planea operar de forma conservadora por ahora, dado que las herramientas de IA cambian rápidamente, y volverá a evaluar la política según evolucione la situación
Cambio en la política de contribuciones de Godot
- La Godot Foundation y los mantenedores decidieron, tras varios meses de discusión, revisar las guías para colaboradores para limitar los envíos relacionados con IA
- Las restricciones abarcan código escrito por IA, Pull Request enviados por agentes de IA y texto generado por IA en la comunicación entre personas
- Godot es un motor de juegos de código abierto usado en títulos como Slay the Spire 2 y The Case of the Golden Idol
La carga de mantenimiento causada por los Pull Request con IA
- Desde febrero, los mantenedores venían discutiendo cómo responder al aumento de los Pull Request de AI slop
- Ese flujo de PR se ha vuelto “increasingly draining and demoralizing” para quienes revisan el código del proyecto
- La Godot Foundation considera que el problema no es temporal, y busca reducir la carga sobre los mantenedores sin perder el camino para formar a nuevos colaboradores como futuros mantenedores
Cuando la revisión ya no se convierte en mentoría
- El gran volumen de PR pendientes de revisión puede verse en sí mismo como una señal de mayor interés en usar y contribuir a Godot
- Sin embargo, a medida que aumentan las contribuciones escritas o enviadas por IA, los mantenedores tienen cada vez menos disposición a dedicar tiempo a revisar PR
- Si la retroalimentación sobre los PR no sirve para orientar a potenciales futuros mantenedores y en cambio “la absorbe una máquina”, se vuelve difícil justificar dedicar tiempo libre a revisar
Restricciones concretas de la nueva política
- La política de contribuciones de Godot pronto incluirá un rechazo explícito al AI-authored code
- Los colaboradores solo deberán usar asistencia de IA para “menial things” y tendrán que revelar ese uso
- La Foundation afirmó que “la IA no puede asumir responsabilidad, y no podemos confiar en que quienes usan mucho IA entiendan su código lo suficiente como para corregirlo”
- También se rechazará el texto generado por IA en la comunicación entre personas
- La Foundation lo describió como “a basic principle of respect”
- La traducción automática basada en un texto original escrito por una persona seguirá permitiéndose
Dirección operativa de la política
- La Godot Foundation se enfoca en añadir barreras a las contribuciones de bajo esfuerzo tipo “slop”
- Entre los objetivos de la política también están permitir que los mantenedores puedan seguir haciendo revisión de código y ayudar a que nuevos colaboradores crezcan hasta convertirse en futuros mantenedores
- Todas las contribuciones deben venir de una persona que asuma responsabilidad por su propio código y pueda corregirlo directamente si algo falla
- La Foundation señaló que, como las herramientas de IA cambian a diario en este momento, mantendrá una política conservadora y la reevaluará conforme cambie la situación
1 comentarios
Opiniones de Hacker News
Esta política es justa. Es realmente molesto recibir muros de texto escritos por IA larguísimos para revisarlos a fondo; se siente como un ataque de denegación de servicio contra la mente humana.
Aun así, no creo que pueda impedirse la programación asistida por IA en sí. En el lado negativo, quien envía el aporte podría añadir marcas de estilo para que parezca humano, dejando igual el contenido principal y el tamaño de la contribución, pero con un estilo más raro.
En el lado positivo, podría llevar a commits y comentarios sin relleno, del tipo “este es el código, esta es la razón del cambio y este es el impacto”. Aunque lo haya generado una IA, estas contribuciones pequeñas serían mucho más fáciles de verificar, y también podrían surgir estándares sobre el tamaño adecuado de las contribuciones o sobre qué cambios requieren una revisión más estricta.
Personalmente, si el contenido encaja con lo segundo, no me importa demasiado si fue generado por IA o no.
Si de verdad llegaran “commits y comentarios sin relleno”, sería un sueño.
En ese contexto, tiene sentido rechazar contribuciones de IA, y más aún en software como Godot, que ya demostró un gran valor.
Si un commit escrito por IA no es fundamentalmente distinto, tampoco hay razón para rechazarlo; por eso no creo que el objetivo sea impedir la programación asistida por IA.
Es interesante que, por un lado, las valuaciones de las empresas de IA dependan de la suposición de que en un futuro cercano todo el código y todos los productos digitales serán escritos por IA, mientras que, por otro lado, casi todos los proyectos populares de código abierto intentan bloquear contribuciones de IA. Es difícil reconciliar ambas cosas.
Personalmente, después de usarla mucho en mis proyectos open source, también estoy pasando por algo como una resaca de IA. En el momento, se siente como si obtuvieras un poder enorme, creando en horas una funcionalidad que habría tomado semanas; pero con el tiempo, al mirar el código, aparecen grietas e inconsistencias sutiles que dejó la herramienta, y eso es incómodo.
Ahora intento usarla menos para desarrollar funcionalidades grandes y más en lugares donde puedo poner guardrails estrictos, como planificación, depuración o refactorizaciones de alcance acotado. Aun así acelera el trabajo, pero más bien 1.5 a 3 veces, no 10 veces.
Reduce la concentración mental necesaria para programar, pero aparece un cansancio nuevo de estar chateando todo el tiempo con la máquina sin saber cómo interpretará las instrucciones en lenguaje natural. Se siente como operar con combinaciones de botones una máquina cuyo cableado interno cambia constantemente, y no resulta satisfactorio.
Lo que hizo posible la IA son contribuciones de personas que no participan en absoluto en el proyecto. Ahora, el simple hecho de haber creado un PR ya no permite asumir que “esta persona tiene cierto interés en el éxito del proyecto”.
Bien usada, la IA es un amplificador, pero para los mantenedores de open source es fácil quedar enterrados bajo grandes cantidades de “contribuciones” de bajo valor hechas por personas a las que no les interesa el proyecto.
En especial por la tendencia aduladora de la IA, que no deja de decir “¡buena idea!”, aunque sé perfectamente que la mayoría de mis ideas no son gran cosa.
Cuando veo historias de gente haciendo vibe coding en el teléfono mientras está con sus hijos, casi suena a compulsión.
Para empezar, en open source la velocidad nunca tuvo tanto significado, y había buenas razones para eso.
También es un problema la estructura de dopamina que hace demasiado fácil recurrir a la IA al trabajar o iniciar un proyecto nuevo.
Por ahora estoy intentando reentrenar mi cerebro para volver a preferir escribir la mayor parte del código a mano, en lugar de ir primero a Claude. El tiempo dirá si esto es una etapa temporal o si acabaremos necesitando algo como grupos anónimos de usuarios de LLM.
Hay listas que recopilan software sin IA. Sería interesante ver un índice o gráfico de cómo cambian con el tiempo.
https://codeberg.org/brib/slopfree-software-index
https://noai.starlightnet.work/list.html
https://hcker.news/?ai=exclude&include_domains=github.com
Por razones funcionales, no se me ocurre bien una política no-AI. Si se ejecuta, se ejecuta, sin importar quién o qué lo haya hecho.
Aunque evites la basura generada por IA, no puedes evitar la basura generada por humanos o por humanos+IA que pase el filtro.
Aun así, sí se me ocurren suficientes razones no funcionales, como procedencia, responsabilidad, prueba de trabajo, fomentar que las personas escriban código directamente y rastrear empíricamente cómo los humanos hacen evolucionar una base de código.
La frase de la Foundation da justo en el clavo: “si la retroalimentación sobre un PR no se usa para orientar a una persona que podría convertirse en futura maintainer, sino que solo es absorbida por una máquina, se vuelve mucho más difícil justificar dedicar tiempo libre a revisar PRs”.
Si no se entiende, basta con ver esto:
https://github.com/godotengine/godot/pull/115280
https://github.com/godotengine/godot/pull/116410
En un proyecto que ya sufría por tener demasiados PRs que revisar incluso antes de la era de la IA, no es justo pedirles a los maintainers que además sigan lidiando con cosas así.
Por eso el cambio realmente importante de la política es la parte que impide que nuevos contribuidores se encarguen de funcionalidades grandes o refactorizaciones.
Con la información que quedó en el repositorio se podía encontrar su alias y sus cuentas sociales, y era un niño que ni siquiera parecía haber llegado a la adolescencia temprana. Parecía no tener todavía los conocimientos básicos para entender el problema ni la estructura social relacionada.
Es un caso donde la ley de Brandolini funciona tal cual.
Refutar tonterías requiere 10 veces más esfuerzo que producirlas. La revisión de código es una refutación, y verificar la exactitud de una proposición también lo es.
Generar una proposición es fácil, pero para refutarla hay que demostrar si es verdadera o falsa, o encontrar una contradicción. La energía de los maintainers de open source, que ya tienen poco tiempo, se desperdicia innecesariamente; estoy totalmente de acuerdo con ahorrar esa energía y usarla de forma productiva.
La IA encontró por casualidad uno de los recursos más caros de la industria: el tiempo libre de las personas que mantienen open source por las noches después de terminar su trabajo principal.
La Foundation señaló algo que siempre fue cierto, pero que la IA puso en primer plano. Cualquier contribuidor, incluida la IA, puede no estar en condiciones de mantener ese parche en el futuro.
El punto clave no es el uso de IA en sí, sino que es una de las señales de que quien envía el cambio no entiende lo que está entregando. Romper convenciones de nombres de variables, cambiar APIs que no deberían tocarse o cometer errores inmaduros de lenguaje pueden ser motivos para rechazar un parche aunque funcione.
Una forma de manejarlo sería marcar que se rechaza el PR por la IA y luego pedirle al autor que señale una parte de la que esté especialmente orgulloso y explique con sus propias palabras, no con una pared de texto generada por IA, qué hace y por qué es bueno. El autor tiene que mostrar gustos y opiniones que la IA no tiene.
Aquí da la impresión de que mucha gente está reaccionando al título en lugar de leer la política real. La política dice que una razón importante es que la revisión de PRs se usa para formar nuevos contribuidores y descubrir potenciales futuros maintainers.
Independientemente de la calidad de las contribuciones de IA, esa parte parece difícil de refutar.
La excepción sería creer que la IA hará innecesario todo el concepto de contribución o mantenimiento open source; pero en ese caso parecería más correcto forkear el motor y poner a trabajar a agentes, en vez de enviar PRs a Godot.
¿Los contribuidores de IA realmente creen que están ayudando? ¿No saben que están arruinando proyectos con ese “trabajo”?
No entiendo por qué gastar dinero en algo que nadie quiere y que será rechazado. ¿No tienen hobbies, o son instancias de OpenClaw que su creador olvidó y que andan libres haciendo lo que quieren?
Estas personas están cosechando contribuciones a proyectos FOSS importantes para inflar el currículum. Lo mismo ocurre con los reportes de vulnerabilidades.
Los generadores masivos quizá crean sinceramente que están ayudando, o quizá saben que sus “contribuciones” son una pérdida neta para el proyecto. Pero cuando hay incentivos económicos directos y la situación personal es precaria, las externalidades pasan a segundo plano.
Claude lo hizo en 1 hora, y yo lo pulí 3 o 4 veces, reduciendo la pared de texto y ajustándolo al estilo del proyecto original. La alternativa era dejarlo pasar o abrir solo un issue y pasarle la carga al maintainer.
Por eso creo que sí ayudé. También encontré ese caso límite mientras trasteaba con mi homelab como hobby.
Ambos PRs eran pequeños y no se distinguían de PRs humanos. Sigo creyendo que eran agregados valiosos, y claramente algunos maintainers también lo vieron así.
No quiere programar ni mejorar un producto, sino tener “líneas de código”, “commits” y un bonito perfil verde de GitHub sin entender los detalles.