Se avessi assunto uno stagista o avessi passato tu stesso 10 notti a lavorare, avresti potuto aggiungere un player FLAC alla tua app immaginaria. Prendere decisioni di prodotto sbagliate non è intrinseco all’uso dei LLM, e se aggiungere una funzionalità inutile sia o meno una perdita di tempo di sviluppo è sempre stato oggetto di discussione.
Le funzionalità extra non rendono necessariamente la tua app più lenta o più pesante in termini di RAM; quel problema è stato risolto dal concetto di caricamento dinamico - 40 anni fa.
Rifiutare tutti i plugin generati dall’IA semplicemente perché sono stati scritti da un’IA sarebbe un errore genetico. Il fatto che un contenuto sia generato dall’IA potrebbe essere stato in passato un buon criterio per identificarne la scarsa qualità, ma con il miglioramento dei modelli sta diventando sempre più difficile distinguere tra l’output umano e quello dell’IA. Se la preoccupazione riguarda la qualità o la sicurezza, ritengo che sarebbe più sicuro considerare tutto il codice come potenzialmente non sicuro finché non viene sottoposto a una sorta di sistema di revisione tra pari basato sul crowdsourcing.
Penso che condividere come il team lavora con l’IA oggi, dai designer ai programmatori, fino al legale, al marketing e ad altri settori, interesserebbe a molte persone.
Sapere qualcosa di IA, come faccio io, non significa conoscere e comprendere come un’azienda utilizzi davvero l’IA su base quotidiana.
Ho letto tutto quello che c’è qui e riesco a vedere entrambe le prospettive. Credo che sia positivo, ma al tempo stesso negativo, che le persone possano semplicemente creare plugin qui e pubblicarli, anche se contengono vulnerabilità di sicurezza “potenziali” che potrebbero compromettere un’installazione di Discourse.
Un po’ fuori tema.
Esiste un altro provider di software per forum (WoltLab) che ha, ad esempio, uno store di plugin. Prima di ogni rilascio, i plugin e i temi vengono revisionati dal team. Forse sarebbe un’idea implementare qualcosa di simile qui. Tuttavia, sorge sempre la domanda su chi dovrebbe effettuare la revisione, e posso immaginare che ciò richiederebbe un investimento significativo di tempo e personale.
Posso affermare con il 100% di certezza che non è assolutamente un’idea fattibile, per noi, quella di revisionare ogni plugin e tema di terze parti. (O almeno, non manualmente, da parte di un essere umano)
È stato interessante vedere le diverse opinioni di tutti sul perché questa trasparenza possa essere importante, sia per motivi morali che di sicurezza. Personalmente, non mi importa se qualcosa è stato creato da un ingegnere del software con 30 anni di esperienza che fa Ruby dalla notte dei tempi, o da un piccolo Timmy con zero esperienza di programmazione. Se è codificato al 100% in modo scadente[1], non lo userò; sarebbe ipocrita da parte mia. Capisco perché è popolare, ma non è qualcosa che intendo sostenere. Se questi modelli fossero addestrati in modo etico e non causassero carenze di componenti insieme a un’epidemia di media generati dall’IA, il mio sentimento verso questi modelli potrebbe essere meno negativo, ma non è il mondo in cui viviamo.
Le preoccupazioni sulla sicurezza per i plugin a livello globale sono anche valide e non si limitano al fatto che “questo è stato creato dall’IA”. Si tratta di un problema difficile da affrontare e che è fuori dallo scope di questo argomento; questo thread è semplicemente una proposta per richiedere tag per gli asset generati interamente da LLM.
rifiuto di usare termini come “vibe-coding” o “sviluppo agentico” ↩︎
Non vedo ancora quale problema stia cercando di risolvere. Qualcuno può darmi un esempio di un plugin creato con il “vibe coding” che fosse di scarsa qualità, insicuro o che consumasse troppe risorse? Uno che non avrebbe mai dovuto essere pubblicizzato qui perché era una totale schifezza e una perdita di tempo per tutti?
E se ci fossero davvero esempi del genere, sarebbero sufficienti da costituire un problema?
A me sembra che una sorta di checklist di autocertificazione per i temi sarebbe altrettanto utile: quante prove hai effettuato, sei pronto a ricevere segnalazioni su qualità e sicurezza, sarai reattivo al feedback.
O, in effetti, qual è il tuo processo di sviluppo, in non più di tre frasi.
Il valore di verità delle risposte non varrà molto, ma la differenza tra i temi che sono autocertificati e quelli che non lo sono potrebbe essere un segnale di valore, per chi sta pensando di installare il tema.
Per quanto mi riguarda, non uso mai il vibe-coding per nessuna applicazione, progetto o software che creo. Uso le chat AI per scambiare idee o per chiarimenti, ma mai per l’intero progetto. È sicuramente più manuale, ma almeno so cosa sto facendo e non mi fido ciecamente di un’altra entità.
Tuttavia, ho visto che la programmazione assistita dall’AI è cresciuta molto negli ultimi mesi. Forse all’inizio era di scarsa qualità o piena di vulnerabilità, ma direi che è migliorata enormemente da allora. I design vibe-coded sono ancora piuttosto riconoscibili (gradienti, bordi, emoji, ecc.), persino in alcuni plugin che ho visto su Meta. Ma ciò che conta è che l’autore li ha condivisi per i propri interessi e per quelli della comunità. Non perché qualcuno li calpesti e li etichetti come ‘slop’, ma perché ha trovato un vero successo con quel plugin e vuole condividerlo con altri forum là fuori che cercano di ottenere la stessa funzionalità.
Capisco il tuo punto sui problemi etici legati all’AI, ma sembra che si riferisca all’AI in generale, come le aziende che frantumano i libri, il massiccio consumo di acqua ed elettricità, ecc. Hai menzionato:
Ma come si correla questo all’uso di plugin o TC (teme/customizzazioni?) creati con l’AI? Se non ti piace l’AI, va bene, non usarla. Ma il panorama della programmazione è cambiato drasticamente con l’introduzione dell’AI, e quindi anche cose come plugin e TC lo saranno. Smetterai di usare completamente Discourse adesso, sapendo che parte del codice è stata scritta con l’aiuto dell’AI? Io no, perché so che ci sono ancora persone dietro.
Quindi, sarà ancora accurato chiamarlo ‘slop-coded’ e boicottare l’uso del termine ‘vibe-coding’ (personalmente, non vedo problemi con quest’ultima frase)? Forse no. È troppo severo? Sì. Quanto penso che tu non ti piaccia, a volte dobbiamo adattarci. Questo significa che ora creerò TC generati con l’AI e li condividerò? Per me, no. Ma significa che li vedrò come un’alternativa, da non respingere o guardare con disprezzo? Sì. E sto cercando di non farlo. Quindi spero che tu possa fare lo stesso.
Condivido un articolo selezionato su questo argomento:
Trail of Bits sostiene che gli agenti AI siano più utili negli audit per la creazione di strumenti personalizzati, non solo per trovare bug. In un audit di Miden zkVM, hanno utilizzato Claude e Codex per creare un server LSP, un decompilatore, un analizzatore statico e un modello Lean, scoprendo un bug di forgiatura di firme di alta gravità e 95 prove Lean che hanno individuato due problemi sottili.
Poiché gli agenti rendono economici i progetti ambiziosi, l’economia degli audit si è spostata verso revisioni guidate dagli strumenti, in grado di proteggere i sistemi complessi molto più a fondo rispetto al passato.
uso l’IA per assistere lo sviluppo dei miei plugin e componenti. Utilizzateli a vostro rischio e pericolo, ma non li etichetterò con alcun disclaimer o tag, esattamente come fa il core di Discourse. Sono io a controllare gli agenti, a rivedere il codice (a volte con l’aiuto di un altro agente o di un altro set di occhi LLM) e a testarlo. Siete liberi di non usarli, ma ho visto più spesso codice scadente scritto interamente da un essere umano che da un’IA.
In effetti, credo che l’approccio tradizionale per valutare la qualità di qualcosa sia verificare la reputazione dell’entità che l’ha creata. La reputazione personale funziona bene quando una persona è attiva nell’open source. In generale, se qualcuno ha svolto un buon lavoro in passato ed è stato reattivo, continuerà a farlo.
Bisogna comunque fare il lavoro sporco. Anche quando si utilizzano LLM per creare strumenti deterministici, è necessario verificare che questi strumenti eseguano effettivamente le azioni corrette e non semplicemente qualcosa che statisticamente è spesso corretto. Utilizzare LLM per creare strumenti deterministici è meglio rispetto al solo invio di prompt a LLM con file markdown nella speranza che il risultato sia lo stesso (ancora problematico dal punto di vista legale ed etico). Tuttavia, se tale strumento deterministico viene mantenuto in modo acritico con LLM, i nuovi rilasci rischiano di perdere il loro comportamento deterministico nel tempo.
Come mostrato da Snyk nel loro report VulnBench, l’audit con LLM non è davvero affidabile:
Usare agenti AI per scrivere temi per Discourse mi sembra davvero appropriato.
Sarebbe fantastico. Potrebbe anche valere la pena capire la configurazione ideale per chi non ha una solida formazione in programmazione. Immagino che sarebbe qualcosa come un agente AI con accesso a un’istanza di sviluppo di Discourse e un buon file di competenze. Questo, insieme a una sorta di revisione della sicurezza automatizzata.
Certo, Sam e il team sono l’autorità indiscussa e possono correggermi se sbaglio, ma dopo molte sperimentazioni da parte mia e felice di dare qualcosa in cambio, ho imparato negli ultimi mesi che Discourse Vibe e un buon utilizzo dell’harness sono ciò che viene suggerito e, di gran lunga, la situazione ideale con cui iniziare.
È anche possibile lavorare con determinati test su Github o persino utilizzando Discourse Container, ma la capacità di sviluppo è limitata, soprattutto per chi ha meno esperienza come nel mio caso.
È possibile scrivere codice “vibe” per Discourse utilizzando l’AI e basta verificare o delegare la verifica finale prima di presentare il lavoro svolto o di utilizzarlo in produzione.
Per quanto mi riguarda, non sono tecnicamente qualificato per rivedere il codice, ma sono in grado di dirigere le funzionalità, come e dove adattarle, e chiedere specificamente di generare o rifinire, quindi immagino che qualcuno arriverà a contribuire apertamente alla sicurezza e all’affidabilità del codice (sempre con revisione umana) in modo che possa essere utilizzato dall’intera comunità. Non solo su Meta, ma Discourse in generale. È sempre stato il mio obiettivo, fin dal mio prompt iniziale.
Anni fa pensavo di non essere nemmeno in grado di dirigere un’AI per farmi creare il codice. E oggi, con le riserve e la legittima controversia che esiste al riguardo, è una realtà.
