Per decenni, SQL è stato il linguaggio universale con cui le organizzazioni interrogano i propri dati. Semplice nella sintassi di base, potente nella sua espressività, SQL ha resistito a ogni ondata tecnologica — dai database relazionali degli anni ’80 ai data warehouse moderni — rimanendo lo strumento fondamentale con cui sviluppatori, analisti e sistemi di ogni tipo accedono alle informazioni strutturate.
Non sorprende, quindi, che quando l’intelligenza artificiale generativa ha iniziato a trasformare lo sviluppo software, SQL sia diventato uno dei primi terreni di sperimentazione. La promessa era allettante: agenti AI capaci di rispondere a domande in linguaggio naturale traducendole automaticamente in query SQL, eliminando la barriera tecnica tra chi ha una domanda e chi sa come estrarla dal database.
Il problema che nessuno aveva previsto
In teoria funziona. In pratica, qualcosa va storto.
Gli agenti AI moderni — inclusi i più sofisticati come Claude — sono effettivamente bravi a scrivere SQL sintatticamente corretto. Riescono a costruire join complessi, aggregazioni articolate, subquery ben formate. Il problema non è la grammatica. Il problema è il significato.
Un agente che non conosce il tuo dominio non sa che la colonna status nella tabella orders ha valori che seguono una logica di business specifica. Non sa che certi campi sono deprecati e non dovrebbero essere usati nelle analisi correnti. Non sa che due tabelle apparentemente simili rappresentano concetti radicalmente diversi nel contesto della tua organizzazione. Il risultato? Query tecnicamente impeccabili che restituiscono risposte sbagliate. E un agente che, di fronte all’ambiguità, non chiede chiarimenti: indovina.
È esattamente il problema che emerge nelle organizzazioni che provano a costruire analisti AI su database reali e complessi. Lo strumento sembra funzionare nei demo, poi fallisce in produzione — non con errori evidenti, ma con risposte plausibili e scorrette, che sono la forma più pericolosa di errore.
La soluzione: dare all’agente una mappa del territorio
La diagnosi, come spiega Kris Jenkins, è chiara: l’agente conosce la sintassi SQL, ma non conosce il tuo software. È come assumere un esperto di grammatica italiana e aspettarsi che sappia come funziona la tua azienda.
La soluzione è altrettanto chiara: bisogna insegnargli il dominio. Non attraverso prompt improvvisati o lunghe istruzioni informali, ma attraverso uno strumento strutturato — il semantic model. Un file che codifica tutto il sapere tacito che un nuovo hire esperto accumulerebbe nei primi sei mesi: come si relazionano le tabelle, cosa significano davvero i nomi delle colonne, quali tipi di query hanno senso, quali pattern sono corretti e quali andrebbero evitati.
È la differenza tra consegnare a qualcuno una mappa dettagliata del territorio e lasciarlo esplorare a caso sperando che trovi la strada giusta.
Nel suo talk a Codemotion Roma 2026, Jenkins — Lead Developer Advocate per Snowflake e host del podcast Developer Voices, con una carriera che lo ha portato ad essere CTO di una società di trading aurifero, contractor specializzato in Haskell e organizzatore di hackathon — guiderà il pubblico attraverso i dettagli pratici dei semantic model e dello standard OSI. Spiegherà perché la standardizzazione in questo ambito è fondamentale per la scalabilità, e mostrerà tecniche concrete per costruire semantic model efficaci in tempi rapidi.
L’obiettivo finale è tanto semplice quanto ambizioso: un database analyst basato su AI che sia affidabile ed efficace fin dal primo giorno — non dopo mesi di aggiustamenti e prompt engineering.
Vieni a scoprirlo di persona.Il talk “Beyond SQL Generation: How to Teach Agents What Your Database Means” di Kris Jenkins è in programma a Codemotion Roma 2026. Se lavori con agenti AI, dati e database, è un appuntamento da non perdere.
