Divulgación obligatoria al contribuir usando herramientas de AI

• En la discusión de un PR del proyecto open source Ghostty, se planteó que se debe divulgar explícitamente si se usaron herramientas de AI
• El autor de la propuesta señaló que la AI todavía genera con frecuencia código de baja calidad, y que el problema es mayor sobre todo cuando usuarios inexpertos envían aportes sin revisarlos
• El objetivo de la divulgación es que las personas mantenedoras puedan evaluar la confiabilidad del PR y, al mismo tiempo, dar retroalimentación educativa a contribuyentes humanos mientras se reduce el esfuerzo innecesario en simples contenidos generados por AI
• Otra persona participante propuso agregar una lista de verificación, incluyendo el uso de AI, mediante una plantilla de PR
• Por otro lado, también se planteó la idea de que las herramientas de AI automaticen una byline especial estandarizada para que quede registrada en los mensajes de commit de GitHub, garantizando al mismo tiempo transparencia y visibilidad de la herramienta

---

Necesidad de divulgar el uso de AI

• Mitchellh dijo que le gustan las herramientas de AI y que él mismo las usa, pero evaluó que por ahora no garantizan una calidad igual o mejor
  • En particular, cuando principiantes con poca capacidad de revisión suben código generado por AI directamente en un PR, la calidad es muy baja
  • Criticó que, en ese contexto, hacer que las personas mantenedoras gasten tiempo en revisiones y retroalimentación innecesarias es “una forma de engaño”
• Por eso, si se divulga explícitamente el uso de AI, quienes mantienen el proyecto pueden determinar con cuánta atención deben revisar

Propuesta de introducir una plantilla de PR

• Yawaramin propuso aprovechar la función de plantilla de PR de GitHub para incluir si se usó AI
  • Al mismo tiempo, también se podrían incluir listas de verificación como Developer Certificate of Origin (DCO)
• Con esto, todas las personas contribuyentes podrían informar de manera consistente el uso de AI

Idea de estandarización en GitHub

• Tobi propuso que GitHub cree un estándar de byline exclusivo para AI
  • Cada vez que se use una herramienta de AI, quedaría registrado en el archivo de staging de .git y se añadiría automáticamente al mensaje de commit
  • GitHub podría listar esa información y ofrecer enlaces a la herramienta → las personas mantenedoras podrían verificar el origen
  • Al mismo tiempo, las herramientas de AI ya no tendrían que abusar del uso de co-authors como si fuera spam
• Se evalúa este enfoque como una forma de cubrir transparencia, promoción de herramientas y eficiencia de mantenimiento

[GN⁺]

Opiniones de Hacker News

• Se señala que incluso al usar "IA" surge el problema de contaminación de propiedad intelectual, y estamos ignorando ese hecho; si alguien pudiera memorizar todo el código de proyectos open source y escribirlo tal cual cada vez que se necesitara, en nuestra empresa obviamente tendríamos que prohibirlo. Pero en el caso de la IA se niega ese hecho con toda clase de racionalizaciones y excusas. En la práctica, está "lavando" de forma laxa distintos tipos de código, incluido GPL, y eso implica un riesgo fatal para empresas basadas en propiedad intelectual (IP).
  • Los tribunales de EE. UU. ya han dictaminado que el uso de datos de entrenamiento es un uso transformativo (transformation); todavía hay muchos detalles por ajustar, pero al final es un cambio irreversible. Si queremos que la creación de IP siga siendo una actividad económicamente sostenible, también hay que cambiar el marco legal relacionado.
  • Siguiendo esa lógica, también habría que prohibir StackOverflow o casi todos los libros de texto de cualquier área; en la práctica, los programadores inevitablemente terminan viendo código de otras personas.
  • En realidad, creo que salvo quienes tienen intereses económicos directos, casi nadie se toma en serio los temas legales relacionados con IA. Por suerte, en la mayoría de los casos este tema se está ignorando, y el sistema legal está funcionando bien sin bloquear el progreso.
• Me impresionó mucho la parte de mitchellh sobre "acompañar a los nuevos contribuidores hasta el final y ayudar a que su PR sea mergeado". Dar feedback para que un desarrollador principiante crezca es algo realmente valioso. Pero si quien envía el PR simplemente le pasa ese feedback a una IA de inmediato y no aprende nada por sí mismo, entonces es una pérdida de tiempo.
  • A partir de ahora, los desarrolladores junior ya no tendrán un entorno de trabajo sin IA.
• Me da mucho gusto que la portada de HN de hoy esté llena de buen contenido basado en experiencias reales. Hay muchas historias sinceras, sin miedo inútil ni exageraciones. En mi computadora personal tengo desactivada la asistencia de IA, y en el trabajo solo la uso de forma muy limitada cuando realmente hace falta. La asistencia de IA tiene una gran fortaleza en trabajos pequeños (atomic work), pero es pésima para trabajos compuestos (compound work). En conclusión, la IA depende de cómo la use el ser humano; la inteligencia humana sigue siendo lo central.
  • Cada vez estoy más de acuerdo con la frase "la IA es tan inteligente como quien la maneja". Antes no entendía cómo podía haber resultados tan distintos usando la misma IA, pero ahora siento de verdad que la IA no es magia. Pensándolo bien, fui ingenuo al esperar que personas que ni siquiera podían explicarse entre ellas fueran capaces de extraer valor de la IA. Más bien, parece que la IA solo va a ampliar la brecha entre un ingeniero promedio y uno sobresaliente. Todavía tengo sentimientos encontrados, pero ya entiendo por qué para algunas personas la IA puede parecer inútil.
  • Cita la conclusión de “No Silver Bullets, Refired” de Frederik P. Brooks: el desarrollo de software es intrínsecamente complejo, y en lugar de esperar una solución revolucionaria, debemos buscar mejoras graduales de productividad. Esa perspectiva se siente realista y esperanzadora.
  • Me parece interesante la frase "la IA es tan inteligente como quien la maneja". Al final, quienes publican cosas como "hice una librería genial en un día con IA" ya eran desarrolladores muy capaces desde el principio.
  • Yo también coincido. En la empresa estamos en una semana de hacking y probando herramientas de IA a nivel general, y los buenos resultados suelen venir de enfoques analíticos, guardrails, grounded generation y cosas así en aplicaciones reales. Últimamente siento que ya pasó la moda inútil de los chatbots y que el paradigma se está reseteando hacia la esencia del machine learning.
  • Pienso que el ser humano toma las decisiones clave y luego la IA conecta el resto. Qué cuenta como decisión clave y qué cuenta como simple trabajo de conectar puntos cambia según el dominio, pero en la práctica la mayor parte del código (aprox. 80~90%) es trabajo repetitivo/de conexión. Si se respeta bien esa frontera, el aumento de productividad es enorme. En cambio, si le dejas a la IA las decisiones clave, la pérdida es todavía mayor; hasta conviene tirar todo y empezar de nuevo. Ejemplos de decisiones clave: diseño de base de datos, definición de tipos, dependencias, diseño de sistema/infraestructura/pantallas, selección de casos de prueba, estructura de organización del código, etc. En cambio, lo que la IA sí puede hacer bien son CRUD, API handlers, transformaciones simples de estructuras de datos, scripts de despliegue, implementación de tests, código de componentes de UI, styling, limpieza de datos temporales, etc. También ayuda en research, exploración de ideas y búsqueda de alternativas, pero la conclusión y la implementación real deben quedar en manos humanas.
• No soy alguien especialmente fanático de la IA; simplemente la veo como una herramienta más. No me importa cómo haya preparado alguien un PR mientras el resultado sea bueno. Eso sí, si el maintainer pide algo antes de enviar el PR, creo que por cortesía corresponde ajustarse a eso.
  • Sí importa de dónde salió un PR y cómo se produjo; los reviewers también se equivocan y tienen límites, así que la confianza se vuelve importante. Si no hay confianza, ni siquiera debería aceptarse en el proceso de revisión. Esa es la misma razón por la que el equipo del kernel de Linux bloqueó a la Universidad de Minnesota por sus experimentos.
  • Parece que no respondiste de verdad al argumento central del texto: "el objetivo es ayudar a que un contribuidor nuevo pueda crecer, pero si el otro lado es una IA, solo se está perdiendo el tiempo".
  • Con IA se pueden crear 1,000 PR al día. Parece que solo estás pensando en los PR bien hechos con IA, pero en la realidad también se puede usar IA para hacerle la vida muy difícil a los maintainers de un proyecto.
  • Según la Oficina de Copyright de EE. UU., los resultados generados por IA no están protegidos por copyright. Por eso, incluso con fines de licenciamiento, es necesario revelar que se usó IA. Si se incumple, se podría perder el copyright de toda la obra. Para más detalles, ver el reporte y la página principal.
  • Si usé IA y me preguntan, siempre lo voy a revelar. Pero si no me preguntan específicamente, no lo diría "por cortesía previa". Creo que para la mayoría de la gente el uso de IA ya se da por hecho o simplemente no le importa, y más bien lo siento como una marca menor que distrae la atención; como cuando llega una notificación de dependabot y en realidad no genera interés.
• Han salido varias veces preguntas como "¿y qué pasa con mi autocompletado?", pero en el documento de política hay una excepción explícita: si se trata de keywords o frases cortas, como un simple tab autocomplete, no hace falta revelarlo. Recomiendo leer bien el documento (o el PR).
• Esta política sí me parece convincente porque agrega contexto adicional. Muchas políticas sobre IA que vi antes se parecían más a declaraciones ideológicas, pero aquí explican por qué lo piden y hacia dónde quieren ir, así que se siente mucho más realista. Ojalá hubiera más políticas así.
• Me preocupa si esta política no terminará haciendo que a la gente honesta le cueste más usar IA. La pregunta es si, al final, como decir que usaste IA hará que el PR reciba menos atención, no va a hacer que todos intenten ocultarlo.
  • No creo que sea tan simple. Incluso la persona que publicó la política (mitchellh) usa LLM, así que si puedes explicar que usaste IA como herramienta de conveniencia mientras entendías bien el trabajo que estabas haciendo, probablemente no perderás mucha confianza.
  • Esa preocupación podría hacerse realidad. Como la IA produce en masa código que "parece más o menos correcto pero en realidad es un desastre", si se acumula desconfianza hacia el código hecho con IA, ese sería un problema de la IA, no de las personas. Hacen falta mejores herramientas de coding con IA.
  • Si dices "usé chat-gpt", de inmediato quedas enterrado; si no dices nada y actúas como si supieras, te felicitan. Ya todo el mundo se está moviendo en la dirección de ocultar el uso de IA.
  • No creo que tenga mucho sentido ver esto como un problema.
  • La idea no es "no uses IA", sino que si la usaste, lo digas con honestidad en el PR.
• Me pregunto por qué también piden una revelación detallada del tipo "usé ChatGPT para ayudarme a entender el codebase, pero el código lo escribí yo".
  • Si dejas esa explicación, desde la perspectiva del reviewer se puede poner atención a posibles malentendidos o errores en la parte de "entender el codebase".
  • Yo no soy desarrollador, pero gracias a estos asistentes de IA el tiempo que me toma explorar código se redujo muchísimo; en lo personal, la IA sí me ha ayudado bastante.
• Me parece bueno el patrón de incluir cada prompt usado para generar el PR. Un LLM no es una herramienta completamente determinista, pero tiene valor dejar el contexto de por qué etapas/prompts se llegó al resultado.
  • En la práctica es muy poco práctico. Incluso para crear un solo PR con IA se mezclan 10~20 prompts, pruebas, ajustes manuales de contexto, código escrito a mano y otros pasos. Casi sería mejor una grabación de pantalla.
  • Yo uso una combinación del plugin de vscode (specsytory) y cursor para dejar en md un registro de todas las interacciones con el LLM y lo adjunto junto con el Pull Request para referencia durante el code review.
• En mi proyecto personal puse una regla para revelar incluso si se usó el autocompletado del editor.
  • La forma de comunicar la intención es interesante, pero hoy la IA es completamente distinta del autocompletado tradicional. Se puede usar como autocompletado, sí, pero lo que puede hacer la IA es mucho más variado y profundo. Pensar la IA solo como un simple autocompletado es una perspectiva personal; mucha gente no la usa así.
  • El tab autocomplete está claramente reconocido como excepción en la política.
  • El autocompletado suele ser solo una herramienta sintáctica, pero la IA intenta guiar incluso el significado y la estructura del código.