Volver a las novedades

¿Por qué los proyectos están desactivando los pull requests para código generado por IA?

Respuesta corta: hay dos motivos distintos cerrando esa puerta, y piden respuestas opuestas de tu parte. El primero es el costo de revisión: el repositorio denoland/celld desactivó los pull requests por completo, y su README dice que los agentes de código hacen demasiado barato enviar un cambio grande y de bajo contexto, que le cuesta al mantenedor más tiempo del que ahorra. El segundo es la procedencia legal: el proyecto QEMU rechaza toda contribución que se crea que incluye o deriva de contenido generado por IA, porque la situación de derechos de autor de esa salida no está resuelta. El primero se arregla enviando un parche más pequeño y enfocado. El segundo no se arregla escribiendo mejor código.

¿Qué desactivó exactamente el repositorio celld?

El repositorio celld, publicado bajo la organización denoland en GitHub, tenía 3.166 estrellas y 101 forks cuando lo leímos, el 12 de agosto de 2026. Su README trae una sección llamada Contributions con este texto, citado literalmente:

Pull requests are disabled. Coding agents make it too easy to send a large, low-context change that costs maintainers more time than it saves. Thoughtful contributions are welcome; please understand the code, keep the patch focused, and respect the review time you are asking for.

Dos cosas hacen que esto sea más que un desahogo en un archivo de texto. Primero, el comportamiento coincide con la declaración: la API REST de GitHub informa los pull requests como no disponibles en ese repositorio y devuelve 404 en su endpoint de pull requests, mientras que un repositorio con la función activada responde con normalidad. Segundo, el texto no es la reacción a una mala semana. Ya estaba en el README de la primera versión publicada, el 2 de agosto de 2026, y seguía ahí el 12 de agosto de 2026.

Lee la redacción con cuidado, porque es más estrecha de lo que sugiere el titular. El README de celld no prohíbe la IA, y no te prohíbe a ti. Dice que las contribuciones pensadas son bienvenidas, y pide otro formato de entrega: un adjunto de git format-patch enviado a la dirección de contacto del proyecto. Lo que se rechazó es la economía del botón de pull request, donde enviar cuesta un clic y revisar cuesta una tarde.

¿La prohibición de QEMU es lo mismo?

QEMU cerró otra puerta, y confundir las dos te manda a buscar el arreglo equivocado. La página sobre procedencia del código en la documentación de desarrollo de QEMU, leída el 12 de agosto de 2026, declara su política en mayúsculas:

Current QEMU project policy is to DECLINE any contributions which are believed to include or derive from AI generated content. This includes ChatGPT, Claude, Copilot, Llama and similar tools.

El motivo que da QEMU no tiene nada que ver con el tamaño del parche. Es el Developer's Certificate of Origin: quien contribuye debe certificar que entiende la situación de derechos de autor y de licencia de lo que envía, y con los generadores de contenido por IA esa situación es, en palabras del propio proyecto, "ill-defined with no generally accepted, settled legal foundation". La misma página abre una excepción fácil de pasar por alto, y merece citarse en vez de resumirse: "This policy does not apply to other uses of AI, such as researching APIs or algorithms, static analysis, or debugging, provided their output is not included in contributions."

Así que la diferencia práctica para ti es total. En celld, un parche más pequeño y mejor explicado es bienvenido. En QEMU, ninguna disciplina de parche ayuda, porque la objeción es de dónde vino el texto, no cuánto texto hay. Averiguar cuál de los dos casos tienes enfrente cuesta un minuto de leer los documentos del propio proyecto, y eso decide si mejoras el parche o no envías nada.

¿De qué tamaño es un cambio que un agente de IA de programación produce en realidad?

Medimos nuestro propio repositorio, que es una muestra útil justamente por ser extrema: este sitio lo escriben agentes de IA de programación trabajando en git worktrees paralelas. Leyendo el historial completo el 12 de agosto de 2026, hay 251 commits sin merge hechos entre el 18 de julio y el 10 de agosto de 2026. El commit mediano cambia 86 líneas. El percentil 90 cambia 987. El mayor cambia 17.718 líneas.

Ese commit mayor no es trabajo de agente, y el segundo mayor tampoco. "Set up a fresh Laravel app" (17.718 líneas) e "Install Laravel Boost" (6.275 líneas) se hicieron con 45 segundos de diferencia el primer día, y los dos son un instalador de paquetes escribiendo archivos, no alguien resolviendo un problema. Se pueden separar las dos categorías con más que una suposición, porque todo commit hecho dentro de una sesión de agente en este repositorio lleva un trailer Claude-Session en el mensaje. 214 de los 251 commits, el 85%, lo llevan, y ninguno de los dos mayores lo lleva. Contando por línea en vez de por commit la porción baja al 70%, y la mayor parte de la diferencia viene de esos dos commits de instalación.

Restringir la medición a esos 214 commits de sesión de agente mueve los números menos de lo que uno esperaría, y ese es el hallazgo. La mediana pasa a 91 líneas, el percentil 90 a 920, y la mayor entrega individual de un agente en la historia del proyecto tiene 4.007 líneas. La porción de entregas demasiado grandes casi no se mueve: 21,1% de todos los commits cambian más de 500 líneas (53 de 251), contra 21,0% de los de agente (45 de 214). Son dos fracciones cercanas, y no un número solo, pero lo bastante cercanas para decir que sacar el bootstrap humano de la cuenta no salva la cola, porque la cola no es el bootstrap.

En el historial completo la concentración es severa: los diez commits más grandes cargan el 43% de todas las líneas alteradas en el proyecto, mientras que la mitad más pequeña de todos los commits carga el 3%. Es decir: la entrega típica de un agente de IA es perfectamente revisable, y es en la cola donde se va la tarde del mantenedor. Una política escrita contra esa cola también le pega a tus parches razonables, que es exactamente lo que pasó en celld.

Corre la misma medición en tu repositorio con un comando:

git log --no-merges --pretty=tformat:'@' --numstat \
| awk '/^@/{if(n)print s; s=0; n=1; next} {s+=$1+$2} END{if(n)print s}' \
| sort -n \
| awk '{v[NR]=$1; t+=$1; if($1>500) big++} END{
    for(i=1;i<=int(NR/2);i++) half+=v[i]
    for(i=NR-9;i<=NR;i++) top+=v[i]
    printf "commits: %d\nmediana: %d\np90: %d\nmayor: %d\narriba de 500 lineas: %d (%d%%)\n10 mayores = %d%% de las lineas\nmitad menor = %d%% de las lineas\n", NR, v[int(NR/2)], v[int(NR*0.9)], v[NR], big, big*100/NR, top*100/t, half*100/t}'

Los números de arriba son la salida exacta de ese comando en nuestro repositorio, y el recorte solo de agente es la misma secuencia con --grep='Claude-Session' agregado al git log. Cuenta líneas agregadas más eliminadas por commit, ignora los commits de merge y trata los archivos binarios como cero, así que un repositorio lleno de imágenes se verá más pequeño de lo que se siente. En un repositorio con exactamente un commit, la mediana y el p90 salen los dos como cero, porque el índice que usa el script no tiene una segunda posición a la que apuntar y awk lee un valor no inicializado como cero; a partir de dos commits ya imprime números reales, y deja de ser una estimación gruesa en el orden de las decenas.

¿Cómo enviar un parche cuando los pull requests están desactivados?

La respuesta es git format-patch, y es más viejo que el pull request. Convierte cada commit de tu rama en un archivo que lleva el diff, el mensaje del commit, el autor y la fecha, que es todo lo que un mantenedor necesita para aplicar tu trabajo con la atribución intacta. La secuencia, probada en un repositorio desechable antes de publicar:

git switch -c mi-cambio
# trabaja, después haz commit normalmente
git format-patch main

Eso escribe un archivo por commit, con el nombre 0001-asunto-de-tu-commit.patch, en el directorio actual. Adjúntalos a la dirección que pide el proyecto, en orden. Si el proyecto usa lista de correo, git send-email 0001-*.patch hace el envío sin que tu cliente de correo estropee los espacios, que es la forma clásica de que un parche llegue inservible. Del otro lado, el mantenedor corre git am 0001-asunto-de-tu-commit.patch y tus commits entran en su historial con tu nombre.

Un hábito que vale la pena llevarse de aquí incluso cuando el pull request está abierto: antes de pedirle una revisión a alguien, corre git diff --stat main...HEAD. Eso imprime el tamaño del favor que estás por pedir. Ver "47 files changed" antes de que lo vea el mantenedor es la revisión más barata que vas a conseguir.

¿Cómo mantener el cambio de un agente lo bastante pequeño para que alguien lo revise?

La expresión que hay que llevarse del README de celld es low-context change, cambio de bajo contexto, y no cambio grande. Un parche de 900 líneas que hace una sola cosa y se explica es más fácil de revisar que uno de 200 líneas que toca nueve archivos sin relación entre sí, y los agentes de IA de programación son muy buenos produciendo el segundo por accidente. Cuatro hábitos que mantienen la entrega revisable:

  • Di qué no tocar. Nombrar en el prompt los archivos y directorios fuera del alcance quita la mayor parte del volumen accidental, porque si no el agente ordena lo que encuentra por el camino.
  • Separa lo mecánico de lo significativo. Un renombrado o un reformateo va en su propio parche, para que el revisor lo pase por encima y gaste atención en el commit que cambia el comportamiento.
  • Pide un frente a la vez. Una tarea grande genera una entrega grande, lenta de comprobar y difícil de rechazar, lo que deja al revisor eligiendo entre aceptar un bloque que no leyó y pedir todo de nuevo.
  • Escribe tú el mensaje, o revísalo línea por línea. El mensaje del commit es el contexto que le falta al mantenedor, y es la parte que el agente tiene menos evidencia para escribir, porque no vio la discusión que motivó el trabajo.

Escribimos por separado sobre el otro lado de esta mesa, cómo revisar código escrito por agentes de IA cuando eres quien recibe, y sobre integrar el trabajo de varios agentes dentro de tu propio repositorio. Este artículo trata del tercer caso, el de entregar dentro del repositorio de otra persona.

¿Deberías avisar que un agente de IA escribió el parche?

Donde el proyecto declara una política, la respuesta ya está decidida por ti, y QEMU es el caso claro: enviar ahí código escrito por un agente sin decirlo significa certificar, bajo el Developer's Certificate of Origin, algo que no estás en posición de certificar. Donde no existe política, avisar sigue siendo el error más barato. El mantenedor que se entera después lo lee como un contribuidor que desperdició su tiempo de revisión a propósito, y ese juicio se pega a tu nombre, no a la herramienta.

Hay un argumento práctico encima del ético. Decirle al mantenedor que un agente produjo el parche y que verificaste partes específicas de él le muestra dónde mirar, lo que hace la revisión más rápida y tu parche más probable de entrar. El aviso que ayuda es específico: qué probaste, qué leíste con atención y dónde estás menos seguro.

Lo que este artículo no resuelve

Dos proyectos son dos proyectos, no una tendencia. Llegamos a celld y a QEMU siguiendo una discusión en Hacker News y después leyendo los documentos de cada proyecto, lo que basta para probar que la práctica existe y para mostrar que la misma puerta cerrada tiene dos causas sin relación entre sí, pero no es un relevamiento, y no tenemos un conteo de cuántos repositorios hicieron lo mismo.

Nuestros números cargan una limitación que vale declarar con precisión. El trailer Claude-Session marca la sesión en la que se hizo el commit, no la autoría de cada línea, y una persona puede teclear dentro de una sesión de agente. Así que los 214 commits son salida de sesión de agente, y no prueba de que un agente escribió cada línea de ellos, y ninguna medición nuestra va más allá. El conteo de líneas también es un sustituto del esfuerzo de revisión, no el esfuerzo en sí. Un cambio de 40 líneas en un camino de pago merece más atención que uno de 900 líneas en un catálogo de traducción, y ningún percentil sabe eso.