Los desarrolladores del proyecto LLVM han aprobado reglas para la aplicación de herramientas de IA durante el desarrollo. La necesidad de regular el uso de IA se explica por el aumento en el número de cambios irrelevantes propuestos para incluirse en la base de código de LLVM. Los cambios irrelevantes se refieren a aquellos generados por herramientas de IA y enviados tal cual, sin comprender el contenido, verificarlo y asumiendo que 'el mantenedor se encargará'. Esta actividad crea una carga adicional para los mantenedores y los obliga a perder tiempo en el análisis de código inútil.
Sin embargo, los desarrolladores de LLVM reconocen que, si se utiliza correctamente, la IA es una herramienta útil que acelera el desarrollo. Las condiciones aprobadas en LLVM para la aplicación de IA se basan parcialmente en las reglas publicadas el año pasado por el proyecto Fedora. La idea principal de las reglas adoptadas es que los desarrolladores no deben trasladar a los mantenedores la responsabilidad de revisar el código generado por asistentes de IA.
Además de la responsabilidad mencionada en las reglas de Fedora, en las reglas de LLVM se ha introducido el requisito de una revisión manual obligatoria del código generado por IA antes de proponer un cambio en el proyecto. Además, quien prepare el cambio debe entender bien el código enviado y estar preparado para responder preguntas relacionadas. Se recomienda redactar manualmente las descripciones para las solicitudes de extracción en lugar de confiar en la preparación del texto de apoyo por parte de la IA.
Al enviar un cambio, una parte significativa del cual ha sido generado por herramientas de IA, es necesario añadir información sobre el uso de IA en la nota de la solicitud de extracción, por ejemplo, indicando la etiqueta 'Asistido por: nombre del asistente de IA'. Está prohibido el uso de herramientas de IA automatizadas, como el agente de IA integrado con GitHub @claude, que realicen acciones o envíen comentarios sin la intervención humana.
Las reglas adoptadas se aplican no solo al código en las solicitudes de cambio, sino también a documentos RFC con propuestas de nuevas funcionalidades, informes de vulnerabilidades y errores, comentarios y reseñas a las solicitudes de extracción.
Además, se puede mencionar la decisión de Daniel Stenberg, el autor de la herramienta para obtener y enviar datos a través de la red curl, de finalizar el programa de recompensas por información sobre vulnerabilidades en Curl. El pago de recompensas se detendrá a finales de enero debido a la cantidad de solicitudes basura generadas por asistentes de IA y enviadas sin verificar la existencia real de la vulnerabilidad.
Se informa que en las primeras dos semanas de enero se han presentado 20 solicitudes de recompensa, alegando la existencia de vulnerabilidades. El análisis de estas solicitudes mostró que ninguna de ellas contenía vulnerabilidades reales. Se recomienda a los autores de informes de vulnerabilidad que no informen sobre el problema si no comprenden su esencia y no pueden reproducir el error. La revisión de solicitudes como esta consume mucho tiempo del equipo responsable de la seguridad. Se supone que la eliminación de las recompensas disminuya la motivación de las personas para enviar informes basura y mal verificados sobre vulnerabilidades, ya sean generados por IA o no.
Adición: El proyecto Node.js también ha anunciado la limitación de la aceptación de solicitudes de recompensa por la identificación de vulnerabilidades, y ahora solo aceptará en HackerOne solicitudes de participantes con alta calificación que ya tengan experiencia en enviar informes correctos sobre problemas (signal > 1). La razón del cambio se debe a un aumento significativo en el número de solicitudes de baja calidad. El análisis de solicitudes basura consume tiempo y recursos que podrían destinarse a un trabajo real de mejora de la seguridad de la plataforma. Desde el 15 de diciembre hasta el 15 de enero, el proyecto recibió más de 30 de tales solicitudes.
Fuente: opennet.ru
