Gli script Oracle SQL generati da agenti basati su modelli linguistici di grandi dimensioni (LLM) possono sembrare impeccabili sulla carta eppure causare disastri in produzione. In un codice legacy di 2,3 milioni di righe, un agente basato su IA inseriva regolarmente identificatori inesistenti – ad esempio, usando POLICY_STATUS invece della colonna reale STATUS_CD, o facendo riferimento a una tabella CUSTOMERS inesistente invece di CUSTOMER.

Eseguire lo script per individuare l'errore di battitura non è un'opzione per le istruzioni UPDATE o DELETE. Eseguirle su un set di dati simile a quello di produzione acquisisce lock, consuma numeri di sequenza e può innescare effetti collaterali a cascata. Gli sviluppatori hanno bisogno di un modo per validare nomi e sintassi senza toccare alcun dato. La risposta, sorprendentemente semplice, è il comando EXPLAIN PLAN di Oracle, riutilizzato come fase di linting.

Come funziona EXPLAIN PLAN come validatore rapido

Quando Oracle riceve un'istruzione, la analizza (parsing) innanzitutto. Il parsing verifica che ogni tabella, colonna e privilegio referenziato esista, quindi costruisce un piano di esecuzione e scrive tale piano in una tabella di sistema. Il comando non esegue mai l'istruzione: nessuna riga viene modificata, nessun trigger viene attivato, nessun lock viene acquisito. Se il parser incontra un oggetto sconosciuto, restituisce un errore in pochi millisecondi.

Questo comportamento rende EXPLAIN PLAN un controllo pre-volo perfetto per l'SQL generato dall'IA. Una tabella o una colonna mancante viene segnalata istantaneamente, permettendo al ciclo di generazione di correggere l'errore prima che un essere umano veda lo script.

Il workflow che ho integrato nella mia pipeline di CI

  1. Dividere lo script in entrata in singole istruzioni.
  2. Eseguire EXPLAIN PLAN FOR <statement> contro uno schema di sviluppo.
  3. Raccogliere eventuali errori di parsing restituiti da Oracle.
  4. Inviare gli errori all'LLM per un nuovo tentativo.

In pratica, un singolo tentativo risolve la maggior parte degli errori di denominazione. L'IA impara lo schema corretto e adatta il proprio output automaticamente. Ho inoltre bloccato l'agente in modalità sola lettura: può emettere SELECT e chiamate EXPLAIN PLAN, ma DDL, DML e COMMIT sono bloccati. Questa sandbox garantisce che il database rimanga intatto mentre l'IA ne sonda la struttura.

Oltre ai controlli sui nomi, il piano generato rivela evidenti segnali di allarme sulle prestazioni. Se un'istruzione dovesse innescare una scansione completa della tabella (full-table scan) su una tabella massiccia, il piano lo mostra prima che qualsiasi riga venga toccata, dando agli sviluppatori la possibilità di suggerire indici o riscrivere il predicato.

Limiti dell'approccio

  • La correttezza logica non è verificata. Un'istruzione che referenzia le colonne giuste ma applica il filtro errato supera comunque il linting.
  • I blocchi PL/SQL sono fuori ambito. Il parser gestisce solo singole istruzioni SQL; il codice procedurale richiede un percorso di validazione separato.
  • Manca la validazione a livello di dati. Il lint non può dirti se un valore letterale è conforme al dominio di una colonna o se un riferimento di chiave esterna esiste effettivamente.
  • Solo schema di sviluppo. Gli errori che compaiono solo in produzione – ad esempio, una tabella che esiste in dev ma viene rinominata in prod – rimangono invisibili fino a un momento successivo.

Queste lacune non diminuiscono l'utilità del metodo; ne definiscono semplicemente il perimetro. Per la maggior parte degli script DML generati da LLM, la modalità di errore più comune è un errore di battitura o un nome di oggetto errato, ed è esattamente ciò che EXPLAIN PLAN intercetta.

Portabilità verso altri motori di database

Lo stesso principio si applica oltre Oracle. L'istruzione PREPARE di PostgreSQL o EXPLAIN possono analizzare una query senza eseguirla. SQL Server offre SET PARSEONLY ON, che forza il motore a validare la sintassi e i nomi degli oggetti saltando l'elaborazione effettiva. Qualsiasi RDBMS che separi il parsing dall'esecuzione può diventare un gate di linting leggero.

In sintesi

Eseguire EXPLAIN PLAN (o il suo equivalente) su ogni istruzione SQL generata dall'IA trasforma un parser di database in un gate di linting economico e a rischio zero. Intercetta gli errori di denominazione e di sintassi più frequenti prima che qualsiasi dato venga spostato, mantenendo stabili i sistemi legacy e permettendo agli sviluppatori di beneficiare dell'aumento di produttività della codifica assistita da LLM.