Enviar código generado por IA a proyectos open source

Qué hacer antes de enviar código asistido por IA a un repositorio upstream

Los proyectos de código abierto publican actualmente políticas sobre el código asistido por IA, y dichas políticas no son uniformes. Por tanto, el hábito es sencillo: busque la política antes de escribir el parche y realice una declaración precisa al enviarlo. Una regla subyace en ambos casos: nunca envíe una línea que no pueda explicar durante la revisión.

Un parche correcto será rechazado si el proyecto prohíbe el código generado o si usted ocultó el origen del mismo. El coste recae sobre su reputación y permanece allí, ya que un mantenedor que descubra la omisión más tarde no tendrá motivos para confiar en el resto de su historial. Primero, algunas definiciones, dado que las políticas las utilizan. Un LLM (large language model) es el modelo detrás de su agente de programación. Un PR (pull request) en GitHub es un MR (merge request) en GitLab, y todo lo expuesto a continuación se aplica a ambos. El DCO (developer certificate of origin) es la línea de firma al final de un mensaje de commit, y resulta ser el centro de toda la controversia.

En qué punto se encuentran las políticas de código abierto sobre IA

Los proyectos se han consolidado en cuatro grupos. Cada ejemplo a continuación tiene fecha, ya que estos textos cambian.

Prohibido. El consejo de Gentoo votó el 14 de abril de 2024 que está "expresamente prohibido contribuir a Gentoo con cualquier contenido creado con la asistencia de herramientas de inteligencia artificial de procesamiento de lenguaje natural". Las directrices de commit de NetBSD califican la salida de un LLM como "código contaminado" que "no debe ser enviado sin la aprobación previa por escrito del núcleo". El documento de procedencia de código de QEMU, a fecha de agosto de 2026, sigue indicando que el proyecto "RECHAZARÁ cualquier contribución que se crea que incluye o deriva de contenido generado por IA".

Solo análisis. La mayoría de las prohibiciones son más limitadas de lo que sugieren los titulares. El documento de QEMU dice que la política "no se aplica a otros usos de la IA, como la investigación de APIs o algoritmos, el análisis estático o la depuración, siempre que su resultado no se incluya en las contribuciones". Puede usar el agente para leer el código. No puede distribuir lo que escribió. Esa distinción es la línea de trabajo dentro de la mayoría de los proyectos restrictivos, y es la que la gente pasa por alto.

Divulgación obligatoria. El consejo de Fedora aprobó una política sobre contribuciones asistidas por IA en octubre de 2025. Permite el uso de herramientas y deposita la responsabilidad en la persona: el colaborador es el autor, es plenamente responsable de toda la contribución y debe revelar cuándo una parte significativa de la misma proviene de una herramienta sin cambios. El kernel de Linux añadió una página de asistentes de codificación en su documentación de procesos en diciembre de 2025, con un apartado para registrar la herramienta y una regla estricta sobre quién puede firmar los cambios.

Sin nada por escrito. Este sigue siendo el caso común. Un preimpreso de mayo de 2026 analizó 1.000 repositorios populares de GitHub y encontró 118 con alguna política de IA escrita. El silencio no es permiso. Pregunte en el gestor de incidencias en una sola frase antes de escribir el parche, y la respuesta se convertirá en un registro público al que podrá hacer referencia más adelante.

Por qué los mantenedores escribieron estas reglas

La primera razón es la carga de revisión, y la aritmética solo tiene un sentido. Un agente genera una solicitud de fusión (merge request) plausible de 400 líneas en un minuto. Revisar esa solicitud correctamente le cuesta a un mantenedor una tarde entera, y la mayoría de los mantenedores son voluntarios. El coste de enviar una contribución cayó casi a cero. El coste de revisarla no se movió en absoluto.

curl muestra el extremo lejano de esa curva. Daniel Stenberg informó a mediados de 2025 que aproximadamente una quinta parte de los informes de seguridad que llegaban a través del programa de recompensas por errores (bug bounty) del proyecto eran lo que él denomina basura de IA: informes que mencionan funciones y rutas de código reales, describen un ataque plausible y no contienen nada útil. El proyecto finalizó la recompensa a principios de 2026 en lugar de seguir financiando esa avalancha. Esos eran informes en lugar de parches, pero es el mismo mecanismo el que hace que un mantenedor abra su PR ya cansado.

GNOME Calendar definió el problema mediante una etiqueta. En junio de 2026, el proyecto introdujo "Probabilistically Automated" para las solicitudes de fusión que muestran una "dependencia mayor o total de la 'inteligencia' artificial para generar código", y nombró el síntoma con exactitud: "usualmente acompañado por una falta de pruebas adecuadas, y la finalización de parches basados en el comportamiento teórico pretendido en lugar de en la corrección del código". Lea esa última frase dos veces. El código parece que debería funcionar. Nadie comprobó si realmente lo hace.

La segunda razón es la procedencia, es decir, de dónde proviene el código y bajo qué licencia. QEMU expone el conflicto claramente: firmar (sign-off) implica que usted "entiende completamente el estado de los derechos de autor y la licencia del contenido" que aporta, y el estado de los derechos de autor de la salida de un modelo no está resuelto. El consejo de Gentoo dio la misma razón, junto con la calidad y la ética. Usted no tiene que estar de acuerdo con la interpretación legal. Usted sí debe notar que es una decisión que corresponde al mantenedor, no a usted.

¿Cómo encuentro la política de IA de un proyecto?

Busque en estos lugares, en este orden.

• CONTRIBUTING.md en la raíz del repositorio, luego .github/CONTRIBUTING.md, y después cualquier archivo DCO adyacente.
• La documentación para desarrolladores. QEMU mantiene su norma en docs/devel/code-provenance.rst. El kernel mantiene la suya en Documentation/process/coding-assistants.rst.
• El sitio web o la wiki del proyecto. La política de Gentoo reside en la página de la wiki del consejo, y la de NetBSD se encuentra en las directrices de commit.
• El gestor de incidencias y el archivo de la lista de correo. Por lo general, una política existe allí durante meses antes de que alguien la redacte en el repositorio.

Desde el interior de un checkout, un grep cubre la mayor parte:

grep -rniE '(llm|copilot|chatgpt|generative|ai-generated|ai-assisted)' CONTRIBUTING.md docs/ .github/ 2>/dev/null | head -20

Luego, lea el historial propio del proyecto, ya que la convención confirmada prevalece sobre cualquier resumen de la misma:

git log --format='%(trailers:key=Assisted-by,valueonly)' | grep . | sort | uniq -c
git log --format='%(trailers:key=AI-used-for,valueonly)' | grep . | sort | uniq -c

Un recuento junto a un valor de trailer le indica la forma que utiliza realmente este proyecto. Un resultado vacío significa que nadie ha realizado una declaración en esa forma aquí, lo cual también es información. Si el proyecto reside en GitHub y el flujo de trabajo es nuevo para usted, cómo funcionan los pull requests y los forks en GitHub cubre la mecánica que asume esta sección.

Divulgación en el trailer del commit, no en un comentario

Un trailer es una línea Key: value en el último párrafo del mensaje de un commit. Git ya utiliza este formato para Signed-off-by: y Co-authored-by:, y las herramientas lo analizan, por lo que es la única divulgación que viaja con el código dentro del árbol.

net: release the buffer on the error path

The error path returned before releasing the buffer, so every failed
setup leaked one page.

Assisted-by: Claude:claude-3-opus coccinelle sparse
Signed-off-by: Your Real Name <you@example.com>

El kernel documenta ese formato como Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], y es explícito sobre el límite de la línea: "Los agentes de IA NO DEBEN añadir etiquetas Signed-off-by. Solo los humanos pueden certificar legalmente el Developer Certificate of Origin (DCO)". El nombre del agente va en Assisted-by. Su nombre va en Signed-off-by. Nunca permita que una herramienta escriba el segundo, y nunca permita que invente una dirección Co-authored-by que no pertenece a nadie.

Los nombres varían, así que copie el local en lugar de inventar el suyo. Un parche publicado en la lista de QEMU en mayo de 2026 propuso relajar la prohibición de ese proyecto para cambios mecánicos, pruebas, documentación y correcciones de errores de veinte líneas o menos, registrados con un trailer como AI-used-for: tests, docs. A fecha de agosto de 2026, eso es una propuesta en una lista de correo y el documento comprometido todavía rechaza el contenido generado. Un proyecto cambió su postura dos veces entre 2023 y 2026. El próximo movimiento no le esperará, por lo que el método importa más que la lista.

git commit -s --trailer "Assisted-by: Claude:claude-3-opus" -m "net: release the buffer on the error path"
git log -1 --format='%(trailers:key=Assisted-by,valueonly)'

--trailer requiere Git 2.32 o posterior. El segundo comando debería devolverle el valor directamente. Una línea vacía significa que git no analizó el trailer, casi siempre porque hay una línea en blanco o una frase común dentro del bloque de trailer al final del mensaje. Para una serie que ya escribió, git rebase --signoff origin/main añade la firma a cada commit, y git interpret-trailers --in-place --trailer "Assisted-by: Claude:claude-3-opus" msg.txt edita un archivo de mensaje.

Vale la pena planificar dos modos de fallo. Un squash merge reescribe el mensaje del commit, así que en un proyecto que utiliza squash, repita la divulgación en la descripción del PR donde el mantenedor la lea. Además, un comentario de revisión no es un registro, porque los comentarios pueden editarse y nunca llegan al historial de git.

La precisión funciona en ambos sentidos. Assisted-by en un commit que usted escribió a mano es ruido, y hace que sus divulgaciones reales valgan menos. Omitirlo en un commit que escribió el agente es lo que termina la relación.

¿Qué certifica realmente Signed-off-by?

El DCO es un texto breve, versión 1.1, publicado en developercertificate.org y utilizado por el kernel, por QEMU y por muchos otros. Añadir Signed-off-by: Your Name <you@example.com> indica que usted lo certifica. Lea lo que está certificando, ya que la mayoría de las personas lo firman sin haberlo leído nunca.

La cláusula (a) dice que la contribución "fue creada en su totalidad o en parte por mí y tengo el derecho de enviarla bajo la licencia de código abierto indicada en el archivo". La cláusula (b) cubre el trabajo basado en código abierto anterior que usted tiene derecho a transmitir con modificaciones. La cláusula (c) cubre el código entregado por alguien que certificó lo mismo. La cláusula (d) dice que usted entiende que la contribución y la información personal en su firma son públicas y se conservan indefinidamente.

Observe lo que falta. El DCO nunca dice que usted haya escrito cada carácter. Dice que usted tiene el derecho de enviar el código bajo esta licencia. Por eso el código generado encaja de forma incómoda aquí: la cuestión no es la autoría, sino si usted puede dar cuenta del origen. La mayoría de los proyectos que requieren una firma también requieren un nombre real, por lo que un seudónimo no supera la verificación. Añada la línea con git commit -s, que lee user.name y user.email de su configuración de git. Cuando un bot de DCO rechaza su PR y nombra el commit que carece de la línea, git rebase --signoff origin/main y un force push a su rama lo solucionan.

Firmar un commit no es lo mismo que realizar un sign-off

git commit -s añade una línea de texto. git commit -S genera una firma criptográfica sobre el objeto commit utilizando su clave GPG o SSH. Responden a preguntas distintas. La firma certifica que este commit proviene del titular de dicha clave y que no ha sido alterado desde entonces. No indica nada sobre el origen del código contenido; por lo tanto, un commit firmado que contenga código generado no revelado sigue estando firmado, pero puede infringir una política. El sign-off es una declaración sobre el origen. La firma es una declaración sobre la identidad. Los proyectos que requieren ambos solicitarán ambos.

Nunca envíe código que no pueda explicar en una revisión

Esta es la prueba, y no se trata realmente de honestidad. Para cada línea: ¿para qué sirve esto y qué falla si se elimina? Si falta alguna de las dos respuestas, el parche no está listo, porque el comentario de revisión llegará y su respuesta será otra ronda de generación. Los revisores se dan cuenta. Ese es el momento en que un colaborador se convierte en un coste. Hágase la misma pregunta sobre los casos límite, la entrada vacía, la ruta de fallo y el segundo llamador.

Ejecute el componente. Compílelo, ejecute la suite de pruebas del proyecto y escriba un reproductor para el error que afirma corregir. La documentación del kernel ofrece la alternativa honesta en palabras claras: "Si la corrección no pudo ser compilada o probada, o si no se pudo producir un reproductor, dígalo explícitamente: los mantenedores pierden actualmente demasiado tiempo analizando informes no verificados y correcciones no probadas". Escribir "No pude probar esto en hardware real" no le cuesta nada. Dar a entender que lo hizo le cuesta el proyecto.

Responda usted mismo a los comentarios de revisión, con sus propias palabras y a su propio ritmo. Una respuesta que llega treinta segundos después del comentario y lo reformula en cinco párrafos le dice al mantenedor exactamente lo que ha ocurrido. Mantenga también el diff pequeño. Cuarenta líneas que usted entiende completamente valen más para un proyecto que una refactorización de cuatrocientas líneas que usted supervisó. Si su agente sigue entregando más de lo que pidió, una habilidad que lo limita al cambio más pequeño que funciona es una forma de mantener el parche reducido a algo que todavía pueda defender línea por línea.

Mantenga las instrucciones del agente en el repositorio

Las instrucciones que proporciona a su agente forman parte de su cadena de herramientas, así que trátelas como si fueran código. Un archivo en la raíz del repositorio, generalmente AGENTS.md, contiene el comando de compilación, el comando de pruebas, el formato de los mensajes de commit, el requisito de firma y las reglas de estilo que el proyecto ya documenta. Ese archivo está versionado y es revisable, y será el mismo mañana que hoy. Las instrucciones escritas de memoria en cada sesión producen un parche diferente en cada sesión, y usted no sabrá qué sesión produjo el parche que fue rechazado. Escribir un AGENTS.md que tanto un agente como un humano puedan leer cubre el archivo en sí.

Una advertencia sobre los repositorios de otras personas. No haga que su primera contribución sea un PR que añada un archivo de instrucciones de agente a un proyecto que usted no mantiene. Se interpreta como un intento de establecer la política de herramientas del proyecto desde fuera, y es una forma rápida de que su cuenta se asocie con algo de lo que los mantenedores ya están cansados. Mantenga el archivo en su fork hasta que alguien lo solicite.

El lugar donde ejecute el agente importa por la misma razón. Un agente que pueda compilar el proyecto y ejecutar sus pruebas dentro de un entorno aislado (sandbox) que usted controle le proporciona un parche que usted realmente ha verificado, lo cual es la diferencia entre declarar asistencia y declarar una suposición. Ejecutar un agente de programación en su propio VPS cubre esa configuración, y las diferencias prácticas entre Claude Code, Cursor, Codex y Copilot cubre cómo difieren las herramientas en el día a día.

El método, una vez que la política cambia

1. Localice la política establecida antes de escribir nada: repositorio, documentación para desarrolladores, sitio web o gestor de incidencias.
2. Si no existe una política, pregunte en la incidencia con una sola frase y guarde la respuesta.
3. Realice la divulgación en el formato que utilice el proyecto, en el trailer del commit, y repítala en el cuerpo del PR si el proyecto utiliza squash.
4. Firme con su nombre real, sabiendo que esa línea es una declaración sobre su derecho a enviar el código.
5. Revise su propio parche como si lo hubiera escrito un extraño, porque así fue.

Cada proyecto mencionado en esta página habrá cambiado para cuando usted lo lea. Los cinco pasos no cambian.

FAQ

¿Debo revelar que he utilizado un agente de programación basado en IA?

Consulte el proyecto, ya que la respuesta se establece a nivel local. Fedora exige la divulgación cuando una parte significativa de la contribución proviene de una herramienta sin cambios. El kernel de Linux solicita un trailer Assisted-by. Gentoo y QEMU, a fecha de agosto de 2026, no aceptan la contribución en absoluto. Cuando no haya nada escrito, hágalo constar de todos modos en un trailer del commit. Un mantenedor que se entere más tarde reaccionará ante la omisión y no ante la herramienta, y esa reacción se aplicará a todo lo demás que haya enviado.

¿Qué proyectos de código abierto prohíben el código generado por IA?

Como instantánea de agosto de 2026: Gentoo desde abril de 2024, NetBSD, que trata la salida de LLM como código contaminado que requiere aprobación del núcleo, QEMU, que rechaza las contribuciones derivadas de contenido generado, y varias aplicaciones de GNOME, incluidas Loupe y Calendar. Lea el texto propio de cada proyecto en lugar de esta lista, ya que quedará obsoleta. Tenga en cuenta la exención que comparten la mayoría: usar un modelo para investigar una API, ejecutar análisis estáticos o ayudarle a depurar suele estar permitido, siempre que su salida no esté en el parche.

¿Cuál es la diferencia entre Signed-off-by y un commit firmado?

Signed-off-by es una línea de texto plano añadida por git commit -s. Certifica el certificado de origen del desarrollador, lo que significa que usted tiene derecho a enviar este código bajo la licencia del proyecto. Un commit firmado, realizado con git commit -S, es una firma criptográfica sobre el objeto del commit con su clave GPG o SSH. Demuestra que el commit proviene de su clave y no fue alterado. El origen y la identidad son declaraciones separadas, por lo que un commit firmado aún puede infringir una política de IA.

¿Puedo poner la divulgación en la descripción de la pull request en lugar de en el mensaje del commit?

Póngala en el mensaje del commit, ya que es el registro que termina en el historial de git y viaja con el código a cualquiera que clone el repositorio más tarde. La descripción de una pull request puede editarse después y reside en la plataforma de alojamiento. Añádala también al cuerpo de la PR cuando el proyecto realice un squash merge, ya que un squash reescribe su mensaje de commit y puede eliminar el trailer.

Mi pull request fue cerrada porque estaba generada por IA. ¿Qué hago ahora?

No discuta la política en el hilo, ya que la persona que la cerró no escribió la regla por sí sola y el hilo no es el lugar donde esta cambia. Lea el texto de la política y decida si puede cumplirla. Cuando el proyecto prohíbe los parches generados, un informe de error claro con un reproductor y sin parche sigue siendo bienvenido, y a menudo es la contribución más útil. Si vuelve con código, hágalo con un cambio pequeño que pueda defender línea por línea.