Obbligo di etichettare come tali i temi e i plugin generati da LLM

Contribuisci Feedback sul sito
1

Attualmente, alcune persone potrebbero cercare di caricare plugin, temi o componenti generati interamente da LLM senza dichiararlo come tale. Esistono molte ragioni per cui potrebbe essere utile sapere quando qualcosa è stato generato completamente da un LLM, e al momento non esiste alcun obbligo di dichiarare tali plugin in questo modo. Personalmente, mi piacerebbe saperlo in anticipo, così da non finire per installare un plugin di bassa qualità con tutti quei problemi di prestazioni, ottimizzazione e UX tipici dei plugin generati da LLM.

Ovviamente, tutto questo si basa sull’onestà e sulla trasparenza delle persone (e chi ha generato argomenti con l’AI potrebbe non sapere meglio di quanto scritto), ma avere un tag come #ai-generated da applicare agli asset generati principalmente da AI sarebbe vantaggioso per tutti.

2 Mi Piace
2

Non sono d’accordo con l’idea che un plugin generato da un LLM sia intrinsecamente di bassa qualità o che soffra necessariamente di problemi di prestazioni, ottimizzazione o UX. La qualità del risultato dipende in larga misura dalla persona che guida l’LLM e ne revisiona l’output.

Sono orgoglioso del software che ho sviluppato negli ultimi 40 anni e l’integrazione degli LLM nel mio flusso di lavoro ha migliorato la qualità del mio lavoro, non l’ha diminuita.

Al contrario, ho visto numerosi plugin scritti a mano pieni di vulnerabilità di sicurezza, problemi di prestazioni e scelte di progettazione scadenti, dove avrei sinceramente voluto che l’autore avesse utilizzato un LLM. In definitiva, ciò che conta è la qualità dello sviluppatore e del codice risultante, non il fatto che un LLM sia stato coinvolto nella sua stesura.

10 Mi Piace
3

Mi chiedo come siate soliti rivedere e/o aggiornare il codice generato dai LLM, per chi, come me, si sta avvicinando al vibe-coding per implementare nuove funzionalità o personalizzare quelle già in produzione.

So che una revisione collettiva su repository pubblici è l’ideale, ma preferisco prima fare i compiti a casa e pubblicare solo versioni che abbiano esaurito le mie attuali capacità.

Concordo con il commento precedente: non sono contro l’IA, ma sono consapevole che TUTTO ciò che genera deve essere auditato, verificato e aggiornato dagli esseri umani.

Un fatto curioso, in merito:

1 Mi Piace
4

È assolutamente giusto e, in ultima analisi, posso parlare solo per conto mio. La mia osservazione riguarda le app “slop” di bassa qualità, tutte identiche tra loro e generalmente di scarsa qualità (sia in termini di funzionalità che di sicurezza), insieme alle app esistenti che hanno visto un grave calo di qualità da quando hanno iniziato a delegare gran parte del lavoro ai modelli LLM (come Visual Studio Code e Formbricks; entrambe le quali ho smesso di usare). Anche se la tua app fosse perfetta, ci sono comunque preoccupazioni etiche, quindi sarebbe ottimo se ci fosse una forma di notifica per queste creazioni, come suggerito. Questo non significa che qualcuno debba basare qualcosa sull’etichetta, ma se lo si desidera, è una bella opzione.

Come ho detto, si tratta di un sistema basato intrinsecamente sulla fiducia e la responsabilità spetta esclusivamente allo sviluppatore di assicurarsi che venga etichettato come tale. Ovviamente ci sono alcuni casi in cui il modello LLM si etichetta da solo nei log di git (come fanno la maggior parte), quindi un utente con livello TL3+ può intervenire se lo desidera consultando GitHub.

5

Apprezzo la tua risposta, grazie. La mia domanda è rivolta anche a tutti e riguarda gli strumenti attualmente disponibili per verificare il codice generato dagli LLM.

Non sono uno sviluppatore, ma sono riuscito a implementare funzionalità che non esistevano in Discourse. E voglio fare del mio meglio, nel migliore dei modi, ciò che è alla mia portata.

Considererò l’etichettatura se deciderò di pubblicare i miei repository; per ora sono privati proprio perché li sto testando e sono interessato a fare tutto nel modo corretto prima di condividerli con la comunità.

6

Sarei estremamente sorpreso se la maggior parte del codice Core (inclusi i plugin Core) non venisse ormai sviluppata con agenti di coding, tanto è cambiato il modo in cui si sviluppa.

A mio avviso, è ormai molto difficile giustificare il non utilizzo di agenti di coding nella maggior parte dei lavori, poiché la perdita di efficienza semplicemente non avrebbe senso dal punto di vista economico.

3 Mi Piace
7

Non mi preoccupa affatto “come è stato creato un plugin” né se l’artefice abbia usato una matita o una penna.

Il fatto che “non ci sia IA” non mi dà nemmeno un briciolo di fiducia in più quando si tratta di installare un tema o un plugin.

Tuttavia… c’è un problema molto più serio che dobbiamo affrontare su CDCK.

I plugin di base e il codice sorgente di Discourse vengono sottoposti regolarmente a scansioni di sicurezza: quando una persona installa un canale supportato, ha la certezza di quanto il codice sia sicuro.

I plugin e i temi di terze parti qui presenti sono “il Far West”: chiunque può contribuire, non li sottoponiamo a scansioni di sicurezza né ci assicuriamo che seguano le migliori pratiche. Questo mette a rischio la community.

Vorrei raggiungere un mondo in cui la “versione XYZ” di un tema venga almeno sottoposta a una scansione automatica, per dare almeno un po’ di sicurezza a chi gestisce un’istanza self-hosted.

Quindi la mia visione qui è esattamente l’opposto :slight_smile: : richiedere che le versioni di temi e plugin di terze parti superino una sorta di scansione IA prima di essere pubblicizzate qui.

5 Mi Piace
8

A mio avviso, almeno sul piano etico, la revisione del codice tramite LLM è completamente diversa dal dire a Claude «costruisci questa app e non commettere errori» e pubblicare l’output con poca o nessuna validazione o modifica fatta da parte tua. Purtroppo, non si può davvero obbligare un utente finale a essere responsabile, e per quanto ci si sforzi, qualcuno troverà sempre il modo di scaricare qualcosa di malevolo. Detto ciò, quanto siano etici gli LLM è un discorso a parte e non è davvero rilevante per questo thread.

e va bene così! Non sto proponendo un divieto totale di qualsiasi cosa che coinvolga l’IA in Customization.. Vorrei semplicemente che venisse etichettata correttamente, in modo che chi non vuole aprire quel barattolo di vermi non lo faccia per sbaglio.

9

Ho molti problemi con gli strumenti basati su LLM (e con i loro risultati). Non solo quelli relativi alla sicurezza, alla legalità, all’affidabilità e all’impatto ambientale. Ma questo non è il punto principale qui.

La sicurezza, intesa in senso ampio, è il problema cruciale in questo contesto, indipendentemente dal fatto che il codice sia generato dall’IA o meno.

Quali strumenti utilizza CDCK per i controlli di sicurezza? Molti di questi sarebbero importanti anche per le creazioni di terze parti.

Ma ci sono altri aspetti da verificare. Con quali sistemi esterni comunica la creazione di terze parti? La maggior parte degli strumenti di analisi della sicurezza accetta che il software comunichi con server esterni, senza un heartbeat. Tuttavia, un componente puramente cosmetico come un tema non dovrebbe effettuare alcuna chiamata a un server esterno. Quindi, la creazione di terze parti può contenere vulnerabilità di sicurezza o problemi che possono compromettere la disponibilità. Ma potrebbe anche esfiltrare dati.

10

Sono d’accordo al 95% con questo. E ora stiamo parlando di Discourse: immagina se fossimo nel mondo di WordPress!

(Quel 5% mancante: non penso che sia il “selvaggio west” — i problemi di sicurezza vengono segnalati tramite meta a quegli sviluppatori di terze parti e in generale vengono risolti piuttosto rapidamente).

Ma allo stesso tempo, la mia esperienza mi dice che gli LLM (oggi) generano codice più sicuro rispetto alla media degli autori di plugin umani. E puoi passare un plugin a qualsiasi LLM decente e chiedergli di “trovare e correggere eventuali problemi di sicurezza”, e lo farà, anche se l’utente umano non ha molte conoscenze in materia di sicurezza.

Ho esaminato manualmente i plugin per l’ultimo decennio e ne ho visti di tutti i colori: iniezioni SQL (da parte di persone che pensavano che ActiveRecord fosse troppo complicato), impostazioni delle chiavi API con client: true, completa mancanza di autorizzazione e controlli di accesso, assenza di rate limiting. Tutti questi problemi vengono trovati e corretti dagli LLM in poco tempo e senza troppi sforzi.

Quindi, di nuovo: penso che gli LLM abbiano reso le cose migliori, non peggiori.

Stai ancora associando il codice generato dagli LLM a un “barattolo di vermi”, è troppo bianco e nero.

4 Mi Piace
11

Jack McDade ha adottato questo approccio con la directory dei plugin per Statamic

Accolgo favorevolmente questo approccio, l’ho trovato utile per confermare ciò che sapevamo già dovesse essere fatto. Aiuta anche a costruire fiducia nel codice.

Sembra che qualcosa di simile possa essere implementato qui senza troppi sforzi da parte del Team.

4 Mi Piace
12

Sono anche preoccupato dai plugin e dai componenti di bassa qualità, e non mi fido molto di quelli che per il 99% sono stati creati tramite “vibe coding” da persone che non conoscono la programmazione.

Ma credo anche alle affermazioni di programmatori esperti, qui e là, secondo cui i programmatori scadenti esistevano da molto prima dell’AI[1]. Codice approssimativo, inaffidabile e difettoso è stato scritto a mano da secoli.

Ciò che mi preoccupa è quando vedo un’app/plugin/qualunque cosa creata tramite vibe coding e sospetto che l’autore non abbia revisionato il codice.

Ho alcune conoscenze di base in programmazione, ma non scrivo codice da molto tempo e non sono mai stato bravo. Ho provato a fare vibe coding per alcuni progetti.

Inizialmente ero molto riluttante a pubblicarli ufficialmente su meta, ma alla fine l’ho fatto dopo aver preso il tempo di revisionare e capire cosa facesse ogni pezzo di codice e di dichiarare pubblicamente il mio approccio nei miei topic. Non ricordo tutto ciò che ho letto prima di pubblicare quei plugin, ma almeno potevo garantire l’affidabilità e la sicurezza al momento della pubblicazione di quel lavoro.

Ho un buon esempio per illustrare come il vibe coding potrebbe farmi rilasciare un plugin molto insicuro.

Prima di lavorare su 🖼️ Topic Gallery, ho creato un proof of concept di un plugin simile qui: A way to monitor user-uploaded files 🖼️ - #2 by Canapin
Funzionava alla grande e l’AI ha seguito le mie direttive.

C’era un problema, però: anche se la funzionalità era chiaramente una funzione di moderazione, l’AI non ha tenuto conto dei permessi: qualsiasi utente, inclusi i visitatori, poteva aprire questa pagina e vedere tutti i file caricati da tutti gli utenti. Per me era ovvio che dovesse essere accessibile solo agli admin, ma l’AI non ci ha “pensato”. E poiché non gliel’ho chiesto, ha creato una pagina pubblica di default.

Quindi continuo a dirmi che se io e l’AI siamo stati in grado di trascurare una simile falla di sicurezza, allora i non programmatori che fanno vibe coding di TC e plugin potrebbero purtroppo fare la stessa cosa.

Le opinioni sul codice AI nel software sono fortemente polarizzate. Basta dare un’occhiata a qualsiasi progetto open source popolare in cui Claude è citato come co-autore degli ultimi commit per vedere una valanga di odio da parte di certe persone.
Sono convinto che dovremmo affrontare queste cose con cautela e che le nostre opinioni dovrebbero essere più sfumate.

Non sono particolarmente favorevole all’idea di avere un tag vibe-coded che potrebbe danneggiare inutilmente la popolarità di personalizzazioni ben codificate e sicure e dei loro autori.

So che ora chiunque può produrre personalizzazioni, che probabilmente ne arriveranno sempre di più ogni giorno e che non ci sono abbastanza persone per revisionarle.

La revisione tramite AI è forse la soluzione. Il mio istinto non mi piace molto questa idea per vari motivi, ma credo che se Sam propone questo tipo di soluzione, probabilmente è una buona, perché mi fido molto delle sue competenze e del suo giudizio. Soprattutto dato che io stesso non ne so nulla. :laughing:

Forse alcuni sviluppatori qui che conoscono la programmazione e l’ecosistema Discourse potrebbero avere un titolo che mostri esplicitamente la loro competenza in questo campo, così da essere considerati sviluppatori affidabili anche dai visitatori che cercano solo personalizzazioni qui senza registrarsi. Sarebbe l’opposto di ciò che chiedi, darkpxlz. Invece di “umiliare” potenziali personalizzazioni inaffidabili, metteremmo in risalto quelle affidabili. :slight_smile:

Solo spunti di riflessione, però. :person_shrugging:

  1. Dovrei saperlo, ne facevo parte anch’io! ↩︎

4 Mi Piace
13

È del tutto possibile che io mi trovi in una camera dell’eco anti-IA, influenzata dai media che consumo e dalle persone con cui interagisco quotidianamente. Ero quasi certo che questa richiesta non sarebbe stata così impopolare, ma se tutti qui amano davvero programmare con gli LLM e non vogliono un tag puramente per trasparenza, chi sono io per fermarli? Rilevare il codice generato da LLM è ancora piuttosto facile, quindi se qualcuno (come me) vuole davvero evitarlo, può semplicemente controllare i contributor per un tag LLM che si auto-identifica, come ho suggerito in precedenza.

1 Mi Piace
14

Dato che si tratta di un argomento controverso, personalmente sostengo la tua richiesta originale, che soddisferebbe quella parte della comunità che, al momento, è più scettica (giustamente).

Tuttavia, sospetto che finiremmo per etichettare quasi tutto, il che vanificherebbe in un certo senso lo scopo.

Concordo anche con gli altri nel dire che non tutto il codice generato dall’IA è di pari qualità: in alcuni casi è prodotto da modelli più recenti e costosi, guidato da sviluppatori esperti, mentre in altri potrebbe essere il risultato di un singolo tentativo di una persona meno esperta che utilizza un modello meno capace, e il repository potrebbe non seguire le migliori pratiche. Questo si può valutare solo esaminando il repository stesso e osservando se le persone riscontrano problemi frequenti.

3 Mi Piace