Nel post precedente vi ho mostrato come uso l'AI nel mio quotidiano lavorativo.
Ho in mente di fare ulteriori esperimenti, che però richiedono tempo, perchè stiamo usando uno strumento PROBABILISTICO: spesso, a parità di input, ho ricavato risposte anche drammaticamente scorrelate. Non fatevi prendere in giro da chi vi racconta che la soluzione è tutta nel prompt: non è vero.
Se usate buoni prompt, avrete risultati migliori. Ma ci vogliono anche guard-rail robusti. E bisogna testare le risposte.
Non vi ho fornito i dettagli, non ho citato il nome dell'AI engine che uso per uno scopo o quello che uso per fare altro. Non è importante questo.
Perchè? Perchè l'AI engine è solo uno strumento. Nel prossimo mese si affacceranno sul mercato nuove soluzioni o magari 2/3 nuove versioni per ogni AI engine che usate ogni giorno.
Il problema non è rincorrere l'ultima feature dell'ultima versione dell'ultimo engine.
Il problema è capire il processo END TO END che può, EVENTUALMENTE, trarre vantaggio da una ridefinizione del processo stesso con l'aiuto dell'AI.
L'AI Gen può aiutarti a fare proficuamente alcune cose, non tutto.
AGGIORNARE/DEFINIRE LA DOCUMENTAZIONE ASSOCIATA AD UNA GUI
Quando emerge una nuova logica di business che può arricchire il prodotto, magari si decide di aggiornare la Graphic User Interface (GUI) che implementa quella logica. O addirittura viene definita una GUI completamente nuova, progettata da zero.
Quando questo accade, io devo:
- Parlare con il Product Manager per capire la logica di business.
- Parlare con gli sviluppatori per capire la logica della GUI.
- Usare in autonomia la GUI e capire i flussi operativi fondamentali da documentare.
- Scrivere, da tutto quello che ho capito e sperimentato, la documentazione per l'utente della GUI.
In questa lista, i verbi fondamentali (quindi le azioni da svolgere) sono capire, usare/sperimentare.
Queste cose non possono essere affidate all'attuale AI Gen. Perchè? Perchè l'attuale AI Gen non accede alla SEMANTICA di nessuna cosa.
Certo, dopo aver scritto la prima versione della documentazione, l'AI mi può aiutare nei modi che ho illustrato nel post precedente. Ma prima no.
AGGIORNARE/DEFINIRE LA DOCUMENTAZIONE ASSOCIATA AD UNA API
Ho scritto diversi articoli relativi alla documentazione delle API.
Oggi esistono tool e standard che dalla definizione dell'API sono in grado di realizzare un'ottima documentazione di tipo reference. Ma se poi volete documentare uno use case specifico, in cui l'uso di quella API può aggiungere valore in modo determinante, vi trovate a dover gestire un ciclo di lavoro (e quasi sempre a dover iterare quel ciclo) simile a quello in 4 passi illustrato in precedenza.
Perchè? Sempre per lo stesso motivo. L'AI Gen può leggere lo schema di definizione della API, potete anche dargli in pasto il codice sorgente, ma non può descrivere uno use case completo e specifico che possa essere "di valore" per il cliente che si appresta a comprare quella API. Perchè l'AI non accede alla SEMANTICA della logica di business che vi ha indotto a produrre quella API.
QUALITY ASSURANCE (TEST) DEL PRODOTTO
Soltanto usando e testando il prodotto si può essere "ragionevolmente" sicuri che il prodotto faccia esattamente quello per cui è stato creato. Dico "ragionevolmente" perchè nella mia esperienza ho lavorato con prodotti molto potenti e ampiamente configurabili.
Dalle diverse combinazioni delle diverse configurazioni poteva essere generato un numero elevatissimo di possibili comportamenti del prodotto. Ogni comportamento, in teoria, da testare.
Da molti anni abbiamo procedure di test automatizzate a vari livelli (dal test della singola classe di codice, al test end to end per uno use case significativo, al test di casi limite che possono comunque verificarsi, ai test di regressione, etc.).
Ma per definire una procedura di test bisogna capire cosa vuoi testare, cioè la semantica del test.
Una GUI può ospitare un numero di componenti anche molto elevato (basta guardare la GUI di Microsoft Word).
L'utente è libero di seguire flussi di lavoro anche molto complessi e quei flussi vanno testati. E il modo in cui un utente interagisce con una nuova GUI è spesso poco prevedibile. Spesso gli sviluppatori rimangono sorpresi nel vedere come l'utente finale interagisce con la GUI. Discipline come il Design Thinking sono nate proprio per questo: per progettare qualcosa "intorno all'utente", cercando di definire al meglio le sue esigenze.
Tutta questa "complessità" risiede nel rapporto dinamico tra l'uomo e il software e ad oggi l'AI Gen non può governare tutto questo.
Quando navigo in una GUI e mi metto nei panni dell'utente, l'AI Gen non può aiutarmi. Quando scelgo la combinazione dei parametri in input ad una API e verifico la correttezza (by design) dell'output, l'AI Gen non può aiutarmi. Certo, potrebbe tentare di farlo... se io potessi trasferire all'AI la semantica del design, la configurazione sottostante, la semantica delle strutture dei dati che quella API deve gestire, i log di sistema. Certo. Tutto molto bello. Ma per fare questo bisogna trasformare i processi aziendali (cosa non banale) e dovete consentire all'AI l'accesso ai sistemi aziendali, il che implica anche notevoli considerazioni legali e di sicurezza su quali informazioni si possono condividere con l'AI e quali no.
Ancora una volta, non ci sono pasti gratis nell'adozione della AI.
E se la GUI o la API hanno una "regressione"? Cioè se la nuova versione, che aggiunge un comportamento desiderato, "rompe" un altro comportamento, che prima funzionava ed ora non funziona più? Nella produzione del software questo può capitare, i test di regressione si fanno per questo.
Io, che conoscevo la logica e la semantica del comportamento precedente mi posso accorgere della regressione: l'AI Gen no.
SCOPRIRE REQUISTI IMPLICITI, CASI LIMITI, CARENZE NON PREVISTE
Al netto delle "narrazioni consolatorie", non esiste nessuna progettazione "perfetta", indipendentemente dal fatto che si applichino i principi della progettazione Waterfall, Agile o qualsiasi altra cosa.
Quando il prodotto va in staging e prima di portarlo in produzione, emergono dei casi limite che non erano stati individuati nella fase di progettazione.
O ci si accorge di un "buco" (di sicurezza, di usabilità, o nella logica di business) che solo il test condotto da un utente umano può far emergere. E spesso i Technical Writer si fanno carico di questa parte del lavoro, perchè DEVONO mettersi nei panni dell'utente.
Oppure ci si accorge che va specificato un pre-requisito essenziale, che non era stato individuato prima.
Anche per questi motivi le metodologie Agile hanno preso piede: perchè l'N-esima iterazione dello sviluppo aiuta, progressivamente, a raffinare la soluzione e filtrare quello che non era emerso all'iterazione N-1.
In tutti questi aspetti, ancora, è richiesta conoscenza della semantica della funzione che si sta indagando, del contesto (la configurazione? O i dati in input e la configurazione? O altro ancora?), dello use case e del modo in cui l'utente procede, che non è necessariamente univoco (spesso, usando un software si arriva allo stesso risultato attraverso procedure diverse).
Anche questo fa parte del mio lavoro, perchè poi devo spiegare all'utente come gestire tutto questo. E l'AI Gen, che non capisce la semantica di nessuna cosa, non mi può aiutare.
GARANTIRE CONFORMITA' LEGALE/REGOLATORIA
La documentazione del software da questo punto di vista non deve rispettare obblighi cogenti.
Ma in altri settori, è necessario scrivere documentazione tecnica che sia perfettamente "conforme" alle norme di settore.
Non entro nel dettaglio, ma di certo l'AI Gen non vi può assicurare che quello che scrivete sia conforme ad un qualsiasi regolamento europeo o norma specifica. O meglio... se gli chiedete un parere, vi fornirà una risposta, magari rassicurante, ma sarà comunque a carico vostro il lavoro di verifica della conformità.
Perchè? Perchè l'AI Gen non capisce la semantica di quello che scrivete e non capisce la semantica del regolamento a cui vi dovete attenere.
Certo, vi può avvertire se nel vostro documento manca una specifica sezione (ad esempio, quella delle avvertenze di sicurezza), nel caso in cui dovete essere conformi ad un regolamento che vi obbliga ad inserire tali avvertenze nel manuale del prodotto. In tal caso vi sta aiutando nel rilevare un buco nella STRUTTURA del documento, e abbiamo già detto che in tal caso l'AI Gen può aiutare.
Ma per molti altri aspetti, è ancora impotente.
Nel 2025 ho scritto alcuni articoli sull'EU AI Act. Non perdo tempo ad elencare le clamorose inesattezze che ho rilevato quando mi sono rivolto all'AI Gen per fare un po' di brainstorming&filtering dell'AI Act. Ad un certo punto, si è lanciata in una notevole dissertazione sull'articolo 142... vi assicuro molto convincente. Peccato che nell'AI Act non è presente alcun articolo 142!
Immaginate situazioni in cui la vostra documentazione deve rispettare regolamenti potenzialmente concorrenti o in parte sovrapponibili.
Ad esempio, immaginate i produttori di macchine industriale che presto dovranno conformare la loro documentazione al nuovo Regolamento Macchine ma che nel periodo transitorio potevano ancora riferirsi alla vecchia Direttiva Macchine. Sarei curioso di sapere se qualche collega si è affidato all'AI Gen per gestire qualche aspetto del periodo transitorio. Ma a lume di naso, direi che in tutte queste attività non ci si può ancora fidare dell'AI Gen.
L'AI NON CAPISCE LE COSE, QUINDI NON PUO' FARE DOMANDE
Due delle fasi fondamentali del mio lavoro consistono nell'usare il prodotto e fare domande. Le stesse domande che potrebbe fare un utente disorientato davanti ad una nuova GUI o una nuova API. Le domande che servono per entrare dentro la logica di business di una nuova feature. Le domande che servono per individuare i pre-requisiti o i casi limite.
Fortunatamente, solo gli umani possono formulare domande, individuare nuovi problemi e analizzare vincoli critici.
----
Come vedete, ci sono molte aree del mio lavoro che ancora non possono trarre vantaggio dall'AI.
Su altre cose ci sto lavorando.
Ne parliamo nei prossimi post.
Nessun commento:
Posta un commento