New study just debunked el miedo a la IA open source

En pocas palabras: No. Un estudio observacional de la Universidad de Pekín (2 de julio de 2026) sobre 1.888 repositorios de GitHub que adoptaron agentes como Cursor y Claude Code halló que la llegada de nuevos contribuidores se mantuvo estable e incluso subió levemente.

El miedo era claro: los agentes de IA se comen los “issues” fáciles, los novatos no tienen por dónde entrar y el open source se queda sin relevo. Un nuevo estudio de la Universidad de Pekín, publicado el 2 de julio de 2026 sobre 1.888 repositorios de GitHub, dice que eso no está pasando. La participación de nuevos contribuidores se mantuvo estable o incluso subió un poco. El “new study just debunked” que circula esta semana apunta justo ahí.

El paper de la Universidad de Pekín es un estudio observacional que rastreó 1.888 repositorios de GitHub que adoptaron agentes de codificación con IA (herramientas como Cursor y Claude Code) y comparó su evolución contra un grupo de control que nunca los adoptó. El objetivo: medir si esos agentes expulsan a los recién llegados del software libre. La respuesta corta es que no, aunque aparece otro problema.

¿Realmente los agentes de IA desplazan a nuevos contribuidores?

Es un miedo que suena impecable. Los proyectos de open source viven de que aparezca gente nueva: alguien arregla un typo, después toma un bug fácil, después un feature chico, y un día es mantenedor. Ese embudo es frágil. Si un agente de IA se come todos los “good first issue” antes de que un humano los vea, el embudo se seca.

Plausible, sí. Pero plausible no es lo mismo que real. Y acá es donde el estudio pega el volantazo.

Los investigadores de la Universidad de Pekín miraron qué pasó de verdad en 1.888 repos después de que entró la IA al flujo de trabajo. ¿El resultado? La participación de recién llegados no se derrumbó. Se mantuvo estable, y bajo algunas mediciones incluso subió un poco. El fantasma del “novato desplazado” no aparece en los datos.

Ojo con esto igual: que el miedo grande no se confirme no significa que todo esté bien. Significa que estábamos mirando el lugar equivocado. Sobre eso hablamos en nuestro análisis de seguridad empresarial.

Qué encontró el estudio de la Universidad de Pekín sobre agentes IA y open source

Ponele que dirigís un proyecto en GitHub con 40 colaboradores. Un día alguien sube un CLAUDE.md al repo y de golpe la mitad de los PRs empiezan a salir de un agente. La pregunta obvia: ¿esto ahuyenta a la gente nueva o no?

El estudio, según la cobertura de The New Stack, contesta con números. Estos son los datos duros que sí están confirmados:

• 1.888 repositorios de GitHub que adoptaron agentes de codificación con IA.
• Cursor y Claude Code como las herramientas analizadas.
• 2 de julio de 2026 como fecha de envío del paper a arxiv.org.
• Participación de newcomers estable o levemente al alza tras la adopción.
• Carga de mantenedores en aumento acelerado, el hallazgo incómodo.

Lo interesante es el contraste entre el miedo y lo que salió. Esta tabla lo resume:

Lo que se temía	Lo que muestran los datos
Los agentes toman los issues de principiantes	La participación de novatos se mantuvo o subió
El embudo de nuevos mantenedores se seca	No aparece esa caída en los 1.888 repos
El código IA es imposible de mantener	Sube el volumen de revisión, no un colapso
La IA reemplaza al humano en el repo	El humano ahora revisa más, no menos

El valor del paper es ese: convierte una charla de sobremesa (“la IA va a matar el open source”) en algo medible. Y medido, el miedo principal no se sostiene.

¿Cómo se midió el impacto de los agentes en los repositorios?

Acá está la parte técnica que le da peso al estudio. Los investigadores no contaron commits y listo. Usaron dos decisiones metodológicas que importan.

Primero, definieron el punto de adopción de forma concreta: el momento en que un proyecto sube su primer archivo de configuración de agente. Un .cursorrules (de Cursor) o un CLAUDE.md (de Claude Code). Es un marcador limpio, con fecha, imposible de discutir. Antes de ese commit, el proyecto era “sin IA”; después, “con IA”.

Segundo, aplicaron difference-in-differences. Si no laburaste nunca con econometría, la idea es simple: comparás cómo cambió un grupo que adoptó la herramienta contra un grupo parecido que no la adoptó, en el mismo período. Así separás lo que causó la IA de lo que ya venía pasando por moda, temporada o el crecimiento natural del proyecto. Para más detalles técnicos, mirá como explicamos en nuestra guía sobre ChatGPT.

¿Por qué es el estándar de oro para causa-efecto? Porque un proyecto que adopta Cursor probablemente ya era más activo que el promedio. Si solo miraras a los que adoptaron, confundirías “la IA trajo gente” con “los proyectos populares adoptan IA y además atraen gente”. El grupo de control cancela ese ruido. Sacás la foto de lo que la herramienta cambió de verdad.

¿Es perfecto? No. Es un estudio observacional sobre repos que ya existían, no un experimento de laboratorio, y como cualquier análisis de este tipo depende de que el grupo de control esté bien emparejado. Tomalo con esa pinza. Pero como evidencia, es de lo más serio que salió sobre el tema.

El verdadero problema: la sobrecarga de los mantenedores

Si el miedo de los novatos era el titular, este es el que debería preocupar.

El mismo estudio encontró que la carga de trabajo de los mantenedores está subiendo rápido en los proyectos que adoptaron agentes. Y tiene lógica de sobra. Un agente de IA baja el costo de escribir un pull request casi a cero. Cualquiera, novato o no, puede generar un PR de 300 líneas en cinco minutos. El problema es que revisar ese PR sigue costando lo mismo que siempre: tiempo, atención y criterio humano.

Pensalo así. Un colaborador manda un PR generado por IA que compila, pasa los tests y parece razonable, el mantenedor lo abre, ve que la lógica está bien pero el estilo no matchea, que faltan casos de borde, que la IA “inventó” un helper que ya existía en otro módulo, y ahora tiene que explicar todo eso en un review que le lleva más que escribir el código él mismo.

Ese es el cuello de botella. La producción se abarató; la revisión no. El resultado es una pila de PRs cada vez más grande sobre las mismas dos o tres personas que sostienen el proyecto.

¿Qué significa esto para el futuro del software libre?

La foto queda rara. Por un lado, entra gente (el embudo de contribuidores no se rompió). Por el otro, la gente que sostiene los proyectos está más quemada que antes. Más entrada, más presión arriba. Más contexto en nuestro análisis de modelos de lenguaje.

La pregunta es: ¿qué pasa cuando el pipeline de contribuidores crece pero el de mantenedores no da abasto? Si nadie hace nada, pasa lo de siempre en el open source: burnout, proyectos abandonados, un mantenedor que un día dice “no puedo más” y archiva el repo. La IA no cambió esa dinámica, la aceleró.

Lo que sí cambia es dónde hay que invertir. Antes el cuello de botella era conseguir gente que escriba. Ahora es conseguir formas de revisar a escala sin que dos personas se hagan cargo de todo. El open source va a necesitar herramientas de triage y revisión asistida tanto como necesitó los CI/CD hace una década.

Herramientas de IA que cambian cómo se contribuye en open source

No es solo Cursor y Claude Code, aunque son los dos que el estudio puso bajo la lupa. La lógica de fondo se repite en todo el ecosistema de agentes: un archivo de configuración en el repo que le dice al agente cómo comportarse.

¿Para qué sirve un archivo CLAUDE.md o .cursorrules?

Es el manual de estilo del proyecto, pero para la IA. En un CLAUDE.md ponés convenciones de código, comandos para correr los tests, qué no tocar, cómo nombrar las cosas. Cuando un colaborador usa el agente dentro de ese repo, el agente lee esas reglas y genera contribuciones más alineadas con el proyecto. Fue justo ese archivo el que los investigadores usaron como señal de adopción.

¿Ayudan estos archivos a estandarizar contribuciones?

En teoría sí, y ese es el lado bueno. Un buen archivo de configuración baja la fricción para el que llega: el agente ya sabe las reglas de la casa, así que el PR sale más prolijo. El problema es que estandarizar la generación no estandariza la calidad del criterio. Un PR prolijo que resuelve mal el problema sigue comiéndole tiempo al mantenedor.

¿Qué deberían hacer mantenedores y proyectos ahora?

Si sostenés un proyecto, el estudio te da una señal concreta: el problema no es que entre menos gente, es que no das abasto para revisar. Algunas movidas que ayudan: En según detallamos sobre tecnologías de Google profundizamos sobre esto.

• Automatizá el primer filtro: bots de checks (tests, lint, cobertura, formato) que rechacen lo obvio antes de que un humano abra el PR. Que tu tiempo se gaste solo en lo que ya pasó la reja.
• Poné reglas de configuración claras: un CLAUDE.md o .cursorrules bien escrito reduce los PRs que hay que devolver por estilo o convenciones.
• Onboarding estructurado: documentá cómo se contribuye, qué se acepta y qué no. Cuanto más claro, menos ida y vuelta por PR.
• Triage antes que review: etiquetar y priorizar rápido evita que la pila de PRs te tape. No todo merece un review profundo el mismo día.
• Pedí contexto en los PRs generados por IA: exigir que el autor explique qué probó y por qué. Un PR sin contexto humano es el que más caro sale de revisar.

Si tu proyecto crece y empezás a necesitar más infraestructura (CI propio, un servidor para correr los tests pesados, alojar la documentación), tenés opciones locales para eso: en donweb.com conseguís hosting y VPS en Argentina sin pelearte con el cambio.

Errores comunes al interpretar este estudio

• Leerlo como “la IA no cambia nada”: falso. Cambia, y bastante. Lo que dice es que el cambio no fue expulsar novatos, sino sobrecargar mantenedores. Es un problema distinto, no la ausencia de problema.
• Tratar la correlación como causa sin mirar el método: justamente el difference-in-differences existe para eso. Si citás el estudio, citá que usó grupo de control, no que “los repos con IA tienen más gente”.
• Asumir que aplica a tu proyecto tal cual: son 1.888 repos, un promedio. Tu proyecto chico de nicho puede comportarse distinto. El dato agregado orienta, no dicta.
• Confundir volumen de PRs con progreso: más pull requests generados por IA no es lo mismo que más valor. Si nadie los revisa bien, es deuda, no avance.

Preguntas Frecuentes

¿Qué dice el estudio de la Universidad de Pekín sobre IA y open source?

Que los agentes de codificación con IA no están expulsando a los nuevos contribuidores del open source. Sobre 1.888 repositorios de GitHub, la participación de recién llegados se mantuvo estable o subió levemente tras adoptar herramientas como Cursor y Claude Code. El paper se envió a arxiv.org el 2 de julio de 2026.

¿Los agentes de IA como Cursor y Claude Code desplazan a los programadores nuevos?

Según el estudio, no. El miedo de que los agentes tomen los issues fáciles y sequen el embudo de novatos no se confirmó en los datos. La entrada de nuevos contribuidores no cayó. Lo que sí subió fue la carga de trabajo de los mantenedores que revisan las contribuciones.

¿Por qué aumenta la carga de trabajo de los mantenedores con agentes de IA?

Porque la IA abarata escribir código pero no abarata revisarlo. Generar un pull request con un agente cuesta minutos; revisar ese PR sigue costando el mismo tiempo y criterio humano de siempre. El resultado es más volumen de contribuciones sobre las mismas pocas personas que sostienen cada proyecto.

¿Qué es el método difference-in-differences?

Es una técnica estadística que compara cómo cambió un grupo que adoptó una herramienta contra un grupo parecido que no la adoptó, en el mismo período. Sirve para separar el efecto real de la herramienta de las tendencias que ya existían. Es el estándar de oro para inferir causa y efecto en datos observacionales.

¿Cómo detectaron los investigadores que un proyecto adoptó IA?

Marcaron el momento en que un repositorio sube su primer archivo de configuración de agente: un .cursorrules de Cursor o un CLAUDE.md de Claude Code. Ese commit, con fecha exacta, define el punto de adopción y permite comparar el antes y el después del proyecto.

Conclusión

El miedo estrella (que la IA iba a matar el relevo generacional del open source) no aguantó el contacto con los datos. Los 1.888 repos de la Universidad de Pekín muestran que los novatos siguen entrando. Buena noticia.

La mala es que el problema se corrió de lugar. Ahora el cuello de botella son los mantenedores, ahogados en pull requests que cuesta lo mismo revisar que antes pero que llegan diez veces más rápido. Si sostenés un proyecto, la jugada de 2026 no es frenar la IA, es blindar la revisión: automatizá el primer filtro, escribí buenas reglas de configuración y ponele triage a la pila antes de que la pila te ponga a vos. La entrada de gente ya no es el problema. Sostener a quien revisa, sí.

Fuentes

• The New Stack – A new study just debunked the biggest fear about AI and open source
• arXiv.org – repositorio donde se publicó el paper de la Universidad de Pekín (2 de julio de 2026)
• GitHub – plataforma de los 1.888 repositorios analizados