Scripts SQL Oracle gerados por agentes de modelos de linguagem de grande escala (LLM) podem parecer impecáveis no papel e, ainda assim, explodir em produção. Em uma base de código legada de 2,3 milhões de linhas, um agente impulsionado por IA inseria rotineiramente identificadores que não existiam – por exemplo, usando POLICY_STATUS em vez da coluna real STATUS_CD, ou referenciando uma tabela CUSTOMERS inexistente em vez de CUSTOMER.
Executar o script para capturar o erro de digitação não é uma opção para instruções UPDATE ou DELETE. Executá-las em um conjunto de dados semelhante ao de produção adquire locks, consome números de sequência e pode desencadear efeitos colaterais em cascata. Os desenvolvedores precisam de uma maneira de validar nomes e sintaxe sem tocar em nenhum dado. A resposta, surpreendentemente simples, é o comando EXPLAIN PLAN do Oracle – reaproveitado como uma etapa de linting.
Como o EXPLAIN PLAN funciona como um validador rápido
Quando o Oracle recebe uma instrução, ele primeiro a analisa (parsing). O parsing verifica se cada tabela, coluna e privilégio referenciado existe, então constrói um plano de execução e grava esse plano em uma tabela do sistema. O comando nunca executa a instrução: nenhuma linha é modificada, nenhum gatilho (trigger) é disparado, nenhum lock é adquirido. Se o parser encontrar um objeto desconhecido, ele lança um erro em poucos milissegundos.
Esse comportamento torna o EXPLAIN PLAN uma verificação prévia perfeita para SQL gerado por IA. Uma tabela ou coluna ausente é reportada instantaneamente, permitindo que o loop de geração corrija o erro antes mesmo que um humano veja o script.
O fluxo de trabalho que integrei ao meu pipeline de CI
- Dividir o script recebido em instruções individuais.
- Executar
EXPLAIN PLAN FOR <statement>contra um esquema de desenvolvimento. - Coletar quaisquer erros de parsing que o Oracle retornar.
- Enviar os erros de volta para o LLM para uma nova tentativa.
Na prática, uma única tentativa resolve a maioria dos erros de nomenclatura. A IA aprende o esquema correto e ajusta sua saída automaticamente. Eu também travo o agente no modo somente leitura: ele pode emitir SELECTs e chamadas de EXPLAIN PLAN, mas DDL, DML e COMMIT são bloqueados. Esse sandbox garante que o banco de dados permaneça intacto enquanto a IA sonda sua estrutura.
Além das verificações de nome, o plano gerado revela sinais de alerta óbvios de desempenho. Se uma instrução disparar um scan completo de tabela (full-table scan) em uma tabela massiva, o plano mostrará isso antes que qualquer linha seja tocada, dando aos desenvolvedores a chance de sugerir índices ou reescrever o predicado.
Limites da abordagem
- A correção lógica não é verificada. Uma instrução que referencia as colunas corretas, mas aplica o filtro errado, ainda passará pelo lint.
- Blocos PL/SQL estão fora do escopo. O parser lida apenas com instruções SQL individuais; código procedural precisa de um caminho de validação separado.
- Falta validação ao nível de dados. O lint não pode informar se um valor literal está em conformidade com o domínio de uma coluna ou se uma referência de chave estrangeira (foreign-key) realmente existe.
- Apenas esquema de dev. Erros que aparecem apenas em produção – por exemplo, uma tabela que existe em dev mas foi renomeada em prod – permanecem invisíveis até mais tarde.
Essas lacunas não diminuem a utilidade do método; elas simplesmente definem seu perímetro. Para a maioria dos scripts DML gerados por LLM, o modo de falha mais comum é um erro de digitação ou um nome de objeto incorreto, e é exatamente isso que o EXPLAIN PLAN captura.
Portabilidade para outros motores de banco de dados
O mesmo princípio se aplica além do Oracle. A instrução PREPARE ou o EXPLAIN do PostgreSQL podem analisar uma consulta sem execução. O SQL Server oferece o SET PARSEONLY ON, que força o motor a validar a sintaxe e os nomes dos objetos, pulando o processamento real. Qualquer RDBMS que separe o parsing da execução pode se tornar um gate de linting leve.
Resumo
Executar o EXPLAIN PLAN (ou seu equivalente) em cada instrução SQL gerada por IA transforma o parser de um banco de dados em um gate de linting de baixo custo e risco zero. Ele captura os erros de nomenclatura e sintaxe mais frequentes antes que qualquer dado seja movido, mantendo os sistemas legados estáveis enquanto permite que os desenvolvedores colham o aumento de produtividade da codificação assistida por LLM.