Esto es un salto bastante grande en tu razonamiento.
Si hubieras contratado a un becario o hubieras pasado tú mismo 10 noches, también podrías haber añadido un reproductor FLAC a tu aplicación imaginaria. Tomar malas decisiones de producto no es inherente al uso de los LLM, y si añadir una función inútil es una pérdida de esfuerzo de desarrollo siempre ha sido motivo de debate.
Las funciones adicionales no necesariamente hacen que tu aplicación sea más lenta y más pesada en RAM; ese problema se resolvió con el concepto de carga dinámica hace 40 años.
Si tenemos un problema de seguridad en los temas, hablemos de un sistema para evaluarlos.
Si tenemos un problema de calidad en los temas, hablemos de sistemas para evaluarlos.
Pero no, no voy a introducir una etiqueta de “desarrollado en Mac”, “desarrollado con teclado rojo” o “desarrollado con un 93,2 % de IA” en los temas, eso no va a pasar.
¿Cuánta IA uso? Estoy encantado de compartir mis flujos de trabajo en un tema aparte, pero ya no escribo código a mano en vim.
Sería una falacia genética rechazar todos los complementos generados por IA únicamente por el hecho de haber sido escritos por una IA. Que algo sea generado por IA pudo ser un buen criterio heurístico para identificar contenido de baja calidad, pero a medida que los modelos mejoran, resulta cada vez más difícil distinguir entre la salida de una IA y la de un ser humano. Si la preocupación es la calidad o la seguridad, creo que sería más seguro asumir que todo el código es inseguro hasta que sea revisado mediante algún tipo de sistema de revisión por pares colaborativa.
Creo que a muchas personas les interesaría saber cómo trabaja el equipo con la IA actualmente, desde diseñadores hasta programadores, e incluso en áreas como la legal, el marketing y otros campos.
Conocer un poco sobre las IA, como yo, no significa saber ni comprender cómo una empresa realmente trabaja con la IA a diario.
He leído todo lo que hay aquí y veo ambas caras. Creo que es bueno, pero al mismo tiempo malo, que la gente pueda crear plugins aquí y publicarlos con tanta facilidad, incluso si contienen vulnerabilidades de seguridad “potenciales” que podrían comprometer una instalación de Discourse.
Un poco fuera de tema.
Existe otro proveedor de software de foros (WoltLab) que tiene, por ejemplo, una tienda de plugins. Antes de cada lanzamiento, los plugins y temas son revisados por el equipo. Tal vez sería una buena idea implementar algo similar aquí. Sin embargo, siempre surge la pregunta de quién haría la revisión, y puedo imaginar que esto requeriría una inversión importante de tiempo y personal.
Puedo afirmar con un 100 % de seguridad que revisar cada plugin y tema de terceros no es una idea viable para nosotros. (O al menos, no de forma manual y por un ser humano)
¿Y si tuviéramos un conjunto curado de herramientas para probar los plugins o TC generados por LLM, supervisados, mantenidos y actualizados por el equipo?
Sé que cualquiera puede ejecutar las pruebas de forma individual, pero, sinceramente, no todos saben cómo hacerlo.
Un método simple y confiable para hacerlo me parece lo mejor de ambos mundos.
Ha sido interesante ver las opiniones de todos sobre por qué esta transparencia puede ser importante, tanto en términos morales como de seguridad. Personalmente, me da igual si algo fue creado por un ingeniero de software con 30 años de experiencia que lleva programando en Ruby desde el principio de los tiempos, o por un pequeño Timmy sin ninguna experiencia en código. Si está programado al 100% de forma descuidada[1], no lo usaré; sería hipócrita de mi parte. Entiendo por qué es popular, pero simplemente no es algo en lo que voy a apoyarme. Si estos modelos se hubieran entrenado de forma ética y no estuvieran causando escasez de componentes junto con una epidemia de medios generados por IA, mi sentimiento hacia estos modelos podría ser menos negativo, pero ese no es el mundo en el que vivimos.
Las preocupaciones de seguridad para los plugins a nivel global también son válidas y no se limitan a “esto fue hecho por IA”. Ese es un problema difícil de resolver y está fuera del alcance de este tema, aunque este tema es simplemente una sugerencia para exigir etiquetas a los activos generados completamente por LLMs.
“vibe-coding” o “desarrollo agéntico” son términos que me niego a usar ↩︎
Sigo sin ver el problema que esto intenta resolver. ¿Alguien podría darme un ejemplo de un plugin creado con “vibe coding” que fuera una chapuza, inseguro o un devorador de rendimiento? Uno que nunca debería haberse anunciado aquí porque era pura basura y una pérdida de tiempo para todos.
Y si de verdad existen ejemplos, ¿son suficientes para que sea un problema?
A mí me suena a que sería tan útil tener algún tipo de lista de verificación autocertificada para los temas: cuánto has probado, si estás preparado para recibir informes sobre calidad y seguridad, si serás receptivo a las opiniones.
O, de hecho, cuál es tu proceso de desarrollo, en no más de tres frases.
El valor de verdad de las respuestas no valdrá mucho, pero la diferencia entre temas que están autocertificados y los que no podrían ser una señal que valga algo para la persona que está pensando en instalar la cosa.
Yo, personalmente, nunca hago «vibe-coding» en ninguna aplicación, proyecto o software que cree. Uso los chats de IA para intercambiar ideas o buscar aclaraciones, pero nunca para el proyecto completo. Es más manual, sin duda, pero al menos sé lo que estoy haciendo y no confío ciegamente en otra entidad.
Pero he visto cómo la programación asistida por IA ha crecido mucho en los últimos meses. Es cierto que al principio el código estaba mal escrito o lleno de vulnerabilidades, pero diría que ha mejorado enormemente desde entonces. Los diseños creados con «vibe-coding» siguen siendo bastante reconocibles (degradados, bordes, emojis, etc.), incluso en algunos plugins que he visto en Meta. Pero lo importante es que el autor lo compartió por sus propios intereses y por los de la comunidad. No para que alguien lo desprecie y lo etiquete como «basura», sino porque ha tenido un éxito genuino con ese plugin y quiere compartirlo con otros foros que buscan obtener la misma funcionalidad.
Entiendo tu punto sobre las preocupaciones éticas de la IA, pero eso parece orientado hacia la IA en general, como las empresas que fragmentan libros, el masivo uso de agua y electricidad, etc. Mencionas:
Pero ¿cómo se correlaciona eso con el uso de plugins o TCs creados con IA? Si no te gusta la IA, está bien, no la uses. Pero el panorama de la programación ha cambiado drásticamente con la introducción de la IA, y por lo tanto, cosas como plugins y TCs también lo harán. ¿Dejarás de usar Discourse por completo ahora, sabiendo que parte del código fue escrito con ayuda de IA? Yo no lo haría, porque sé que todavía hay personas detrás de ello.
Así que, ¿seguirá siendo correcto llamarlo «código basura» y boicotear el uso del término «vibe-coding» (personalmente, no veo problemas con esa última frase)? Quizás no. ¿Es demasiado duro? Sí. Aunque creo que te gustaría despreciarlo, a veces tenemos que adaptarnos. ¿Eso significa que ahora haré TCs generados por IA y los compartiré? Para mí, no. Pero ¿significa que lo veré como una alternativa, que no debe ser evitada ni despreciada? Sí. Y estoy intentando no hacerlo. Así que espero que tú también puedas hacerlo.
Solo comparto un artículo curado relacionado con este tema:
Trail of Bits sostiene que los agentes de IA son más útiles en las auditorías para crear herramientas personalizadas, no solo para encontrar errores. En una auditoría de Miden zkVM, utilizaron Claude y Codex para crear un servidor LSP, un descompilador, un analizador estático y un modelo en Lean, lo que permitió descubrir un error de forja de firmas de alta severidad y 95 pruebas en Lean que detectaron dos problemas sutiles.
Dado que los agentes hacen que los proyectos secundarios ambiciosos sean más económicos, la economía de las auditorías se ha desplazado hacia revisiones impulsadas por herramientas que pueden asegurar sistemas complejos de manera mucho más exhaustiva que antes.
uso la IA para ayudarme a desarrollar mis plugins y componentes. úsalos bajo tu propio riesgo, pero no los etiquetaré con ningún descargo de responsabilidad ni etiqueta, igual que hace el núcleo de Discourse. Yo controlo los agentes, reviso el código (a veces con otro agente o con los ojos de otro LLM para ayudarme) y los pruebo. Eres libre de no usarlos, pero he visto con más frecuencia código deficiente escrito por completo por un humano que por una IA.
En efecto, creo que el enfoque tradicional para conocer la calidad de algo es comprobar la reputación de la entidad que lo creó. La reputación personal funciona bien cuando una persona está activa en código abierto. En general, si alguien ha realizado buen trabajo anteriormente y ha sido receptivo, continuará haciéndolo.
Aún así, tienes que hacer el trabajo sucio. Incluso al utilizar LLMs para crear herramientas deterministas, es necesario verificar que estas herramientas realmente ejecutan las acciones correctas, y no simplemente hacen algo que estadísticamente suele ser correcto. Usar LLMs para crear herramientas deterministas es mejor que simplemente proporcionar a los LLMs archivos markdown con la esperanza de que el resultado sea el mismo (aunque sigue siendo problemático legal y éticamente). Sin embargo, si esa herramienta determinista se mantiene a ciegas con LLMs, las nuevas versiones corren el riesgo de perder su comportamiento determinista con el tiempo.
Como Snyk mostró en su informe VulnBench, la auditoría con LLMs no es realmente fiable:
Me parece que usar agentes de IA para escribir temas de Discourse es realmente apropiado.
Eso sería genial. También podría valer la pena averiguar la configuración ideal para alguien que no tiene una sólida base en programación. Supongo que sería algo así como un agente de IA con acceso a una instancia de Discourse de desarrollo y un buen archivo de habilidades. Eso y algún tipo de revisión de seguridad automatizada.
Por supuesto, Sam y el equipo son la autoridad indiscutible y pueden corregirme si me equivoco, pero tras mucho experimentar por mi parte y con ganas de devolver algo a cambio, he aprendido en los últimos meses que Discourse Vibe y un buen uso del harness son lo que se sugiere y, de lejos, la situación ideal para empezar.
También es posible trabajar con ciertas pruebas en GitHub o incluso usando Discourse Container, pero la capacidad de desarrollo es limitada, especialmente para quienes tienen menos experiencia, como es mi caso.
Es posible «vibe codear» (escribir código de forma intuitiva) para Discourse usando IA, y solo hay que verificar o delegar la verificación final antes de presentar el trabajo realizado o usarlo en producción.
Por mi parte, no tengo la cualificación técnica para revisar código, pero tengo suficiente conocimiento para dirigir las funcionalidades, cómo y dónde adaptarlas, y preguntar específicamente qué generar o pulir. Así que imagino que alguien vendrá a contribuir abiertamente a la seguridad y la fiabilidad (siempre con revisión humana) del código para que pueda ser utilizado por toda la comunidad. No solo en Meta, sino en Discourse en general. Siempre ha sido mi objetivo, desde mi primer prompt.
Hace años pensaba que no habría sido capaz ni siquiera de dirigir a una IA para que me creara el código. Y hoy, con las salvedades y la legítima controversia que existe al respecto, es una realidad.
Sí, las cosas han cambiado mucho en el último año. Me gusta programar con agentes de IA, así que tengo sesgos.
Volviendo a lo que quizás sea el verdadero problema de este tema, creo que hay muchas razones para que la gente se preocupe por el impacto de la IA en la sociedad. No creo que el argumento de que los LLM (o más precisamente, los agentes de IA) son malos escribiendo código se sostenga bien con el tiempo. Mis propias preocupaciones están relacionadas principalmente con lo que sucede cuando tanto trabajo se canaliza a través de unas pocas grandes empresas tecnológicas. Sería necesario un ensayo para profundizar en eso aquí, sin embargo.
Los tiempos están cambiando, los modelos de pesos abiertos están cerrando rápidamente las brechas; lo que antes era una diferencia de 12 meses entre los modelos de frontera y los abiertos ahora se ha reducido a 3-6 meses.
Prevé que la IA se difundirá de manera mucho más uniforme en los próximos años. La IA local es una excepción hoy en día, pero se volverá más común, y cada vez más empresas alojarán su propia inteligencia, igual que lo hacemos en Discourse.
