La Crisis del Open Source en la Era de la IA: Del Pull Request al Prompt Request

Un análisis profundo sobre cómo la generación masiva de código mediante IA está saturando el software de código abierto y obligando a proyectos como TLDraw y LLVM a cambiar sus reglas.

La premisa del peligro inminente para el Open Source

Existe una creciente preocupación en la comunidad tecnológica respecto a la viabilidad futura del software de código abierto tal como lo conocemos hasta ahora. Esta inquietud surge de la observación de que el modelo tradicional de colaboración está siendo amenazado por nuevas dinámicas en la generación de código, lo que ha llevado a varios proyectos a replantearse sus normas de gestión. La aceptación y el debate generados por contenidos anteriores sobre tecnologías como Tailwind indican que este es un tema de vital importancia y actualidad para los desarrolladores.

Decisiones drásticas en la gestión de contribuciones

Ante la saturación y los problemas emergentes, varios mantenedores de proyectos de Open Source están optando por tomar decisiones radicales sobre cómo administran las aportaciones externas. Estas medidas no son cambios menores, sino alteraciones fundamentales en el flujo de trabajo que afectan directamente a cualquier persona que desee aplicar código nuevo o colaborar con estos proyectos existentes. La situación ha escalado hasta el punto en que la gestión tradicional de Pull Requests se ha vuelto insostenible para algunos equipos.

El caso específico del proyecto TLDraw

El proyecto TLDraw, una aplicación popular utilizada para dibujar y crear diagramas en equipo, se ha convertido en un ejemplo central de esta crisis. Los responsables de este proyecto han publicado un post que ha captado la atención de la comunidad por la severidad de las medidas anunciadas. La dirección del proyecto ha decidido cerrar automáticamente cualquier solicitud de extracción (pull request) que provenga de contribuidores externos.

Definición de contribuidor externo en el contexto de TLDraw

Para clarificar el alcance de su nueva política, el equipo de TLDraw ha definido explícitamente qué consideran un contribuidor externo. Esta categoría abarca a cualquier persona que no trabaje directamente dentro del equipo oficial de TLDraw. Esto significa que la comunidad general de desarrolladores, que tradicionalmente ha sido el motor del Open Source, se ve temporalmente excluida del proceso directo de contribución de código mediante los canales habituales.

La postura de Steve y la justificación oficial

Steve, presumiblemente uno de los mantenedores o líderes de TLDraw, ha comunicado la decisión a través de GitHub, ofreciendo una explicación que resulta muy interesante para entender el contexto actual del desarrollo de software. Su mensaje detalla las razones detrás del cierre automático de las solicitudes y establece que esta no es una medida caprichosa, sino una respuesta necesaria ante un cambio en el entorno de desarrollo.

Excepciones a la regla de cierre automático

A pesar de la medida drástica de cerrar las "pull requests" de código, el equipo de TLDraw ha decidido mantener abiertos ciertos canales de comunicación y reporte:

• Incorporate issues (reportes de problemas).
• Reportes de errores (bugs).
• Participación en discusiones.

Esto indica que el bloqueo es específicamente contra la propuesta de soluciones en código y no contra la retroalimentación de la comunidad.

La temporalidad de la medida y la espera de mejores herramientas

La decisión de bloquear contribuciones externas se presenta como una solución temporal y no necesariamente permanente.

Los mantenedores han expresado que esta política se mantendrá hasta que plataformas como GitHub ofrezcan mejores herramientas para gestionar la nueva realidad del flujo de trabajo. Existe una demanda explícita de utilidades que ayuden a filtrar y administrar el volumen de aportaciones de manera más eficiente.

La expansión masiva de la Inteligencia Artificial desde 2025

Según el análisis presentado, desde el año 2025 se ha observado una expansión masiva en el uso de la inteligencia artificial entre los desarrolladores de software. La aparición y popularización de agentes y herramientas como Cloud Code y Open Code han facilitado enormemente la generación automática de código. Estas herramientas son capaces de producir código que, a primera vista, tiene sentido y es funcional.

El uso de IA para aportar al Open Source

Una gran cantidad de personas está utilizando estas nuevas capacidades de generación de código por IA para enviar contribuciones a proyectos de Open Source. Steve, del proyecto TLDraw, confirma que, al igual que muchos otros proyectos en GitHub, han visto un incremento significativo recientemente en las contribuciones que son generadas directamente por herramientas de inteligencia artificial.

La naturaleza engañosa de las Pull Requests generadas por IA

Problemas de contexto incompleto o confuso

Esto sugiere que, aunque el código podía ejecutarse o parecer lógico, carecía de una comprensión profunda de cómo funcionaba el proyecto en su totalidad. Las herramientas de IA, o los usuarios que las operaban, no acababan de entender la arquitectura o los objetivos específicos del software al que intentaban contribuir.

Errores en la solución de problemas y malentendidos

Frecuentemente, el código generado por IA no solucionaba los problemas que se suponía debían resolverse, o lo hacían de una forma errónea. Se detectaron malentendidos fundamentales en la base de código. Estos errores indican una falta de alineación entre la lógica generada por la máquina y la lógica interna del proyecto.

Violación de reglas de estilo y consistencia

Otro punto de fricción importante es que estas contribuciones a menudo no seguían las reglas de estilo establecidas por el proyecto. La consistencia en el código es vital para la mantenibilidad a largo plazo. Esto obliga a los mantenedores a realizar correcciones cosméticas o estructurales que consumen tiempo valioso.

La falta de seguimiento (Follow-up) por parte de los autores

Un aspecto crítico que rompe el modelo de colaboración es el poco o nulo seguimiento ("follow-up") por parte de los autores de estas contribuciones. Cuando un mantenedor revisa una PR y ofrece propuestas o pregunta por qué se tomó cierta decisión técnica, lo normal es esperar un diálogo. Sin embargo, en el caso de las contribuciones masivas por IA, no se acostumbra a ver estas conversaciones, dejando a los mantenedores hablando al vacío.

El costo de tiempo para los mantenedores

Esta dinámica generaba una situación insostenible donde los contribuidores principales tenían que gastar una enorme cantidad de tiempo revisando solicitudes que nunca llegaban a buen puerto. El esfuerzo invertido en revisar código, sugerir cambios y tratar de entender la intención del autor se desperdiciaba porque las solicitudes se quedaban en el "limbo" sin respuesta ni corrección por parte del enviador.

El efecto Hidra en las solicitudes de extracción

El problema se agravaba por el volumen incesante de nuevas solicitudes; cada vez que los mantenedores lograban revisar y cerrar una "pull request", aparecían otras dos nuevas en su lugar. Este ciclo continuo de generación y revisión crea una carga de trabajo que supera la capacidad humana de los equipos de mantenimiento, haciendo imposible mantener la calidad y la atención al detalle.

El significado del compromiso en una Pull Request

Steve de TLDraw enfatiza que una "pull request" representa un compromiso ("commitment") por parte de los mantenedores. Al recibir una contribución, el equipo asume la responsabilidad de revisarla con cuidado y considerarla seriamente para su inclusión en el código (merge). Este contrato implícito de atención y respeto profesional se rompe cuando la contraparte envía código generado automáticamente sin intención de iterar sobre él.

La necesidad de selectividad y el filtrado manual

Para que la responsabilidad de los mantenedores siga teniendo sentido, el equipo de TLDraw concluyó que necesitan ser mucho más selectivos con lo que aceptan revisar. Su estrategia implica cerrar primero todas las PRs y luego leerlas una a una para reabrir solo aquellas que consideren viables. El objetivo explícito de esta maniobra es "filtrar el ruido" que inunda su repositorio.

El aumento de la barrera de entrada para contribuir

Como consecuencia directa de estas políticas de filtrado, va a ser mucho más complicado para las personas aportar al Open Source en el futuro inmediato. Los mantenedores se ven obligados a establecer barreras previas para filtrar todo el slop (basura o contenido de baja calidad) generado por inteligencia artificial que no desean incorporar en sus proyectos.

Inadecuación de las herramientas actuales de GitHub

La crisis se exacerba porque las herramientas que plataformas como GitHub aportan para gestionar el flujo de trabajo (issues, pull requests, revisiones) están pensadas para una época pasada. Estas herramientas fueron diseñadas asumiendo que la mayoría del código era escrito por humanos, lo que implicaba una velocidad de producción limitada y reflexiva. Ninguna herramienta actual se ha adaptado completamente al uso masivo de la IA.

Humanos gestionando volumen de máquinas

El núcleo del problema tecnológico es que estamos utilizando herramientas pensadas para la escala humana para gestionar un volumen de código generado por máquinas. La disparidad entre la velocidad de generación de la IA y la capacidad de revisión humana crea un cuello de botella insalvable con la infraestructura actual. La IA avanza más rápido de lo que las herramientas de gestión son capaces de asimilar.

El ataque DDoS de código a proyectos Open Source

La situación ha sido descrita por la comunidad, específicamente en foros como Reddit, como un ataque DDoS (Denegación de Servicio Distribuido) pero de código. Múltiples proyectos consideran que están siendo atacados por una avalancha de sumisiones generadas por IA que saturan sus recursos de atención y mantenimiento.

El caso del proyecto Curl y Daniel Stenberg

Daniel Stenberg, creador del proyecto Curl, ha confirmado que su proyecto está siendo efectivamente "atacado" con un DDoS de reportes de errores (Bug Reports). La terminología de "ataque" refleja la severidad con la que los mantenedores perciben este influjo masivo y no solicitado de interacciones de baja calidad.

Incremento del volumen de reportes y cierre de Bug Bounties

En el caso de Curl, el volumen de reportes se disparó en algún punto hasta un 800% (un por 8) de lo normal. Debido a este incremento inmanejable de reportes generados probablemente por herramientas automatizadas buscando recompensas, el proyecto está considerando cerrar su programa de "Bug Bounty" (recompensas por errores).

El caso del proyecto OCaml y el rechazo masivo

El equipo que trabaja en el proyecto OCaml se enfrentó a una situación similar, llegando a rechazar una "pull request" de 13.000 líneas que había sido generada por inteligencia artificial. El tamaño desproporcionado de la contribución es un rasgo característico de la generación automática que ignora las buenas prácticas de atomización de cambios.

El agotamiento de revisar código de IA

El razonamiento del equipo de OCaml para rechazar tal contribución fue que revisar código generado por IA es mucho más agotador que revisar código humano. La falta de una narrativa humana, intencionalidad clara y estructura lógica coherente hace que la auditoría de este tipo de código requiera un esfuerzo cognitivo superior por parte de los revisores.

El impacto en el proyecto Vue

El proyecto Vue también se está viendo atacado con un montón de sumisiones generadas con IA, confirmando que este no es un problema aislado de un solo ecosistema. La ubicuidad del problema sugiere una tendencia generalizada que afecta a proyectos de alto perfil en diferentes lenguajes y dominios.

La responsabilidad de GitHub y Copilot

Se señala que GitHub no está ayudando a mitigar esta situación, sino que la agrava al integrar herramientas como Copilot directamente en la interfaz de creación de "issues" y "pull requests". Esta integración hace que sea todavía más sencillo y atractivo generar contenido automático, lo que a su vez lo hace más complicado para la gente que tiene que gestionar el proyecto.

La propuesta de RFC del proyecto LLVM

Para intentar gestionar este caos, algunos proyectos como LLVM (una infraestructura de compiladores) están generando un "Request for Comments" (RFC) específico para la gestión de código de IA. LLVM busca establecer una política clara que obligue a los contribuidores a seguir ciertas reglas si desean utilizar herramientas generativas.

Limitación de tamaño en las contribuciones (LLVM)

Una de las propuestas más llamativas del RFC de LLVM es la limitación del tamaño de las contribuciones. Proponen que las contribuciones sean idealmente de menos de 150 líneas adicionales, excluyendo los tests. Este número se considera "bastante preocupante" o bajo, pero tiene como objetivo eliminar la mayoría de las PRs generadas por IA, ya que a herramientas como Cloud Code les encanta generar grandes cantidades de código.

Exigencia de transparencia en el uso de IA

El RFC de LLVM también propone ser transparente con el uso de la inteligencia artificial. Se sugiere que en los mensajes de "commit" se deba indicar explícitamente si el código fue asistido por una herramienta, utilizando etiquetas como "assisted by cloud" o "assisted by codex". Esto busca recuperar el contexto sobre el origen del código.

Prohibición de la IA en la decisión final de revisión

Un punto crucial de la propuesta es limitar el uso de la IA para la revisión de código. Se establece que nunca debe ser una inteligencia artificial la que tome la decisión final sobre si una "pull request" se va a aceptar o no. Esto podría afectar el modelo de negocio de herramientas como Code Rabbit, cuyo mercado es precisamente automatizar la revisión de código.

Limitaciones a la automatización de Merges

Es probable que se limiten las automatizaciones donde herramientas de revisión automática aprueben y fusionen ("merge") código directamente sin intervención humana. Si estas políticas se implementan, veremos cambios en los ficheros de "contributing" de los proyectos, especificando cómo se debe utilizar la IA para aportar.

El concepto de Prompt Request en lugar de Pull Request

Surge una idea innovadora compartida por Jesse Oros y atribuida originalmente a Peter: el concepto de Prompt Request. Esta propuesta sugiere que, dado que ver un montón de cambios en el código ya no comunica la intención del autor, sería preferible compartir el "prompt" (la instrucción dada a la IA) que generó el código.

Valorando la intención sobre el código final

La filosofía detrás del "Prompt Request" es que si al mantenedor le gusta el prompt, él mismo puede ejecutarlo y fusionar el resultado. Ver los cambios en el código da cada vez menos información debido a la velocidad y volumen de generación; en cambio, ver cómo el ingeniero interactuó con la IA aporta mucho más valor para entender las 30.000 o 40.000 líneas generadas.

Historial de prompts vinculado a los commits

Para implementar esta visión en las herramientas, se propone que se pueda compartir el "prompt story", es decir, el historial de lo que el usuario preguntó y lo que el asistente respondió, vinculado directamente a la "pull request". Esto permitiría a los revisores ver no solo el resultado final, sino el proceso lógico y conversacional que llevó a ese código.

Desarrollo de nuevas herramientas de trazabilidad

Ya hay personas comentando en redes sociales (X) que están desarrollando herramientas nuevas que permitirían vincular la sesión de contexto (de Cloud Code, Open Code, etc.) con cada "commit". De esta forma, el historial de interactividad con la IA quedaría registrado en el control de versiones, proporcionando una auditoría completa de la creación del código.

Integración futura en plataformas de gestión

El análisis predice que en los próximos meses aparecerá sí o sí alguna herramienta que incorpore una mejora en la gestión de cambios con IA. Aunque sería preferible que esto estuviera integrado directamente en GitHub, es probable que surjan soluciones construidas "por encima" de GitHub, tipo Graphite, que se conecten al repositorio pero ofrezcan una interfaz visual diferente para ver los "diffs" y el control de versiones integrado con la IA.

La velocidad de la IA frente a la adaptación humana

Estamos en una época de cambios muy interesantes pero desafiantes, donde la sensación general es que la inteligencia artificial avanza a una velocidad que supera la capacidad de adaptación de las herramientas actuales. La industria todavía depende de flujos de trabajo diseñados para humanos para intentar contener y organizar una producción de software que ahora es, en gran medida, industrial y automatizada.

Conclusión sobre el futuro de las herramientas

Se prevé la inminente llegada de herramientas de terceros que llenen el vacío dejado por GitHub, permitiendo visualizar los cambios y el control de versiones de una forma nativa para la era de la inteligencia artificial. Hasta que eso ocurra, la tensión entre la generación masiva de código y la capacidad limitada de revisión humana seguirá provocando crisis en proyectos de Open Source.

¿Cuál es el factor detonante que ha llevado a considerar que el modelo de Open Source actual está en peligro y es insostenible? El factor principal es la expansión masiva del uso de la inteligencia artificial por parte de los desarrolladores desde el año 2025. La aparición de agentes y herramientas como Cloud Code y Open Code ha facilitado enormemente la generación de código, lo que ha provocado que una gran cantidad de personas utilicen estas herramientas para enviar contribuciones masivas a proyectos de código abierto. Este volumen generado por máquinas ha saturado la capacidad de gestión de los proyectos, creando una situación donde el flujo de trabajo tradicional se rompe ante la disparidad entre la velocidad de generación de la IA y la capacidad de revisión humana.

¿Qué medida drástica implementó el proyecto TLDraw para mitigar la saturación de contribuciones y cuál es su justificación? El equipo de TLDraw decidió cerrar automáticamente cualquier solicitud de extracción (pull request) proveniente de "contribuidores externos", definidos como cualquier persona que no trabaje directamente en el equipo oficial del proyecto. La justificación de Steve, uno de los responsables, es que necesitan "filtrar el ruido" y ser más selectivos, ya que mantener abiertas estas solicitudes implica un compromiso de revisión que ya no pueden cumplir debido a la baja calidad y el alto volumen de las aportaciones generadas por IA.

¿Por qué las contribuciones generadas por IA son problemáticas para los mantenedores a pesar de ser "formalmente correctas"? Aunque muchas de estas solicitudes siguen los procesos técnicos requeridos para realizar una "pull request", a menudo sufren de un contexto incompleto o confuso sobre el funcionamiento global del proyecto. Además, suelen presentar malentendidos en la base de código, llamadas a funciones erróneas y violaciones de las reglas de estilo. Esto significa que, aunque el código parece cumplir con los requisitos administrativos, carece de la lógica y la calidad necesarias para ser funcional y mantenible.

¿Cómo afecta la falta de "follow-up" (seguimiento) por parte de los autores al contrato social del desarrollo colaborativo? En el modelo tradicional, una "pull request" inicia una conversación donde el mantenedor revisa y sugiere cambios, y el autor responde e itera sobre el código. Sin embargo, en las contribuciones masivas de IA, existe poco o nulo seguimiento por parte de los autores, quienes a menudo no responden a las preguntas o sugerencias de los mantenedores. Esto rompe el compromiso implícito de colaboración, obligando a los mantenedores a gastar tiempo revisando código que queda en el "limbo" y nunca llega a fusionarse.

¿De qué manera el concepto de "ataque DDoS de código" ilustra la situación actual de proyectos como Curl y OCaml? Los mantenedores describen la afluencia masiva de reportes y código de baja calidad como un ataque de Denegación de Servicio Distribuido (DDoS), ya que satura los recursos de atención del proyecto. Daniel Stenberg, de Curl, reportó un aumento del 800% en reportes de errores, lo que les lleva a considerar cerrar su programa de recompensas (Bug Bounty). Similarmente, el proyecto OCaml rechazó una contribución de 13.000 líneas generada por IA, argumentando que auditar tal cantidad de código automático es agotador y un uso ineficiente de sus recursos humanos.

¿Por qué se considera que existe una brecha tecnológica fundamental en las herramientas actuales de plataformas como GitHub? La crisis surge porque estamos utilizando herramientas diseñadas para una época en la que el código era escrito por humanos, lo que implicaba una velocidad de producción limitada. Las herramientas actuales de gestión de "issues" y "pull requests" no se han adaptado al volumen industrial generado por las máquinas. Además, plataformas como GitHub agravan el problema al integrar asistentes como Copilot directamente en la interfaz, facilitando aún más la generación de contenido automático sin ofrecer herramientas equivalentes para su filtrado y gestión.

¿Qué estrategias de regulación propone el "Request for Comments" (RFC) del proyecto LLVM para gestionar el código asistido por IA? El proyecto LLVM propone políticas estrictas para aceptar contribuciones, como limitar el tamaño de las solicitudes a menos de 150 líneas adicionales (excluyendo tests) para evitar volcados masivos de código generado. También exigen transparencia, sugiriendo que los "commits" indiquen explícitamente si fueron asistidos por herramientas (ej. "assisted by cloud"), y establecen que la decisión final de aprobar una revisión nunca debe ser tomada por una IA, manteniendo el criterio humano como barrera final.

¿En qué consiste la propuesta de "Prompt Request" y cómo cambia el enfoque de la revisión de código? La "Prompt Request" es una alternativa propuesta donde, en lugar de enviar miles de líneas de código, el contribuidor comparte el "prompt" o instrucción que dio a la IA para generar dicho código. La premisa es que ver el código final aporta poca información sobre la intención del autor, mientras que ver la interacción con la IA permite al mantenedor entender qué se quería lograr. Si el "prompt" es válido, el mantenedor puede ejecutarlo y generar el código él mismo, priorizando la intención sobre la implementación bruta.

¿Qué papel juega la "historia del prompt" (Prompt Story) en la futura trazabilidad de las contribuciones de software? Se plantea la necesidad de herramientas que vinculen la sesión de contexto (la conversación con la IA) directamente a cada "commit" o solicitud de cambio. Esto permitiría tener un historial completo de la interactividad con la inteligencia artificial dentro del control de versiones. De esta forma, los revisores no solo verían el resultado final, sino el proceso lógico y las preguntas que llevaron a la generación de ese código, facilitando una auditoría más profunda y contextualizada.

¿Qué evolución se espera en el ecosistema de herramientas de desarrollo para solucionar esta crisis? Se prevé la aparición inminente de herramientas de terceros construidas "por encima" de GitHub, como Graphite, que incorporen mejoras específicas para la gestión de cambios con IA. Estas nuevas utilidades permitirán visualizar las diferencias ("diffs") y gestionar el control de versiones integrando nativamente el contexto de la inteligencia artificial, llenando el vacío que las plataformas actuales no han logrado cubrir ante la velocidad de avance de la tecnología generativa.