Pop!_OS prohíbe el código generado por IA en gran parte de su base de código

Completamente performativo.

Construyes tu sistema operativo sobre miles de paquetes de código abierto, muchos de los cuales contienen código generado por IA. ¿Vas a auditarlos uno por uno y eliminar los paquetes infractores? ¿Y qué pasa con los que no eliminarás porque el sistema operativo quedaría irreparablemente roto?

Tenía un PR en curso que se cerró por esto. Tenía un problema con las contraseñas en el applet de red para la VPN y había usado Claude para ayudarme a identificarlo y luego idear una solución. Dediqué mucho tiempo a crearlo a mano y a asegurarme de que la calidad fuera buena, pero respeto su decisión y no guardo rencor, pero como alguien que ha tenido dificultades para encontrar tiempo y oportunidad para contribuir al código abierto, fue un pequeño contratiempo.

hay un hilo en curso aquí sobre un tema similar de un experto de AWS (ex CTO de AWS)

"Aparentemente, la IA no conduce a resultados positivos en todos los equipos de desarrollo de software. Los clientes me preguntan si deberían frenar la adopción de la IA en sus equipos.

¿Cómo respondes a eso?

¿Sí? ¿No?"

https://www.linkedin.com/feed/update/urn:li:activity:7510679...

Parece que parte de ello es un hábito de aprendizaje, volverse competente en el uso de las herramientas (agentes de IA) en sí mismas, y un mejor flujo de trabajo en torno a ello, pero ¿sigue siendo la IA imperfecta todavía?

No veo cómo esto va a sobrevivir a la brecha atacante/defensor a medida que ls se vuelven cada vez mejores en ciberseguridad y en encontrar 0 days... pero quizás es lo suficientemente oscuro como para que no importe?

Me pregunto si el problema es principalmente el código o los PRs escritos por IA y la gente que usa IA para hablar con los mantenedores. Personalmente, simplemente prohíbo a cualquiera que haga lo segundo, no quiero hablar con opus más de lo que ya lo hago jaja

Ok, esto puede ser controvertido, pero los tokens de código de los LLM no son gratis, y me quedo sin mi asignación semanal con bastante regularidad solo por hacer algunos proyectos bastante intensos, así que no entiendo por qué alguien querría gastar su propio dinero para hacer malos PRs a propósito, y me gusta asumir buenas intenciones de la gente a menos que se demuestre lo contrario, lo que significa que una prohibición casi total del código escrito por LLM para estos grandes proyectos de código abierto me parecía un poco extrema, cuando el problema central parecía ser que el proceso/política de revisión debería cambiar con los tiempos.

Por ejemplo, a principios de este año estaba ayudando a trabajar en un motor de juego de código abierto con un bug de renderizado de texto de larga data que se remonta a alrededor de 2021 que impide que el motor esté listo para producción, para el cual la comunidad y yo hemos desarrollado extensas soluciones alternativas. Así que, un día finalmente dije basta y conseguí que Claude lo depurara. Claude tardó 10 minutos en encontrar el bug, era un cambio de 3 líneas de código en el renderizador (sí, tres).

Así que escribí las pruebas de regresión, documenté el bug y abrí un PR para la solución, pensando que se fusionaría en menos de una semana y luego todos podríamos seguir adelante. Los mantenedores lo recibieron bastante bien en el PR, pero el PR estuvo ahí parado durante casi 6 meses, sin fusionar, hasta que finalmente se cerró por un mal squash upstream. Estoy bastante seguro de que el bug sigue ahí también.

Y como nota al margen, estaría encantado si alguien quiere contribuir a mis proyectos de Github con su IA.

"... muchas de las contribuciones de IA no fueron planificadas y mostraban poco entendimiento de la arquitectura del software. Así que el equipo quiere "priorizar el trabajo en contribuciones de nuestro propio equipo y colaboradores habituales"."

Suena razonable, incluso para usuarios ávidos de LLM, supongo. Tienes que trazar una línea. Esta línea es demasiado simplista, pero funcionará, por ahora.