Anton Onufriienko, Managing Director at Devart – Intervista

Anton Onufriienko, Managing Director at Devart, è un dirigente tecnologico e operativo con una profonda esperienza nella gestione di aziende software, nella crescita dei ricavi e nella gestione di grandi team cross-funzionali nel settore SaaS, software aziendale e servizi finanziari. Nel corso della sua carriera, è passato dal costruire organizzazioni di vendita e lanciare startup alla supervisione di operazioni P&L complete per importanti unità aziendali, tra cui la più grande divisione di Devart con oltre 130 dipendenti. Prima di diventare Managing Director, ha ricoperto il ruolo di Chief Revenue Officer e Head of Sales di Devart, dove ha guidato la strategia di go-to-market, la trasformazione dei prezzi e le iniziative di crescita internazionale. È anche CEO di TMetric, una piattaforma di tracciamento del tempo e di profitto che aiuta le aziende a servizio a ottenere chiarezza operativa.

Devart è un’azienda di software specializzata nello sviluppo di database, nella connettività dei dati, nell’integrazione e negli strumenti di produttività per sviluppatori, DBA, analisti e team aziendali. Fondata nel 1997, l’azienda è nota per la sua suite di strumenti di gestione del database dbForge, che supporta i principali sistemi di database, tra cui SQL Server, MySQL, Oracle (ORCL ) e PostgreSQL. Devart sviluppa anche soluzioni di connettività dei dati come ODBC, ADO.NET, Python e Delphi, oltre a Skyvia, la sua piattaforma di integrazione dei dati basata su cloud per ETL, automazione, backup e orchestrazione del flusso di lavoro. L’azienda serve oltre 500.000 utenti in tutto il mondo, tra cui una grande quota di organizzazioni Fortune 100, e si è concentrata sempre più sull’integrazione di funzionalità basate sull’intelligenza artificiale nei suoi prodotti, come ad esempio dbForge AI Assistant, che aiuta gli sviluppatori a generare, ottimizzare, risolvere problemi e spiegare query SQL utilizzando il linguaggio naturale.

Ha percorso un cammino che lo ha portato a costruire e guidare team di vendita, a gestire operazioni P&L complete e ora a gestire la più grande unità aziendale di Devart. Come questo percorso ha plasmato il suo approccio all’integrazione dell’intelligenza artificiale nella strategia e nella decisione aziendale su larga scala?

Le vendite mi hanno insegnato a misurare il ROI su tutto. Passando a un ruolo di CRO, ho esteso questa disciplina a tutte le funzioni. La gestione della BU mi ha costretto ad applicarla all’intelligenza artificiale stessa.

Ho una visione pratica dell’intelligenza artificiale. Non sono scettico: tre delle nostre quattro scommesse sui prodotti per il 2026 sono native per l’intelligenza artificiale. Ma credo che l’iperiallo si frappone tra i risultati reali e duraturi.

C’è un meme in circolazione che riassume dove l’industria spesso sbaglia. Le aziende sostituiscono abbonamenti SaaS da 400 dollari con strumenti fatti in casa che costano 1.000 dollari al mese in spese per API e richiedono costanti riparazioni. Non è un vero cambiamento, è solo uno spettacolo costoso.

La lezione che ho appreso dalle vendite è semplice: ogni iniziativa paga il suo modo, altrimenti muore. Gestisco il rollout dell’intelligenza artificiale nello stesso modo in cui gestivo un territorio di vendita. Ipotesi di ROI esplicita per flusso di lavoro, rollout in tre fasi e impatto documentato prima di scalare.

Il nostro obiettivo principale è il Ricavo per Dipendente, e il nostro obiettivo è raddoppiare entro la fine del 2028. Non si chiude quel divario assumendo personale. Si chiude cambiando il modo in cui si lavora, e l’intelligenza artificiale è l’unico meccanismo realistico a quella portata.

Il mio filtro per ogni iniziativa di intelligenza artificiale, interna o di prodotto, è lo stesso: qual è il valore misurato, chi paga per esso e come sappiamo che ha funzionato? Tutto ciò che non supera quelle tre domande non appartiene alla produzione. Il costo di sbagliare si accumula rapidamente, e la maggior parte delle aziende scoprirà che in modo costoso.

Devart ha costruito una solida reputazione attorno agli strumenti di database e alla produttività degli sviluppatori. Come sta integrando l’intelligenza artificiale in questi prodotti per offrire un valore reale anziché un’automazione di superficie?

I nostri utenti sono specialisti tecnici di alto livello: DBA, ingegneri senior, architetti di dati. Rilevano l’automazione di superficie in pochi secondi e si risentono se vengono venduti giocattoli di marketing travestiti da innovazione. Due anni fa, quando l’iperiallo dell’intelligenza artificiale ha raggiunto il picco e i concorrenti hanno gareggiato per aggiungere pannelli di chat a ogni elemento dell’interfaccia utente, la tentazione di seguire era reale. Avevo visto quel modello prima, nel mobile, nel cloud, nel low-code, e mi sono rifiutato di ripeterlo.

La disciplina era semplice: valore per il cliente per primo. Costruire funzionalità di intelligenza artificiale che nessuno ha chiesto, che non offrono un valore reale, è il peggiore utilizzo possibile delle risorse di ingegneria finite. È particolarmente vero quando il tuo pubblico può rilevare la differenza immediatamente.

Ciò che è cambiato nel 2026 è che l’intelligenza artificiale è passata dall’iperiallo a una vera rivoluzione tecnica. Il divario tra ciò che questi sistemi potevano fare nel 2023 e ciò che possono fare oggi non è incrementale. È una categoria di capacità completamente diversa. Possiamo ora risolvere problemi che erano veramente insolubili in precedenza: accesso sicuro ai dati aziendali per gli agenti di intelligenza artificiale, intelligenza del database contestuale all’interno dell’IDE dello sviluppatore e analisi aziendali autonome che non richiedono un analista dedicato.

Questi sono nuove linee di prodotto che esistono perché l’intelligenza artificiale ha reso solvibile il problema di base. È il livello che ci poniamo: un prodotto di intelligenza artificiale reale è uno in cui la rimozione dello strato di intelligenza artificiale rompe il prodotto. L’industria ha trascorso due anni a chiamare i pannelli di chat “prodotti di intelligenza artificiale”. Quelli sono funzionalità, non prodotti.

Abbiamo impiegato più tempo perché volevamo fare le cose per bene. I prossimi dodici mesi mostreranno se quella disciplina ha pagato.

L’intelligenza artificiale sta sempre più scrivendo, ottimizzando e debuggando il codice. Come questo cambierà il ruolo degli sviluppatori che lavorano con i database nei prossimi anni?

Il valore di conoscere la sintassi SQL sta svalutandosi rapidamente. Se l’intelligenza artificiale può generare una JOIN multi-tabelle complessa in pochi secondi e identificare gli indici mancanti dai log in pochi minuti, il valore di un ingegnere non deriva più dalla digitazione di SQL. Quella parte del lavoro sta diventando una commodity.

Ma ecco la sfumatura critica che gli evangelisti della totale automazione sempre saltano. Un errore dell’intelligenza artificiale sul frontend è un pulsante non allineato che si aggiorna. Un errore dell’intelligenza artificiale sul database è un ambiente di produzione cancellato, una violazione della protezione dei dati o un arresto transazionale dell’intera attività.

I database contengono stato. Non perdonano le allucinazioni.

Quell’asimmetria ridefinisce il ruolo completamente. Nei prossimi due o tre anni, gli sviluppatori di database e i DBA evolveranno da sviluppatori a architetti e revisori. Il loro lavoro principale si sposta su tre cose:

• Progettazione di architetture affidabili che l’intelligenza artificiale non può ragionare da sola, perché le manca il contesto aziendale.
• Definizione di limiti di sicurezza rigidi e politiche di sicurezza per gli agenti di intelligenza artificiale che toccano i sistemi di produzione.
• Revisione e controllo del codice generato dalle macchine prima che raggiunga il database.

Il modello mentale a cui continuo a tornare: gli ingegneri gestiranno eserciti di assistenti di intelligenza artificiale. Gli strumenti come dbForge dovranno evolversi da IDE tradizionali a centri di comando e controllo. Il lavoro diventa meno scrivere SQL manualmente e più recensire ciò che l’intelligenza artificiale genera, validarla e far rispettare i limiti che l’intelligenza artificiale non può superare in sicurezza.

L’opportunità professionale qui è significativa. Gli sviluppatori che migliorano le proprie competenze in architettura e controllo moltiplicheranno il proprio valore sul mercato. Diventeranno lo strato indispensabile tra la produttività dell’intelligenza artificiale e la sicurezza della produzione. Il premio sull’esperienza del database non scompare; si sposta verso l’alto, verso la progettazione, la governance e il giudizio, che è esattamente dove l’intelligenza artificiale non può operare da sola.

Quali sono i limiti più grandi degli strumenti di intelligenza artificiale attuali nella gestione dei database e dove si vedranno i progressi più significativi?

Gli strumenti di intelligenza artificiale attuali sono ancora bloccati nell’automazione di superficie. Generare una query SELECT di base o del codice boilerplate non è più impressionante. Il problema più grande è che la maggior parte dei sistemi di intelligenza artificiale si comporta ancora come dattilografi ciechi invece che come architetti di sistema. Possono generare la sintassi, ma non capiscono veramente l’ambiente in cui operano. Il vero progresso si verifica quando l’intelligenza artificiale inizia a ragionare sul contesto, le dipendenze, lo stato e la logica aziendale insieme.

Attualmente, vedo tre limiti principali che bloccano l’intelligenza artificiale negli ambienti dei database.

In primo luogo, c’è il problema del contesto. I grandi modelli linguistici possono vedere schemi, DDL e nomi di colonne, ma non capiscono veramente i piani di esecuzione, la frammentazione degli indici, i modelli di distribuzione dei dati o la logica aziendale dietro i dati. Senza quella comprensione più profonda, molti consigli di ottimizzazione diventano indovinelli statistici travestiti da competenza.

In secondo luogo, c’è il problema dell’allucinazione, e le aziende hanno quasi zero tolleranza per questo al livello del database. Un JOIN allucinato può rallentare i sistemi di produzione. Un UPDATE errato può cancellare record critici. A quel livello, anche piccoli errori di accuratezza diventano estremamente costosi molto rapidamente.

Il terzo problema è la sicurezza e la governance. Nessuna azienda seria inserirà schemi di produzione o informazioni personali in uno strumento di intelligenza artificiale pubblico senza forti garanzie sulla separazione dei dati e il controllo. Finché i vendor non risolvono questo problema in modo appropriato, l’adozione dell’intelligenza artificiale nelle industrie regolamentate rimarrà limitata.

I progressi significativi si verificheranno quando l’intelligenza artificiale andrà oltre la generazione della sintassi e inizierà a funzionare più come un architetto di sistema o un analista in background.

Una parte di questo è il livello semantico: passare dai nomi di tabella grezzi al significato aziendale reale. Non solo “tabella_utenti”, ma capire concetti come cohorti di clienti, rischio di abbandono, o tendenze di LTV del terzo trimestre.

Un altro spostamento è l’intelligenza artificiale che agisce più come un DBA senior in background. Analizza continuamente i carichi di lavoro, identifica i colli di bottiglia, suggerisce indici, rileva query a rischio e coglie i problemi prima che i sistemi falliscano.

Poi ci sono le operazioni macchina-macchina, dove gli agenti autonomi monitorano il carico del database, testano strategie di ottimizzazione in ambienti isolati e distribuiscono miglioramenti sotto la supervisione umana.

Questi sono gli sviluppi che plasmeranno i prossimi cinque anni di strumenti di database.

Da parte della sua esperienza nella gestione dei ricavi e della strategia di go-to-market, come l’intelligenza artificiale sta ridefinendo i modelli di prezzo, il confezionamento dei prodotti e l’acquisizione dei clienti nelle aziende di software?

Il libro di istruzioni tradizionale di go-to-market è rotto. Lo vediamo nei nostri numeri e in tutta la categoria degli strumenti di sviluppo.

La morte dell’acquisizione classica. Nonostante miglioramenti significativi nei ranking di ricerca tra i nostri prodotti nel 2026, stiamo colpendo la realtà del “zero click”. La ricerca dell’intelligenza artificiale fornisce risposte direttamente nella pagina dei risultati e priva i siti web del traffico. I ranking forti non si traducono più in lead come facevano anche solo due anni fa.

Cinque anni fa, una solida strategia di contenuto era sufficiente per guidare la crescita. Oggi è un requisito minimo. I modelli linguistici grandi pesano la forza del marchio, le menzioni positive e la densità della comunità quando formano risposte. Se il tuo marchio non è visibile e affidabile, i sistemi di intelligenza artificiale smettono di presentarlo in modo coerente. Non perdi solo traffico. Scomparsi completamente dal percorso di acquisto.

Questo spostamento colpisce particolarmente le aziende di strumenti di sviluppo tradizionali. I canali di acquisizione basati sul SEO che hanno finanziato una generazione di SaaS B2B stanno perdendo rapidamente efficienza. Chiunque continui a fare affidamento su di essi come principale leva di crescita deve costruire attivamente alternative proprio adesso: distribuzione dell’ecosistema, comunità e partnership.

L’evoluzione del prezzo: dal numero di posti alla PLG 3.0. Stiamo entrando nella prossima fase della PLG. Il prezzo per posto inizia a rompersi quando un agente di intelligenza artificiale può fare il lavoro di più dipendenti. In quell’ambiente, addebitare in base al numero di dipendenti non ha più senso. Le aziende che non ripacchetteranno i prodotti in base al valore anziché al numero di dipendenti perderanno MRR nei prossimi 24 mesi.

Il passo successivo è la PLG 3.0: il momento in cui un agente di intelligenza artificiale autonomo, e non un essere umano, valuta, testa e acquista software aziendale. L’adozione di massa di quel modello è ancora alcuni anni più in là, ma progettare prodotti e prezzi per l’acquirente macchina è un compito del 2026, non del 2028.

Molte organizzazioni lottano per passare dall’esperimentazione con l’intelligenza artificiale all’impatto reale sulla produzione. Quali sono i fattori chiave che determinano se le iniziative di intelligenza artificiale hanno realmente successo?

La maggior parte delle funzionalità di intelligenza artificiale fallisce prima ancora di essere costruita. Fallisce nella stanza in cui qualcuno dice “abbiamo bisogno di intelligenza artificiale in questo prodotto”, non perché gli utenti l’hanno chiesto, ma perché il consiglio di amministrazione vuole una storia di intelligenza artificiale o il marketing pensa che attirerà un nuovo pubblico. Quello è il peccato originale della maggior parte delle iniziative di intelligenza artificiale, e plasma tutto ciò che segue.

Continuo a vedere gli stessi errori ripetuti nelle aziende che lottano per spostare l’intelligenza artificiale dall’esperimentazione all’impatto reale sulla produzione.

L’errore principale è costruire funzionalità di intelligenza artificiale che nessuno ha realmente chiesto. Una volta che una funzionalità di intelligenza artificiale è stata impostata senza un reale bisogno dell’utente, il team lavora a ritroso dalla tecnologia per inventare un caso d’uso. Il risultato è prevedibile: un pannello di chat fissato a un’interfaccia utente esistente, un’autocompletamento che si mette in mezzo, un pulsante “riassumi” che produce un output peggiore di quello che l’utente avrebbe potuto scrivere da solo. Queste funzionalità vengono spedite, ricevono una comunicazione stampa e sotto-performano silenziosamente ogni previsione di adozione. Il danno più profondo è che consumano la capacità di ingegneria che avrebbe dovuto andare a funzionalità che gli utenti hanno effettivamente richiesto.

Il secondo problema è che i team sottovalutano enormemente la differenza tra dati di demo puliti e dati di produzione reali. Le demo di intelligenza artificiale girano su esempi curati e puliti. La produzione gira sui dati reali dei clienti: duplicati, campi mancanti, dieci modi diversi per scrivere lo stesso nome di prodotto, quindici anni di casi limite di legacy. Un modello che raggiunge un’accuratezza impressionante nella valutazione può degradarsi gravemente sui dati live, e la maggior parte dei team non scopre questo fino a quando gli utenti non si lamentano. Il costo di quella scoperta nella fiducia della produzione è raramente recuperabile.

Un altro punto di fallimento comune è la ricerca degli utenti. Le interviste standard sui prodotti non funzionano per le funzionalità di intelligenza artificiale. Gli utenti non possono articolare cosa vogliono dall’intelligenza artificiale perché non sanno cosa è possibile. Chiedere “userebbe l’intelligenza artificiale per fare X?” ottiene risposte di sì educate che non hanno valore predittivo per l’adozione. La ricerca di prodotti di intelligenza artificiale efficace richiede la presentazione di prototipi, l’osservazione dell’uso reale e la misurazione di se gli utenti tornano dopo che la novità si è esaurita. Pochi team di prodotto hanno ricostruito la loro pratica di ricerca per questo. Stanno ancora eseguendo il playbook del 2019 sui problemi del 2026.

E infine, molte aziende misurano l’attività di intelligenza artificiale invece dell’impatto aziendale. “Duecento persone hanno usato la funzionalità di intelligenza artificiale questa settimana” è un metrica di adozione, non di impatto. L’impatto reale è il tempo di ciclo ridotto, la qualità migliorata, i ricavi generati o i costi rimossi. Se non puoi tracciare una linea retta dalla funzionalità di intelligenza artificiale a un numero nel P&L, non hai un impatto sulla produzione. Hai un’attività costosa.

C’è un quinto fattore che sta diventando sempre più critico e che la maggior parte dei team di prodotto trascura completamente.

La conformità e il percorso di costruzione senza intelligenza artificiale. Una quota significativa degli utenti aziendali nel settore finanziario, sanitario, governativo, difesa e legale operano in base a politiche che proibiscono o limitano le funzionalità di intelligenza artificiale nel software dei fornitori. Se il tuo prodotto accoppia rigidamente l’intelligenza artificiale all’esperienza principale senza un modo per disabilitarla o bypassarla, non espandi il tuo pubblico aggiungendo intelligenza artificiale. Perdi un segmento del tuo pubblico esistente.

Questo è esattamente il problema che stiamo risolvendo con la Connettività dell’Intelligenza Artificiale. I team di conformità nelle industrie regolamentate non si oppongono all’intelligenza artificiale stessa. Si oppongono ai dati che lasciano il loro perimetro. La soluzione non è rimuovere l’intelligenza artificiale; è dare a quelle organizzazioni un’architettura di intelligenza artificiale che si adatti alle loro limitazioni. È il motivo per cui la Connettività dell’Intelligenza Artificiale viene spedita come on-premise: la capacità di intelligenza artificiale rimane, i dati non lasciano mai l’infrastruttura del cliente e l’approvazione di acquisto passa in rassegna al primo giro invece che al terzo.

I team che ottengono questo risultato progettano per la conformità fin dal giorno uno. I team che lo sbagliano scoprono il problema durante la revisione di acquisto, quando l’affare è già perso.

Devart opera su più ecosistemi di database. Come può aiutare l’intelligenza artificiale a semplificare la crescente complessità della gestione dei dati su piattaforme diverse?

Il dolore è reale. Un’azienda Fortune 500 tipica esegue otto a dodici motori di database diversi contemporaneamente: Oracle legacy per le finanze, PostgreSQL per nuovi servizi, SQL Server per le operazioni, Snowflake o BigQuery per l’analisi e sempre più un negozio di vettori per le incorporazioni. Ognuno ha il proprio dialetto, la propria strumentazione, il proprio regime di governance. Uno sviluppatore che si unisce a quell’ambiente può trascorrere tre mesi solo imparando dove si trova i dati e chi è autorizzato a toccarli.

L’intelligenza artificiale non risolve da sola quella complessità. Amplifica qualsiasi contesto le viene dato. Otto database non connessi con nessun metadata unificato producono otto set di suggerimenti superficiali. Quello è esattamente il modello di fallimento che vediamo nella maggior parte dei rollout di intelligenza artificiale aziendale su pile.

L’opportunità è un livello di contesto che si trova tra gli agenti di intelligenza artificiale e i database sottostanti. Uno che parla a tutti, normalizza i metadata, applica politiche di governance unificate ed espone un’interfaccia MCP pulita in modo che qualsiasi agente di intelligenza artificiale, sia Claude, GPT o un modello interno, funzioni in tutta la proprietà con regole coerenti.

Quello è l’architettura che stiamo costruendo con la Connettività dell’Intelligenza Artificiale: un server MCP on-premise con supporto multi-database, un livello semantico che cattura le definizioni aziendali una volta invece di costringere ogni agente di intelligenza artificiale a riscoprirle, controllo di accesso basato su ruolo al livello di operazione SQL e registri di controllo completi.

La semplificazione non è gratuita. Qualcuno deve ancora modellare il livello semantico e impostare le politiche. Ma quel lavoro si fa una volta, non ripetutamente per ogni agente di intelligenza artificiale che si aggiunge.

Ha guidato grandi team cross-funzionali. Come l’intelligenza artificiale sta cambiando la collaborazione interna e la presa di decisioni tra prodotto, ingegneria, marketing e vendite?

La maggior parte dell’attrito cross-funzionale era solo persone in attesa di informazioni da altri team. L’intelligenza artificiale comprime quell’attrito più velocemente di qualsiasi framework di gestione potrebbe mai fare.

Gli spostamenti sono pratici e immediati.

Nel prodotto e nell’ingegneria: un responsabile del prodotto chiede una domanda sul database in termini commerciali chiari, “qual è la varianza di LTV tra i nostri primi tre livelli di prezzo?”, e ottiene una risposta azionabile sul posto, invece di inserire un biglietto Jira all’analisi e aspettare tre giorni.

Nel marketing e nei dati: l’analisi dei cohort si verifica in linea, non attraverso una coda di richieste. Il responsabile del marketing chiede, ottiene i numeri e costruisce la campagna, tutto nella stessa mattina.

Nelle vendite e nell’ingegneria: le risposte tecniche per i potenziali clienti non richiedono più la pianificazione di una chiamata con un ingegnere senior. Il rappresentante delle vendite ottiene una risposta tecnica credibile in tempo reale, e il ciclo di vendita si comprime.

Le decisioni si spostano nella conversazione invece che nel follow-up. Il modello “ti richiamo con quel numero” sta morendo. Le riunioni si riducono perché l’intelligenza artificiale gestisce i pre-letture e le sintesi che un tempo consumavano la prima metà di ogni sessione.

Questo crollo dell’attrito impone uno spostamento di gestione più profondo, ed è quello che la maggior parte dei team di leadership sottovaluta.

Ogni azienda afferma di essere orientata ai risultati. Guarda sotto il cofano e la maggior parte corre ancora su metriche proxy: punti storia, linee di codice, biglietti chiusi, ore lavorate. Abbiamo usato l’attività come proxy del valore perché il valore reale era difficile da misurare. L’intelligenza artificiale rompe quel proxy in modo permanente. Quando un agente può scrivere 10.000 righe di codice o chiudere 500 biglietti di supporto in un minuto, misurare l’attività diventa pericolosamente fuorviante.

Stiamo passando esplicitamente a una gestione basata sui risultati veri, dove le prestazioni sono misurate strettamente dall’esito e dal giudizio. Brutale nella pratica, perché la maggior parte dei sistemi di prestazione non è costruita per questo. Le persone che usavano nascondersi dietro un’alta attività diventano visibili immediatamente, e la leadership deve essere disposta ad agire su quella visibilità.

La conseguenza strutturale è un organigramma più piatto. I livelli di coordinamento e routing delle informazioni si comprimono. Le organizzazioni che si adattano più velocemente opereranno con meno persone a maggiore leveraggio.

Con l’aumento dello sviluppo assistito dall’intelligenza artificiale e degli strumenti senza codice, stiamo andando verso un futuro in cui la gestione dei database diventa accessibile agli utenti non tecnici?

C’è una confusione pericolosa nell’industria in questo momento. Le persone trattano un database di progetto laterale e un database legacy aziendale come se fossero la stessa cosa. Non lo sono.

Per piccoli progetti verdi, la democratizzazione è già qui. Ho personalmente costruito piccole applicazioni da zero senza competenze approfondite di gestione del database. Se tutto il tuo schema si adatta alla finestra di contesto di un modello linguistico grande, l’intelligenza artificiale funziona come magia. Gli sviluppatori di citizen che costruiscono strumenti interni su piccola scala saranno una categoria reale e in crescita.

La realtà aziendale è completamente diversa. I grandi database legacy affrontano lo stesso problema dei grandi codici monolitici: il muro del contesto. Non puoi inserire quindici anni di evoluzione dello schema non documentata, dipendenze cross-database e logica di trigger personalizzata in un prompt. Quando l’intelligenza artificiale perde il contesto su un grande database, le allucinazioni non si degradano in modo gradevole. Si moltiplicano esponenzialmente.

Il rischio che non viene discusso è la falsa sicurezza su larga scala. Le interfacce del linguaggio naturale sono uniche nel produrre risposte che sembrano plausibili ma sono sottilmente sbagliate. Se una query SQL ha un errore di sintassi, ottieni un messaggio di errore. Se un’interfaccia del linguaggio naturale fraintende “clienti attivi” perché i tuoi dati hanno sei definizioni diverse di attività, ottieni un numero. Il numero sembra a posto. Potrebbe essere fuori del 30%. L’utente non ha modo di saperlo.

Quindi no, la gestione dei database aziendali non sta diventando un parco giochi per utenti non tecnici.

Il DBA dei cittadini è un mito su larga scala.

Il futuro appartiene agli architetti di dati esperti che usano strumenti professionali per colmare il divario di contesto e costruire infrastrutture che permettano all’intelligenza artificiale di operare in sicurezza in cima.

La correzione strutturale è il livello semantico: un vocabolario controllato in cui le definizioni aziendali sono fisse e riutilizzate in ogni interazione con l’intelligenza artificiale. È l’architettura centrale che stiamo costruendo in Insightis. Senza di essa, l’accessibilità diventa una responsabilità.

Guardando avanti, cosa assomiglia un set di strumenti di sviluppo “nativo dell’intelligenza artificiale” e come i team dovrebbero iniziare a prepararsi per quel cambiamento oggi?

Un set di strumenti di sviluppo nativo dell’intelligenza artificiale non è un chatbot fissato a un IDE. La maggior parte di ciò che viene commercializzato come “nativo dell’intelligenza artificiale” oggi è un’interfaccia del chat più un modello di autocompletamento. Quello è il minimo, non la destinazione.

Per me, un set di strumenti di sviluppo veramente nativo dell’intelligenza artificiale necessita di tre cose.

In primo luogo, l’intelligenza artificiale necessita di un contesto profondo. Deve capire il tuo codicebase, la tua infrastruttura, le tue decisioni storiche e il tuo ambiente dei dati in modo continuo, non solo attraverso prompt incollati in una finestra di chat. La maggior parte degli strumenti attuali fallisce in questo test. Il loro contesto si azzera con ogni sessione, e l’utente paga il costo di ricostruirlo costantemente.

In secondo luogo, gli strumenti stessi devono comunicare tra loro correttamente. Il tuo IDE deve parlare al tuo database, il database al tuo stack di osservabilità e il tuo CI/CD al tuo revisore di intelligenza artificiale, ecc. Il Protocollo di Contesto del Modello sta diventando lo strato standard qui, con 97 milioni di download di SDK al mese nel primo trimestre del 2026, in aumento rispetto ai 100.000 di fine 2024. Quello è un aumento di 970 volte in quindici mesi e la curva di adozione più ripida che abbia mai visto nell’infrastruttura di sviluppo.

In terzo luogo, la produzione di intelligenza artificiale di livello richiede serie barriere di sicurezza. Anteprima dell’area di distruzione prima delle operazioni distruttive. Analisi delle dipendenze. Piani di rollback automatizzati. Registri di controllo per impostazione predefinita. L’intelligenza artificiale senza queste è buona per i prototipi e pericolosa in produzione.

Come prepararsi, concretamente.

Verifica la tua pila contro quei tre componenti. Ogni strumento espone API e MCP? Parla con gli altri, o siede in un silo? Ha controlli di sicurezza? Gli strumenti che falliscono due dei tre sono attivi a breve termine.

Costruisci l’infrastruttura del contesto oggi. Documenta lo schema, le definizioni aziendali e le decisioni architettoniche in formati leggibili dalle macchine. Un contesto ricco non si costruisce in un trimestre. I team la cui intelligenza artificiale lo ha nel 2027 sono quelli che stanno documentando oggi.

Esegui l’intelligenza artificiale in produzione prima di pensare di essere pronto. I team in attesa di una “strategia di intelligenza artificiale” formale prima di spedire saranno diciotto mesi indietro rispetto ai team che stanno già imparando dai fallimenti reali della produzione. Scegli un caso d’uso a basso rischio. Spediscilo. Costruisci i muscoli.

I team che prendono queste decisioni oggi definiranno il prossimo decennio di come il software viene costruito. La finestra è stretta, ed è aperta proprio adesso.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Devart.