I rischi quando si usano i co-worker AI
Si sta diffondendo l'utilizzo da parte di chi sviluppa (in particolare) dei cosiddetti co-worker AI, i quali somigliano molto ad un IDE (Integrated Development Environment), quindi con gestione delle cartelle, dei file di configurazione, con una certa commistione fra aree di sviluppo, di produzione o di rilascio tramite piattaforme come github.
Una caratteristica molto importante di questi ambienti è che vogliono in pratica riprodurre il più possibile la stessa sensazione tradizionale di fare sviluppo, quindi basandosi su alcuni speciali file detti MD o di altro tipo, nei quali ci sono gli orientamenti principali di un progetto.
Dato che l'AI può padroneggiare allo stesso tempo il codice e la sintassi tipica di questo e dei file di configurazione, ma allo stesso tempo il linguaggio naturale, è molto facile che i due domini si confondano ed in un file dall'apparente sintassi esatta e specifica dimenticare dei valori che non dovrebbero esserci, magari affidandosi a istruzioni in linguaggio naturale più o meno travestite da ordini deterministici nel codice stesso.
Questo può portare a confondere quello che è il regno deterministico di ciò che sarà effettivamente compilato ed andrà ad essere eseguito da sistemi tradizionali procedurali (la macchina o il device), e quello che è invece il regno del linguaggio naturale, che in teoria potrebbe essere non eseguito, oppure eseguito in forma non perfettamente allineata, magari perché ci sono dei “non detto” che si danno per scontati e che invece per il LLM non lo sono, o perché fa fede qualcosa che è scritto da qualche parte e che non viene intercettato dalla compilazione, essendo posto in commenti o istruzioni per il LLM.
Dunque ci sono numerosi rischi di questa confusione possibile fra livelli diversi di pensiero/astrazione ed esecuzione, specie se il LLM diventa sempre più discreto e invisibile, tanto che non si capisce quale delle cose scritte siano state scritte per una successiva reinterpretazione o per una reale esecuzione, e viceversa non si capisce quanto un codice scritto con una sintassi rigorosa sia in realtà poi invece passibile di rielaborazione non necessariamente deterministica, e come saranno interpretati i commenti, a volte lasciati lì senza pensarci troppo.
Attenzione "non deterministico" non è usato qui nel senso di casuale, bensì di "soggetto all'arbitrio" del LLM. Quindi ancora una volta non c'entra il pappagallo stocastico.
Certe operazioni vanno eseguite in produzione solo se sono effettivamente compilate e non se soltanto sembrano destinate a tale compilazione ma ciò solo in apparenza. E tanti altri esempi si potrebbero fare, per esempio, cosa inviare nei repository, quali operazioni automatiche eseguire etc.
Il versioning è particolarmente suscettibile di queste problematiche. Affidarlo all’AI potrebbe essere un errore, perché proprio in strumenti deputati a tale scopo si sente il maggior bisogno di azioni deterministiche e reversibili, anche per non perdere fasi intermedie del lavoro spesso non desumibili in maniera retroattiva. Chi non ha fatto esperienza di aver rovinato del lavoro fatto perché più modifiche si sono “mescolate” insieme come in un coacervo non più scioglibile?
Certi ordini precisi, certi filtri, non devono essere lasciati all’interpretazione del LLM, specie perché quelli che possiamo considerare ordini chiari in realtà per esso potrebbero essere lacunosi o essere sovrascritti da altri, posti e dimenticati chissà dove.
Infatti con i LLM non si sa mai quale ampiezza di sguardo stanno usando per decidere cosa fare in un punto locale, non sempre riescono a separare i domini e determinare la freschezza e rilevanza di un frammento di testo che potrebbe aver suscitato qualcosa nella loro rete neurale.
In pratica si può dire che quelle caratteristiche che permettono ai LLM di funzionare costituiscono anche il loro limite. Non si può mai sapere quale frammento di testo, lontano o vicino, preciso o vago, abbia attivato un certo gruppo di neuroni finora silente e che ora non si disattiva più, perché andato in "risonanza" con altri elementi presenti chissà dove nel progetto, o magari proprio quelli preminenti, diventando la fonte di certi prodotti nell’output, magari in contraddizione con le intenzioni degli utilizzatori.
Questi aspetti non sono ancora ben inquadrati, in quanto si crede che andranno migliorando nel tempo con l’evolversi dei modelli, ma purtroppo sembrano intrinseci piuttosto.
Il fatto che di fatto tutto sembri funzionare e che gli errori siano minimi è in realtà ingannevole.
La deviazione microscopica, che nell’ambito deterministico può avere grosse conseguenze, non viene da un errore statistico (pappagallo stocastico) bensì da una decisione interna del modello, nei suoi strati profondi, causata dalla larghezza stessa del contesto.
Inoltre anche i flussi logici mentali dell'utente sono alterati e soggetti ad equivoci, per esempio si potrebbe non ricordare esattamente se una certa istruzione era stata posta nel dominio deterministico del progetto (posto che esista un luogo dove l’AI non agisca o rispetti i divieti) o invece se era stata data come istruzione all’AI.
Tali dimenticanze sono del resto intrinseche quando l’authorship delle azioni e delle decisioni è indebolita per il continuo affidarsi all’AI, sia nel singolo progetto sia in generale.
Le persone potrebbero gradualmente perdere quel nerbo, quella volontà, di essere responsabili in prima persona dei punti nodali delle cose.
Si pensi poi anche ai finti terminali sotto i quali si “nasconde” l’AI, del tutto identici a quelli normali dove tradizionalmente si scrivono comandi con la massima attenzione, per esempio anche richiedendo permessi superiori per agire in certi ambiti protetti.
Chi si approccia a queste cose per la prima volta, può essere influenzato dai risultati appariscenti effettivamente conseguibili, ma non avere sufficiente controllo e consapevolezza per capire che tipo di workflow sta in realtà seguendo, o cosa sta accadendo.
Il ruolo degli Hustlers
E’ sotto gli occhi di tutti comunque che la fregola indotta dagli hustler, per esempio nella forma di influencer, non solo non accenna a sopirsi ma anzi viene moltiplicata dagli specchietti per le allodole AI, in una frenesia che spinge tutti a non considerare per bene i rischi, presi dall’entusiasmo di queste nuove possibilità.
Non voler rinunciare a qualcosa di immediato per rispetto del determinismo necessario è un effetto psicologico naturalmente conseguente all’uso indiscriminato dell’AI.
Quanto detto sopra per lo sviluppo software può essere esteso a chi usa tali strumenti nel proprio lavoro, sia nel pubblico che nel privato, specie in quei contesti di lassismo dove conta più figurare di far qualcosa che farlo allo stato dell’arte e prevedendo i risultati a medio e lungo termine, rispettando l’etica lavorativa.
La sovrapproduzione di qualsiasi cosa, di tutto, è oramai un problema reale, mentre per risolvere i problemi reali e sentiti si dovrebbe invece andare per sottrazione.
Invece no, tutti moltiplicano le proprie attività, spesso inutili tentativi buttati là un tanto al chilo e poi di nuovo a ricominciare con altre idee balorde, tanto poi se ne occupa il coworker AI di turno, anzi i vari agents lasciati lavorare a vanvera tutto il giorno.
Molti non capiscono che il denaro è un flusso che difficilmente premia l’enshitification. Usare la forza bruta l’AI per forzare il “muro” dei soldi non può funzionare, specie se tutti fanno la stessa cosa.
Voi cosa ne pensate?