Exigir que los temas y complementos generados por LLM estén etiquetados como tales

Actualmente, algunas personas pueden intentar subir plugins, temas o componentes generados íntegramente por LLMs sin revelarlo. Hay muchas razones por las que puede ser beneficioso saber cuándo algo ha sido generado completamente por un LLM, y en este momento no existe ninguna obligación de declarar dichos plugins como tales. Personalmente, me gustaría saberlo de antemano para no terminar instalando un plugin de baja calidad con todos los problemas de rendimiento, optimización y experiencia de usuario que suelen tener los plugins generados por LLMs.

Obviamente, esto depende de que las personas sean honestas y transparentes (y las personas que tienen temas generados por IA quizás no sepan mejor que lo que indica la herramienta), pero contar con una etiqueta como #generado-por-ia que se aplique a los activos generados principalmente por IA sería beneficioso para todos.

2 Me gusta

No estoy de acuerdo con la idea de que un plugin generado por un LLM sea inherentemente de baja calidad o que necesariamente sufra de problemas de rendimiento, optimización o UX. La calidad del resultado depende en gran medida de la persona que guía al LLM y revisa su salida.

He sentido orgullo por el software que he desarrollado durante los últimos 40 años, y la incorporación de LLMs en mi flujo de trabajo ha mejorado la calidad de mi trabajo, no la ha disminuido.

Por el contrario, he visto numerosos plugins escritos a mano plagados de vulnerabilidades de seguridad, problemas de rendimiento y malas decisiones de diseño, donde sinceramente deseaba que el autor hubiera utilizado un LLM. Al final, lo que importa es la calidad del desarrollador y el código resultante, no si un LLM estuvo involucrado en su escritura.

11 Me gusta

Me pregunto cómo sugieren revisar y/o actualizar el código generado por LLMs, para aquellos de nosotros que estamos incursionando en el “vibe-coding” para implementar nuevas funcionalidades o personalizar las que realmente se están entregando.

Sé que una revisión colectiva en repositorios públicos es lo ideal, pero me gustaría primero hacer mi tarea y solo publicar versiones que hayan agotado mi capacidad actual.

Estoy de acuerdo con el comentario anterior; no soy anti-IA, pero al mismo tiempo soy consciente de que TODO lo que generan debe ser auditado, verificado y actualizado por humanos.

Algo curioso, relacionado:

1 me gusta

Esto es totalmente justo y, al final del día, solo me permite hablar por mí mismo, basándome en la observación de aplicaciones de baja calidad “slop” que todas se ven idénticas y son generalmente de baja calidad (tanto en términos de funcionalidad como de seguridad), junto con aplicaciones existentes que han sufrido un descenso severo en la calidad desde que comenzaron a externalizar en gran medida el trabajo a LLMs (como Visual Studio Code y Formbricks; ambas de las cuales he dejado de usar desde entonces). Incluso si tu aplicación es perfecta, todavía existen preocupaciones éticas, por lo que sería genial si hubiera algún tipo de notificación para estas creaciones, como se sugirió. Esto no significa que nadie tenga que basarse en la etiqueta, pero si te gustaría, la opción es agradable.

Como dije, este es inherentemente un sistema basado en la confianza y es responsabilidad exclusiva del desarrollador asegurarse de que esté etiquetado como tal. Obviamente, hay algunos casos en los que el LLM se etiqueta a sí mismo en los registros de git (como la mayoría lo hacen), por lo que un TL3+ puede tomar medidas si lo desea, consultando GitHub.

Agradezco tu respuesta, gracias. Mi consulta también va dirigida a todos y se refiere a las herramientas que actualmente existen para verificar el código generado por LLMs.

No soy desarrollador, pero logré implementar funcionalidades que no existían en Discourse. Y quiero hacer lo que esté a mi alcance de la mejor manera posible.

Consideraré etiquetar si termino publicando mis repositorios; por ahora, son privados precisamente porque los estoy probando, y me interesa hacerlo bien antes de distribuirlos a la comunidad.

Me sorprendería muchísimo si la mayor parte del código de Core (incluidos los plugins de Core) no se estuviera construyendo ahora mismo con agentes de programación, dado el alcance de los cambios en el desarrollo.

En mi opinión, ahora resulta muy difícil justificar no usar agentes de programación para la mayoría de las tareas, ya que la caída en la eficiencia simplemente no tendría sentido desde el punto de vista empresarial.

3 Me gusta

No me preocupa en absoluto “cómo se formó un plugin” ni si el artesano usó un lápiz o un bolígrafo.

“Aquí no hay IA” no es algo que me dé ni un ápice más de confianza a la hora de instalar un tema o un plugin.

Sin embargo… hay un problema mucho más serio que debemos abordar en CDCK.

Los plugins principales y el código fuente de Discourse se analizan en busca de vulnerabilidades de seguridad de forma regular; cuando una persona instala un canal compatible, tiene confianza en cuanto a lo seguro que es el código.

Los plugins y temas de terceros de aquí son “el salvaje oeste”: cualquiera puede contribuir, no los analizamos en busca de vulnerabilidades de seguridad ni nos aseguramos de que sigan las mejores prácticas. Esto pone en riesgo a la comunidad.

Me gustaría alcanzar un mundo en el que “la versión XYZ” de un tema al menos se escaneara automáticamente para dar a los autoalojadores al menos cierta confianza.

Así que mi visión aquí es exactamente lo opuesto :slight_smile: exigir que las versiones de temas y plugins de terceros pasen algún tipo de escaneo por IA antes de ser anunciados aquí.

8 Me gusta

La revisión de código por parte de un LLM es totalmente diferente a pedirle a Claude que construya una aplicación sin cometer errores y publicar la salida con poca o ninguna validación o edición por parte del usuario, al menos en lo que a principios éticos se refiere. Lamentablemente, no se puede obligar a un usuario final a asumir la responsabilidad, y por muy duro que se intente, alguien encontrará la manera de descargar algo malicioso. Pero, de todos modos, qué tan éticos son los LLM es una conversación aparte y no es realmente relevante para este hilo.

¡y eso está bien! No estoy sugiriendo una prohibición generalizada de nada que involucre IA en Customization… Solo me gustaría que se etiquetara correctamente para que quienes no quieren abrir esa lata de gusanos no terminen haciéndolo.

Tengo muchos problemas con las herramientas basadas en LLM (y con sus resultados). No solo con los problemas de seguridad, legales, de fiabilidad y medioambientales, pero eso no es el problema principal aquí.

La seguridad, en su definición amplia, es el problema importante aquí. Si el código ha sido generado por IA o no.

¿Qué herramientas utiliza CDCK para las comprobaciones de seguridad? Varias de ellas también serían importantes para las creaciones de terceros.

Pero hay más cosas que comprobar. Con qué sistemas externos se comunica la creación de terceros. La mayoría de las herramientas de análisis de seguridad aceptarán que el software se comunica con servidores externos, sin un heartbeat. Pero un componente de tema puramente cosmético no debería realizar ninguna llamada a un servidor externo. Así que la creación de terceros puede contener agujeros de seguridad, o contener problemas que pueden dañar la disponibilidad. Pero también podrían exfiltrar datos.

Estoy de acuerdo en un 95 % con eso. Y ahora estamos hablando de Discourse; ¡imagina si estuviéramos en el mundo de WordPress!

(El 5 % que falta: no creo que sea «el viejo oeste»; los problemas de seguridad se reportan a través de meta a esos desarrolladores de terceros y, en general, se corrigen bastante rápido).

Pero, al mismo tiempo, mi experiencia es que los LLM (hoy en día) generan código más seguro que el autor promedio de plugins. Y puedes pasarle un plugin a cualquier LLM decente y pedirle «encuentra y corrige cualquier problema de seguridad», y lo hará, incluso si la persona no tiene mucho conocimiento en seguridad.

He estado revisando manualmente plugins durante la última década y he visto mucho: inyecciones de SQL (por personas que pensaban que ActiveRecord era demasiado sofisticado), configuraciones de claves de API con client: true, falta total de autorización y controles de acceso, y falta de limitación de tasa de solicitudes. Todos ellos son encontrados y corregidos por los LLM en poco tiempo y sin demasiado esfuerzo.

Así que, de nuevo: creo que los LLM han hecho esto mejor, no peor.

Sigues asociando el código generado por LLM con una «caja de pandora»; eso es demasiado blanco y negro.

4 Me gusta

Jack McDade ha adoptado ese enfoque con el directorio de complementos de Statamic

Doy la bienvenida a este enfoque; lo encontré útil para confirmar lo que ya sabíamos que debía hacerse. También ayuda a generar confianza en el código.

Parece que algo similar podría implementarse aquí sin demasiado esfuerzo por parte del equipo.

4 Me gusta

También me preocupan los plugins y componentes de baja calidad, y no confío mucho en ellos cuando están codificados al 99% por intuición (vibe coding) por alguien que no sabe nada de programación.

Pero también creo en lo que dicen por ahí programadores experimentados: los malos programadores existían mucho antes de la IA[1]. El código descuidado, poco fiable y defectuoso se ha escrito a mano desde hace siglos.

Lo que me preocupa es cuando veo una app/plugin/lo que sea codificada por intuición y sospecho que el autor no revisó el código.

Aunque tengo conocimientos básicos de programación, no he programado en mucho tiempo y nunca fui bueno en ello. Intenté hacer vibe coding para algunos proyectos.

Inicialmente, me resistía mucho a publicarlos oficialmente en meta, pero finalmente lo hice después de tomarme el tiempo para revisar y entender qué hacía cada parte del código y también de declarar públicamente mi enfoque en mis temas. No es que me acuerde de todo lo que leí antes de publicar esos plugins, pero al menos podía garantizar la fiabilidad y la seguridad en el momento en que publiqué ese trabajo.

Tengo un buen ejemplo para ilustrar cómo el vibe coding podría haberme llevado a lanzar un plugin muy inseguro.

Antes de trabajar en 🖼️ Topic Gallery, hice una prueba de concepto de un plugin similar aquí: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
Funcionaba genial y la IA seguía mis directrices.

Pero había un problema: aunque la función era claramente una función de moderación, la IA no tuvo en cuenta los permisos: cualquier usuario, incluidos los visitantes, podía abrir esa página y ver todos los archivos subidos por todos los usuarios. Para mí estaba claro que debería ser solo para administradores, pero la IA no “pensó” en eso. Y como no se lo pedí, creó una página pública por defecto.

Así que sigo diciéndome a mí mismo que si yo y la IA pudimos pasar por alto una fuga de seguridad tan obvia, es posible que los no programadores que hacen vibe coding de TCs y plugins hagan lo mismo, lamentablemente.

Las opiniones sobre el código generado por IA en el software están fuertemente polarizadas. Solo tienes que echar un vistazo a cualquier proyecto de código abierto popular donde Claude sea citado como coautor de los últimos commits para ver una avalancha de odio por parte de ciertas personas.
Estoy convencido de que deberíamos abordar estas cosas con cautela y que nuestras opiniones deberían ser más matizadas.

No estoy particularmente a favor de tener algún tipo de etiqueta vibe-coded que pueda dañar innecesariamente la popularidad de las personalizaciones bien codificadas y seguras y de sus autores.

Sé que ahora cualquiera puede producir personalizaciones, que pueden llegar cada vez más cada día y que no hay suficientes personas para revisarlas.

La revisión por IA es quizás la solución. Mi instinto no me gusta mucho esta idea por varias razones, pero creo que si Sam propone este tipo de solución, probablemente sea buena, porque confío mucho en sus habilidades y juicio. Especialmente ya que yo mismo no sé nada. :laughing:

Quizás algunos devs aquí que sepan de programación y del ecosistema de Discourse podrían tener un título que muestre explícitamente su experiencia en este campo, para que pudieran ser vistos como devs de confianza incluso por visitantes que solo están buscando personalizaciones aquí sin registrarse. Sería lo opuesto a lo que pides, darkpxlz. En lugar de “humillar” personalizaciones potencialmente poco fiables, destacaríamos las fiables. :slight_smile:

Solo es algo para pensar, aunque. :person_shrugging:


  1. Debería saberlo, ¡yo era uno de ellos! ↩︎

5 Me gusta

Es totalmente posible que esté atrapado en una cámara de eco anti-IA debido a los medios de comunicación que consumo y a las personas con las que interactúo a diario. Estaba casi seguro de que esta solicitud no sería tan impopular como ha sido, pero si todos aquí realmente aman codificar con LLMs y no quieren una etiqueta puramente por transparencia, ¿quién soy yo para impedirlo? Detectar el código generado por LLMs sigue siendo bastante fácil, así que si alguien (como yo) realmente quiere evitarlo, puede simplemente revisar a los contribuidores para ver si un LLM se etiqueta a sí mismo, tal como sugerí anteriormente.

1 me gusta

Dado que es un tema controvertido, personalmente apoyo tu solicitud original, que serviría a esa parte de la comunidad que, por el momento, se inclina más por la escepticismo (y es comprensible).

Sin embargo, sospecho que terminaríamos etiquetando casi todo, lo cual acaba desvirtuando el propósito, ¿no?

También coincido con otros en que no todo el código generado por IA es igual: algunas partes están creadas por modelos más recientes y costosos, guiados por desarrolladores experimentados, mientras que en otros casos podría ser un intento único de una persona menos experimentada usando un modelo menos capaz, y el repositorio podría no estar utilizando las mejores prácticas. Y eso solo se puede juzgar examinando el propio repositorio y observando si las personas están teniendo problemas frecuentes.

5 Me gusta

Creo que una revisión exhaustiva por parte de humanos e IA es una buena idea para cualquier software importante, independientemente de si fue escrito originalmente por humanos o por IA. Sería genial si existieran mejores herramientas para revisar software y llevar un registro de quién revisó qué versiones de qué paquetes. Actualmente hay algunas cosas que se parecen a esto para Rust/Cargo: Crev, cargo-vet y Thirdpass. También he iniciado una discusión en los foros de Swift.

1 me gusta

Pertenzo al bando de la etiqueta «why». La discusión entre usar o no usar etiquetas es un poco un desvío del tema principal. Para mí, lo importante es garantizar que la calidad del código y del producto en el directorio de plugins sea la prioridad absoluta. Discourse tiene la responsabilidad última en este ámbito, pero la comunidad puede ayudar. Con ese fin, mi nueva BFF y yo hemos trabajado en la creación de DiscourseSkill.md. Mi intención original era usarlo internamente, pero quizás otros lo encuentren útil. Para ello, echen un vistazo a DiscourseSkill.md