Un número creciente de proyectos de código abierto está prohibiendo explícitamente las contribuciones generadas por inteligencia artificial para proteger la integridad y la mantenibilidad de sus bases de código. Este cambio está impulsado por una oleada de entregas 'vibe-coded': código que parece funcional y estéticamente correcto, pero que carece de las pruebas rigurosas, las auditorías de seguridad y la profunda comprensión arquitectónica requeridas para el software de producción.
El auge del 'vibe-coded' de baja calidad
El proyecto 'osssaysno.com' destaca una tendencia en la que los mantenedores rechazan contribuciones que parecen haber sido generadas por modelos de lenguaje grandes (LLMs). Un comentarista, escribiendo como koalalorenzo, describió estos como proyectos 'vibe-coded' donde el enfoque está en la 'apariencia' y las 'sensaciones', mientras que los problemas de seguridad permanecen sin abordar porque 'un LLM siempre tiene razón'.
Otra perspectiva sugiere que el problema no es la IA en sí, sino la falta de responsabilidad humana. Los comentaristas en Hacker News argumentaron que el verdadero problema surge cuando los contribuyentes no asumen la responsabilidad de leer, probar y comprender el código que envían, independientemente de si lo escribió un humano o una IA.
Protegiendo la salud mental de los mantenedores
Los mantenedores se enfrentan a un aumento significativo en el volumen de interacciones de la comunidad, incluidos problemas y solicitudes de extracción, lo que pone en riesgo el agotamiento de quienes gestionan los proyectos. Un comentarista, Arbortheus, señaló que la dificultad reside en distinguir entre un contribuyente que comprende el dominio del problema y uno con 'valentía holandesa inducida por LLM'.
Al prohibir las contribuciones generadas por IA, los mantenedores pretenden crear un umbral más alto para 'aportar valor'. Un comentarista, Systemerror7A69, argumentó que en el pasado, una solución funcional era evidencia del proceso de pensamiento de un contribuyente; con los LLM, ese pensamiento a menudo se externaliza, lo que dificulta a los mantenedores identificar aportaciones de alta calidad.
Compensaciones y desafíos de aplicación
La decisión de prohibir la IA no está exenta de controversia. Algunos comentaristas argumentaron que estas prohibiciones son 'perezosas' y podrían alejar a posibles contribuyentes, especialmente en proyectos impulsados por la comunidad que carecen de financiación. Sugirieron que el enfoque debería centrarse en la calidad de la contribución en lugar de la herramienta utilizada para crearla.
También existe una preocupación práctica con respecto a la aplicación de estas reglas. Un comentarista, ChrisRR, sugirió que prohibir el código de IA podría llevar a los contribuyentes a mentir sobre su uso. Propuso un punto medio donde la IA puede ser utilizada, pero el contribuyente humano debe asumir la responsabilidad total del resultado final.
Además, algunos argumentan que evitar la IA para la búsqueda de errores podría hacer que el software sea más vulnerable. Un comentarista, jonathanstrange, advirtió que, dado que los atacantes utilizarán IA para encontrar exploits, el código exclusivamente humano podría considerarse eventualmente menos seguro.
Matices en la integración de la IA
No todos los proyectos están adoptando una prohibición general. Algunos mantenedores distinguen entre contribuciones de IA 'externas' —donde un bot o un no experto envía código— y la 'programación agéntica guiada por humanos'. Un comentarista, jdzikowski, señaló que los proyectos pueden confiar más en el código de IA si es aprobado por alguien que comprende profundamente la arquitectura del proyecto.
La discusión también reveló que algunos proyectos están encontrando caminos intermedios. Por ejemplo, un comentarista señaló que, si bien un proyecto podría no aceptar solicitudes de extracción generadas por LLM, aún podría utilizar agentes de IA internamente para commits coautorizados o tareas específicas.