Godot prohíbe el vibe coding: 5.000 pull requests atascados y la bofetada que el open source le da a los gurús de la IA

El motor de Slay the Spire 2 no acepta más código que no entiende nadie

Godot no es un proyecto cualquiera. Es el motor open source detrás de Slay the Spire 2 y Brotato, uno de los más respetados del desarrollo de videojuegos independientes, y el que muchos desarrolladores eligieron como refugio cuando Unity implosionó en 2023 con su polémica tarifa por instalación. Esa migración masiva le trajo más desarrolladores, más visibilidad y, según los datos disponibles, más contribuciones de baja calidad generadas con IA.

El 30 de junio de 2026 la Fundación Godot publicó una nueva política de contribuciones. Prohíbe el uso de agentes autónomos de IA y lo que la industria lleva meses llamando vibe coding: generar bloques sustanciales de código dejándose llevar por lo que escupe el modelo sin entender realmente qué hace cada línea.

No es FUD. No es una opinión de foro. Es la respuesta oficial de una fundación con repositorio, historial y nombres propios detrás.

Los 5.000 PRs: cuando el atasco tiene nombre y apellidos

En febrero de 2026, Rémi Verschelde, el gestor principal de Godot, describía públicamente la situación como "cada vez más agotadora y desmoralizante". No usó eufemismos. Lo dijo con todas las letras refiriéndose a la avalancha de pull requests generados por IA que llevaban meses llegando al repositorio.

Para julio de 2026, el repositorio de Godot en GitHub acumulaba más de 5.000 pull requests sin resolver.

Ese número necesita contexto para que duela como tiene que doler. Un pull request es una propuesta de cambio de código: alguien escribe una modificación, la envía, y un mantenedor la revisa, pide cambios, discute el enfoque y, si pasa el corte, la fusiona con el código principal. Es un proceso que requiere tiempo, criterio técnico y comunicación. No es automático.

Cinco mil PRs sin resolver en un proyecto gestionado por voluntarios no es un indicador de actividad saludable. Es un cuello de botella que paraliza el desarrollo real y deja tirados a los contribuyentes legítimos que sí entienden lo que están proponiendo.

La ironía es que la promesa del vibe coding era acelerar el desarrollo. Lo que ocurrió en Godot es exactamente lo contrario: el repositorio fue más lento, más opaco y más difícil de gestionar precisamente porque la velocidad de generación de código superó con creces la capacidad humana de revisarlo.

Lo que los gurús del vibe coding no cuentan

Hay un detalle que los hilos de Twitter sobre vibe coding siempre omiten: detrás de cada repositorio open source hay personas reales que revisan código a cambio de nada.

No hay un equipo de QA pagado. No hay SLA de respuesta. Hay individuos que dedican horas libres a leer código ajeno, entender qué intenta hacer, detectar bugs, proponer mejoras y escribir feedback detallado, todo ello esperando que quien recibe ese feedback aprenda algo y se convierta, con el tiempo, en alguien capaz de ayudar a revisar código de otros.

Eso es lo que la Fundación Godot llama el espíritu de mentoría que sostiene estos proyectos. Y es exactamente lo que un PR generado por agente autónomo destruye.

La Fundación lo explica sin rodeos en su política: revisar un PR de IA no forma a nadie. El mantenedor escribe feedback; la máquina no aprende. No hay transferencia de conocimiento. No hay futuro colaborador que salga de esa interacción. Solo hay desgaste acumulado en alguien que trabaja gratis y que en algún momento deja de hacerlo.

"Revisar PRs de IA es desmoralizante porque la retroalimentación no forma a futuros mantenedores. Las máquinas no pueden aprender ni responsabilizarse del código." , Fundación Godot, política de contribuciones 2026

Esto no es una queja filosófica sobre la naturaleza del software libre. Es una descripción operativa de por qué el modelo colapsa cuando se inunda de contribuciones que nadie comprende realmente.

La política en detalle: qué prohíbe, qué permite y qué exige

La política de Godot no es una prohibición total de IA. Esa matización importa y conviene no distorsionarla.

Qué está prohibido:

• Uso de agentes autónomos de IA para generar fragmentos sustanciales de código
• Vibe coding: generar bloques de lógica sin comprensión real del código resultante
• Texto generado por IA en la comunicación humana dentro del proyecto (comentarios, discusiones, mensajes a mantenedores)

Qué está permitido:

• Autocompletado
• Generación de expresiones regulares
• Operaciones de buscar y reemplazar
• Cualquier tarea mecánica y de detalle donde el desarrollador entiende al 100% el resultado

Qué se exige:

• Divulgación obligatoria de cualquier uso de IA, incluso en tareas menores, en la discusión del pull request
• Que cada PR sea revisado y aprobado por un humano antes de su fusión
• Para colaboradores nuevos (con tres PRs aprobados o menos): empezar por corrección de bugs y documentación antes de proponer funcionalidades nuevas o refactorizaciones grandes

La última condición es interesante porque no es solo un requisito burocrático. Es un mecanismo de aprendizaje. La Fundación quiere que los nuevos contribuyentes se ganen la confianza de los mantenedores demostrando que entienden el código base antes de proponer cambios estructurales. La IA no puede hacer ese camino por nadie.

El precedente de Zig: cuando la línea es todavía más dura

Godot no es el primero. Antes llegó Zig.

El lenguaje de programación Zig, a través de su presidente Andrew Kelley, prohibió directamente todas las contribuciones que involucren IA, sin excepciones ni matices. La justificación de Kelley fue directa al hueso: las contribuciones de IA son "invariablemente basura" y tienen "valor negativo" porque consumen tiempo de revisión de un equipo que ya tiene 200 PRs abiertos.

La diferencia entre Zig y Godot revela dos filosofías distintas ante el mismo problema.

Zig optó por la prohibición total porque es más fácil de aplicar: si la norma es cero IA, no hay que evaluar caso por caso si el código generado es suficientemente bueno. Eso elimina la carga cognitiva de los revisores, que de otro modo tendrían que juzgar cada PR de IA individualmente, lo cual, según Kelley, sería insostenible.

Godot eligió una prohibición más quirúrgica: prohíbe lo que no se puede entender y permite lo que es mecánico. Es una política más compleja de aplicar porque requiere juicio humano para detectar qué cuenta como "fragmento sustancial" y qué no. La Fundación no ha especificado si implementará herramientas automáticas de detección o si dependerá únicamente de la revisión manual y la divulgación voluntaria del contribuyente. Esa ambigüedad es real y conviene no ignorarla.

Ambas políticas coinciden en el diagnóstico de fondo: el problema no es que la IA genere código. El problema es que genera código que nadie entiende lo suficiente como para mantenerlo, depurarlo o defenderlo cuando algo falla.

El contraste con Unreal Engine: distintos públicos, distintas apuestas

La política de Godot contrasta directamente con la de Unreal Engine 6, que permite "mezclar y combinar" modelos de IA en el flujo de desarrollo. El CEO de Epic, Tim Sweeney, ha llegado a ridiculizar públicamente a Valve por requerir divulgación de IA en los juegos de Steam.

Aquí hay que leer el contexto sin ideología: Unreal Engine no es un proyecto open source gestionado por voluntarios. Es un producto comercial con equipos pagados de revisión, QA y soporte. La ecuación de costes es completamente distinta. Lo que destruye una comunidad de voluntarios puede funcionar en un entorno corporativo con recursos suficientes para absorber el ruido.

La pregunta relevante no es cuál de los dos tiene razón en abstracto. Es qué modelo aplica a qué contexto. Y el contexto de Godot, como el de la mayoría de proyectos open source de calidad, es el de mantenedores voluntarios con tiempo limitado.

El auge de Godot tras el colapso de confianza en Unity en 2023 fue genuinamente positivo: más desarrolladores, más visibilidad, más contribuciones legítimas. Pero también atrajo a una nueva categoría de usuarios que llegaron con expectativas distintas sobre lo que significa "contribuir" a un proyecto, expectativas moldeadas en parte por el discurso del vibe coding que presenta la generación de código como un fin en sí mismo.

Qué puedes aprender si contribuyes a Godot (o a cualquier proyecto con política similar)

Si trabajas con IA y quieres contribuir a proyectos open source que adopten políticas como la de Godot, las reglas prácticas son claras:

• Usa IA para lo mecánico, no para la lógica. Autocompletado, regex, refactorización de nombres: adelante. Generar la arquitectura de un sistema que no entiendes: no.
• Divulga antes de que te lo pregunten. La transparencia proactiva es la diferencia entre un contribuyente que genera confianza y uno que la destruye.
• Entiende cada línea que envías. Si no puedes explicar por qué funciona el código que estás proponiendo, no estás en condiciones de responder al feedback de un mantenedor ni de arreglarlo cuando falle en producción. El problema no es nuevo: las apps construidas en tres horas con vibe coding tienen exactamente la misma brecha entre lo que el modelo genera y lo que el creador entiende.
• Empieza pequeño. Bugs, documentación, tests. Antes de proponer una funcionalidad nueva, demuestra que entiendes el código base. Eso no es una barrera arbitraria; es cómo funciona la confianza en comunidades técnicas.
• Comunícate como humano. La política de Godot prohíbe explícitamente el texto generado por IA en las discusiones del proyecto. No porque sea detectado automáticamente, sino porque un mantenedor voluntario merece saber que está hablando con una persona, no con un modelo que está parafraseando una respuesta.

El modelo de mentoría que la IA no puede reemplazar

Hay algo en la política de Godot que va más allá de los PRs rechazados y los repositorios colapsados. La Fundación está articulando en voz alta algo que la industria lleva meses evitando decir: los proyectos open source no son solo repositorios de código. Son estructuras de transmisión de conocimiento.

Cuando un mantenedor senior revisa el código de alguien que empieza, no solo está comprobando si funciona. Está enseñando cómo se razona sobre un problema, qué decisiones de diseño existen y por qué se elige una sobre otra, cuáles son los compromisos implícitos de cada enfoque. Esa transmisión no ocurre en un sentido único: el mantenedor también aprende del proceso, porque revisar código ajeno obliga a articular criterios que de otro modo permanecen implícitos.

Un agente autónomo no puede recibir esa enseñanza. No puede aprender de la retroalimentación en el sentido que importa para la salud de un proyecto a largo plazo. No puede asumir responsabilidad sobre el código que genera. Y cuando algo falla en producción, no hay nadie al otro lado que pueda arreglarlo porque nunca entendió realmente qué estaba proponiendo.

La Fundación Godot no está siendo conservadora ni ludita. Está siendo precisa sobre dónde falla el modelo del vibe coding cuando se aplica a contextos que dependen de la responsabilidad humana sobre el código.

La pregunta que la política pone sobre la mesa

Hay una pregunta de fondo que la nueva política de Godot no formula explícitamente pero que está en cada línea: ¿qué significa contribuir a un proyecto?

Si contribuir significa enviar código que pasa los tests automáticos, la IA puede hacerlo sin problemas. Si contribuir significa entender el problema lo suficiente como para defenderlo, iterarlo, mantenerlo y eventualmente enseñar a otra persona cómo funciona, la IA autónoma no puede hacerlo. No porque sea técnicamente incapaz de generar el texto, sino porque el código que genera nadie en la cadena comprende de verdad.

Esa es la distinción que Godot ha decidido hacer explícita. Y que otros proyectos, según cómo evolucione esta política, tendrán que decidir si adoptan o ignoran.

La plantilla que Godot ofrece al resto del open source no es perfecta. La definición de "fragmento sustancial" es ambigua. La dependencia de la divulgación voluntaria tiene flancos evidentes. No hay datos todavía sobre si la política reduce efectivamente el número de PRs de baja calidad o si simplemente desplaza el problema.

Pero es la primera política de un proyecto de este tamaño que intenta separar con precisión la asistencia legítima de la generación autónoma irresponsable. Y el hecho de que la comunidad lleve meses esperando algo así dice bastante sobre el estado real del debate.

Generar código es fácil. Entenderlo sigue siendo trabajo de humanos. Y en los proyectos que sobreviven décadas, esa diferencia lo es todo.