Come uso l'AI: il controllo di qualità

Quando lavoravo in IBM, nel mio IDE (Integrated Development Environment) era installato il plug-in di una famosa società tedesca (di cui non farò il nome).

Questo strumento mi aiutava a scrivere documentazione che fosse conforme a 3 standard contemporaneamente:

• DITA
• US English
• IBM Style Guide

Mentre scrivevo, in tempo reale lo strumento mi indicava gli eventuali errori che facevo aiutandomi nel correggerli.

Avete mai provato a consultare 3 manuali diversi della IBM? Vi sembreranno scritti dalla stessa mano. Ovviamente non è così, ma quello strumento offriva a tutti i technical writer della IBM la possibilità di scrivere contenuti perfettamente conformi agli standard sopra indicati.

Oggi non dispongo di un IDE così configurato ma da un pò di tempo sto sperimentando un prompt che mi aiuta a realizzare un controllo di qualità "a posteriori".

L'azienda in cui lavoro mi mette a disposizone un AI engine (che non nominerò ma che indicherò con AI name) e io cerco di sfruttarlo.

INCISO: Per tutti gli smanettoni che leggendo il mio post mi suggeriranno "Ma perchè non usi lo strumento A... e non provi l'agente B...", preciso che io posso usare solo strumenti autorizzati dall'azienda. Perchè la conformità legale e la sicurezza vengono prima di qualsiasi considerazione tecnica.

Tenete presente che io scrivo documentazione tecnica DIRETTAMENTE in lingua Inglese dal 2008.

Ovviamente il mio Inglese nel 2008 era... diciamo così... grezzo... e sono indulgente con me stesso.

Oggi è molto migliorato, ma posso commettere ancora errori, perchè non sono un English native speaker.

Per questo, mi affidavo ad una bravissima collega (ciao Danila!) che mi affiancava ed era preziosa nel migliorare la qualità della documentazione aziendale... perchè 4 occhi vedono meglio di 2 e perchè era veramente in gamba.

Ora che non lavora più con me, devo comunque assicurare un livello adeguato di qualità dei nostri contenuti.

Per questo motivo, da alcune settimane sto sperimentando un prompt, che sto progressivamente affinando. Vediamo la sua struttura generale. 

IL PROMPT

Ci sono N sezioni specifiche, più  una FINAL SECTION.

SCOPE

You must act as an expert editor. You must implement a set of specific checks to improve the linguistic level of the content and the compliance with some rules of style.

ORTOGRAPHIC CORRECTNESS (US English-based)

Main attributes to analyze and check:

• Spelling of words according to US English.
• Typos and terminology inconsistencies
• ... other specification...
• ... other specification...

GRAMMATICAL CORRECTNESS

Main attributes to analyze and check:

• Sentence structure
• Articles, prepositions, verb tenses
• ... other specifications...
• ... other specifications...

REGISTER&NEUTRALITY

Main attributes to analyze and check:

• Neutral and technical register
• ... other specifications...
• ... other specifications...

MICROSOFT STYLE GUIDE compliance

Main attributes to analyze and check:

• General check about Microsoft Style Guide rules. A particular check about:
• Active voice
• ... other specifications...
• ... other specifications...

COMPANY GLOSSARY compliance

Main attributes to analyze and check:

• Verify that contents are coherent with company glossary.
• If the text contains a term that may be synonymous with a term in the company glossary, report the occurrence and suggest replacing it with the glossary term.
• ... other specifications...
• ... other specifications...

SECTION ... K...

Main attributes to analyze and check:

• ... other specifications...
• ... other specifications...

SECTION ... K+1...

Main attributes to analyze and check:

• ... other specifications...
• ... other specifications...

SECTION ... N...

Main attributes to analyze and check:

• ... other specifications...
• ... other specifications...

FINAL SECTION

In this section is specified a set of rules that you (AI name) MUST COMPLY WITH . These rules are like "guard-rails" to limit your normal and structural inclination to hallucinate.

Rule 1: Don't ignore the instructions specified in the previous N sections.

Rule 2: Don't modify the source document but provide me a report with your proposal

Rule 3: I want a report for every specific section

Rule 4: The format of the report is: ... blablabla...

Rule 4: ...blablabla...

Rule 5: ...blablabla...

...

Rule N: You cannot ignore any of the previous rules.

----

Come vedete, non vi ho spifferato tutte le specifiche di ogni sezione (solo le principali) ma non perchè dovessi custodire chissà quali segreti. Semplicemente, perchè quel che conta è la struttura. Poi ognuno la può configurare come meglio crede per i propri bisogni.

IL PROCESSO

Quando devo avviare il controllo di qualità, io fornisco alla AI name:

• Il prompt
• Il documento da verificare

Dopo pochi secondi ottengo N report, uno per ogni sezione.

Ovviamente potrei ottenere un unico report onnicomprensivo, ma visto che voglio procedere per raffinamenti successivi, voglio verificare in che modo AI name opera in ogni sezione.

RISULTATI

Come stanno andando le cose? In generale, Danila era più brava.

Aveva una conoscenza completa del contesto e quando decideva di fare una modifica aveva sufficiente competenza per farla in autonomia, a meno di casi dubbi in cui si consultava con me.

Danila era intelligente (veramente) quindi non ragionava a "sezioni": il suo cervello e la sua preparazione professionale le consentivano di operare più controlli in parallelo, in modo fluido, senza il bisogno di definire una sequenza particolare, con attributi specifici.

Danila non aveva bisogno di essere istruita sul tono e sul registro, sul fatto di scrivere testi in active voice, sul fatto che il testo doveva essere conforme allo US English, perchè era una professionista esperta.

Ovviamente, AI name non è intelligente... ma è più veloce.

Lavorando per raffinamenti successivi, sto ottenenedo risultati sempre più affidabili.

Nonostante la sezione delle regole, ogni tanto aggiunge cose che non sono desumibili dal testo.

Bisogna controllare sezione per sezione, non si può assorbire il suo output in maniera automatica.

A volte suggerisce forme idiomatiche più eleganti del mio Inglese tecnico.

Ottimo. Ma a volte "si allarga" indebitamente.

Una volta, ha preso una procedura di N passi, dove in ogni passo io specifico UNA ed UNA SOLA AZIONE, attraverso l'uso di UNO ed UN SOLO VERBO. Evidentememte era una procedura spiegata troppo bene, ma un poco lunga e AI name ha provato a sintetizzare in un solo passo 2 o 3 passi distinti.

Lo ha fatto un paio di volte. Sbagliando. Perchè il modo giusto era il mio. Punto. Discorso chiuso.

In quel caso, non ho accettato il suggerimento. 

Ma ho inserito una specifica ulteriore sulle procedure step-by-step.

COME MIGLIORARE IL PROCESSO

Ci sono diversi passaggi. Cito solo i principali.

Automatizzare l'accesso alle pagine di contenuti

Ad oggi, il mio repository di contenuti non è accessibile per la AI name.

Io devo manualmente selezionare il contenuto che devo analizzare e darglielo in pasto.

Questo passo di automazione richiede lavoro extra, che va pianificato.

Iterare sulla struttura del prompt, per migliorare quello che va migliorato.

L'esempio che vi ho fatto sulla procedura step-by-step è emblematico: non basta lamentarsi del fatto che AI name sbaglia, ma bisogna costruire le giuste istruzioni per costringerla (entro certi limiti...) a non sbagliare. Questo si fa con un prompt che ha una struttura modulare, dove in ogni modulo (sezione) posso aggiungere specifiche iterativamente.

Definire un agent che sia in grado di modificare i contenuti in autonomia, dopo il mio nulla osta.

Questo è lo step più complesso.

Intanto va risolto il primo punto, cioè l'accesso al repository dei contenuti.

Che deve essere gestito in modo "sicuro", tanto più se si tratta di accedere in scrittura.

Poi ci sono tutta una serie di vincoli.

Ad esempio, quando scrivo un testo che verrà pubblicato nella documentazione aziendale, utilizzo un CSS (Cascading Style Sheet).

Attraverso di esso, contenuti "tipologicamente diversi" vengono "renderizzati" con stili diversi. Tali stili sono specificati nel CSS. Quindi l'agent dovrebbe accedere al CSS e avere la capacità di "riconoscere" lo stile del testo da modificare per mantenere lo stesso stile nel testo modificato. Non impossible, ma nemmeno banale.

Come ho spiegato in precedenza, la AI name non si accorge se cambia una GUI ma anche se se ne accorgesse, non riuscirebbe ad associare quel cambiamento ad un cambiamento della logica di business che quella GUI implementa. 

Per esempio, se ad una GUI viene aggiunto un pulsante DELETE, anche se AI name si accorgesse della variazione, non potrebbe sapere a QUALI OGGETTI o PROCESSI si potrebbe applicare l'azione di cancellazione, fra tutti quelli accessibil nella GUI.

Quindi:

1. La logica che coinvolge il nuovo pulsante DELETE la devo scrivere io.
2. Devo accertarmi di aggiornare anche lo screenshot eventualmente presente.

Altrimenti AI name validerebbe un testo (step 1) associato al vecchio screenshot, il che risulterebbe poco comprensibile per il lettore.

Come vedete, non è semplice creare un agent capace di riversare in autonomia le modifiche indicate nei report; in alcuni casi, non è possibile. Talvolta, non è nemmeno desiderabile. E comunque, io non rinuncio al mio potere di controllo. Perchè mi fido di me.

Alla prossima, con un nuovo capitolo su "Come uso l'AI".

Auspico il dibattito. Fatevi avanti!

Leggi questo articolo...

25 anni (circa…) di DITA

Per chi non lo sapesse, DITA è l’acronimo di Darwin Information Typing Architecture.

E compie (circa...) 25 anni.

Perchè è importante saperlo? Perchè nell’epoca dell’AI generativa abbiamo già superato la fase dello "spaesato" che arriva e ti dice “butta tutti i documenti aziendali nel macinino dell’AI che tanto ci pensa lei...” e ci stiamo accorgendo che i dati DOVREBBERO ESSERE taggati e strutturati, prima di darli in pasto ad un RAG.

E DITA serve esattamente a questo e lo fa veramente bene da 25 anni, tanto da essere ormai lo standard per la documentazione tecnica più diffuso nel mondo, nei più diversi settori industriali.

Ma quando è inziata questa storia? Provo a riassumere rapidamente, con ordine e sintesi.

Tutti più o meno sanno che DITA nasce in IBM. Ma non è stato un parto indolore.

Tutto iniziò con GML (siamo nei primi anni ’80 del secolo scorso), la cui evoluzione fu SGML (Standard Generalized Markup Language).

Uno dei protagonisti dello sviluppo di SGML fu Elliot Kimber, che ebbi la fortuna di conoscere nel 2015 a Stoccarda, nell'ambito di tcworld.

Dalla comunità che sviluppava SGML, nacque XML (eXtensible Markup Language) e nel 1997 viene presentato XML 1.0.

Il primo parser XML fu realizzato dal laboratorio Watson, ma IBM in quel momento puntava ancora su un DTD SGML denominato WebDoc.

Più o meno negli stessi anni, un altro gruppo di lavoro era partito dall’idea di standardizzare la documentazione prodotta da Unix MAN e questo lavoro portò allo sviluppo di DocBook, anch’esso derivato da SGML.

DocBook ebbe una certa diffusione fino ai primi anni di questo secolo, essendo stato adottato per diversi progetti importanti della comunità Open Source. Poi sembrò essere avviato al viale del tramonto. 

E’ uno standard che ho investigato per pochi mesi, quando lavoravo in Engineering e mi è sembrò fin da subito estremamente rigido e povero.

Ma poi venne Paligo, uno dei CCMS attualmente più interessanti sul mercato. Paligo utilizza DocBook e questo ha dato nuova linfa a questo standard. In questo link potete analizzare un confronto fra DocBook e DITA, dal punto di vista di Paligo.

Io non condivido l'opinione di Paligo, ma proprio per questo vi propongo un punto di vista diverso dal mio.

Tuttavia, la storia e la tecnologia di solito non fanno sconti a nessuno. Chi vince, vince perchè deve vincere. E in IBM la battaglia tra SGML ed XML fu vinta da XML.

Tra i protaginisti della svolta ci furono Michael Iantosca, Don Day e Michael Priestly.

Vinse l’approccio topic-based perchè:

• riduceva la duplicazione dei contenuti e favoriva il riuso degli stessi
• abilitava la pubblicazione multicanale
• facilitava aggiornamenti centralizzati
• consentiva la specializzazione controllata dei contenuti
• abbatteva potentemente i costi di traduzione dei contenuti
• favoriva l’uniformità stilistica della documentazione

Stava per nascere DITA, uno standard aperto che stava per trasformare lo sviluppo della documentazione di prodotto. E DITA ha prima trasformato IBM e poi il resto del mondo.

Nel 2001 IBM creò il DITA Open Toolkit, il primo strumento per definire un processo di pubblicazione della documentazione tecnica basata su DITA.

Nel 2005 IBM donò ufficialmente DITA a OASIS.

E da quel momeno DITA fu adottato nel mondo del software, dell’elettronica, della finanza, della sanità, e in molti altri ancora.

DITA l'ho usato per 4 anni quando lavoravo in IBM.

Su DITA in questo blog ho scritto diversi articoli, tra cui:

• Dalla scrittura monolitica alla scrittura modulare: DITA overview (dal blog di Petra Dal Santo)
• Dal "monolite" ai "moduli" ... con DITA: Task Topic
• tcworld2015 in 3 parole: integrazione, CCMS, standardizzazione
• A che punto siamo con DITA?

... ed altri che trovate nella sezione DITA (sulla spalla destra).

Sono stato anche speaker dell'evento Adobe DITAWORLD 2018, dove ho spiegato chiaramente come sia del tutto falso il famoso problema della "difficile curva d'apprendimento" di DITA, unico vero argomento dei detrattori di questo standard.

Ma oggi il punto è: abbiamo messo la testa sul fatto che se vogliamo sfruttare al meglio le potenzialità che ci offre l'AI generativa, dobbiamo organizzare i nostri contenuti in un certo modo? 

Se la risposta è SI, abbiamo diverse possibilità, come ho recentemente sottolineato qui.

Ma DITA, probabilmente, è la migliore. Forse non per tutti. Ma la migliore, di sicuro.

P.S. 

Chi vi racconta che lo standard proprietario TizioCaio esisteva prima di DITA, è meglio di DITA, è più utlizzato di DITA e vi vuole vendere consulenza sullo standard TizioCaio... vi sta raccontando fregnacce. 

Non siete obbligati ad usare DITA per scrivere la vostra documentazione, ma dovete conoscere l'origine delle cose e se uno standard è il più utilizzato al mondo... ci sarà un motivo.

Leggi questo articolo...

Cara AI, ma sei sicura che mi puoi sostituire? Cosa NON PUO' FARE l'AI - Parte 2.

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:

1. Parlare con il Product Manager per capire la logica di business.
2. Parlare con gli sviluppatori per capire la logica della GUI.
3. Usare in autonomia la GUI e capire i flussi operativi fondamentali da documentare.
4. 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.

Leggi questo articolo...