Sin código de LLM en las dependencias

Detección de código generado por LLM

• Algunas personas quieren herramientas que marquen commits generados por LLM mediante heurísticas: grandes blobs con comentarios extensos, líneas de código por hora inusuales y estilos de commit entrenados en repos anteriores a la era de los LLM.
• Otras sostienen que la “detección de IA” es intrínsecamente poco fiable, la comparan con los polígrafo y advierten sobre altos falsos positivos.
• Una postura más suave: la detección no necesita ser perfecta, solo lo bastante buena como para sacar a la luz casos “obvios” para revisión humana.
• Se proponen heurísticas simples, como comprobar las etiquetas de coautor del commit, como soluciones fáciles de aprovechar.

Viabilidad de dependencias sin LLM

• Una parte ve rechazar dependencias contaminadas por LLM como una postura principista pero potencialmente poco práctica, especialmente cuando bloquea versiones más nuevas de herramientas y lenguajes críticos.
• Otras personas lo consideran una defensa razonable contra la “basura de IA”, aunque implique más trabajo, congelar dependencias o usar menos dependencias.
• Se reconoce que esto podría volverse insostenible a largo plazo y obligar a hacer concesiones entre pureza y acceso a mejoras en lenguajes y herramientas.

Gobernanza de OSS y políticas de contribución

• Entre las sugerencias están: no aceptar contribuciones externas en absoluto, poner un peaje a los PR para financiar más revisión, o pasar a un alojamiento “libre de IA”.
• Algunos argumentan que el software libre puede simplemente rechazar parches generados por LLM sin dejar de ser abierto; hacer un fork sigue siendo una opción para quienes discrepan.
• Una preocupación recurrente es el agotamiento de los mantenedores por PR de IA de baja calidad y el riesgo de que los proyectos voluntarios “implosionen” bajo la carga de revisión.
• Varios comentarios destacan la diferencia cualitativa entre mentorizar a humanos junior (que pueden convertirse en mantenedores) y revisar salida de LLM, que no aporta beneficio comunitario a largo plazo.

Calidad del código de LLM frente al código humano

• Un sector afirma que los LLM se asemejan a desarrolladores de nivel medio-bajo y pueden ser útiles si se usan de forma responsable; el problema es el uso descuidado, no la herramienta.
• Los críticos dicen que los LLM son peores que los devs típicos, carecen de comprensión y producen desastres sutiles y a gran escala a velocidad sobrehumana.
• Hay temor a un futuro saturado de “slopcode” opaco y con mucha rotación, donde la comprensibilidad y la fiabilidad se degraden.

Seguridad, ética y actitudes corporativas frente a OSS

• Algunos defienden los LLM como esenciales para la auditoría de seguridad a escala futura; otros responden que el análisis y la generación de código son cuestiones distintas.
• Existe tensión entre estar “obligado” a usar LLM por el mercado laboral y la creencia de que, aun así, esa situación es mala.
• Varios comentarios destacan preguntas no resueltas sobre copyright y licencias en torno a los datos de entrenamiento y la reutilización de código.
• Se contrasta el idealismo y el escrutinio público de los proyectos de código abierto con las corporaciones que usan LLM internamente en silencio y con menos preocupación por la procedencia.