Büyük dil modeli (LLM) ajanları tarafından üretilen Oracle SQL betikleri kağıt üzerinde kusursuz görünebilir ancak üretim ortamında patlayabilir. 2,3 milyon satırlık eski bir kod tabanında, yapay zeka destekli bir ajan, sürekli olarak var olmayan tanımlayıcılar sızdırıyordu; örneğin, gerçek STATUS_CD sütunu yerine POLICY_STATUS kullanmak veya CUSTOMER yerine var olmayan bir CUSTOMERS tablosuna atıfta bulunmak gibi.

Yazım hatasını yakalamak için betiği çalıştırmak, UPDATE veya DELETE ifadeleri için bir seçenek değildir. Bunları üretim ortamına benzer bir veri setinde çalıştırmak kilitler oluşturur, sıra numaralarını tüketir ve zincirleme yan etkilere neden olabilir. Geliştiricilerin, herhangi bir veriye dokunmadan isimleri ve söz dizimini (syntax) doğrulamanın bir yoluna ihtiyacı vardır. Şaşırtıcı derecede basit olan cevap, Oracle'ın bir linting adımı olarak yeniden amaçlandırılan EXPLAIN PLAN komutudur.

EXPLAIN PLAN hızlı bir doğrulayıcı olarak nasıl çalışır

Oracle bir ifade aldığında, önce onu ayrıştırır (parse eder). Ayrıştırma işlemi, başvurulan her tablonun, sütunun ve yetkinin mevcut olup olmadığını kontrol eder, ardından bir yürütme planı oluşturur ve bu planı bir sistem tablosuna yazar. Komut ifadeyi asla çalıştırmaz: hiçbir satır değiştirilmez, hiçbir tetikleyici (trigger) çalışmaz, hiçbir kilit alınmaz. Ayrıştırıcı bilinmeyen bir nesneyle karşılaşırsa, birkaç milisaniye içinde bir hata fırlatır.

Bu davranış, EXPLAIN PLAN komutunu yapay zeka tarafından üretilen SQL için mükemmel bir uçuş öncesi kontrolü haline getirir. Eksik bir tablo veya sütun anında raporlanır, böylece üretim döngüsü, bir insan betiği görmeden önce hatayı düzeltebilir.

CI hattıma entegre ettiğim iş akışı

  1. Gelen betiği tekil ifadelere ayırın.
  2. Bir geliştirme şemasına karşı EXPLAIN PLAN FOR <statement> komutunu çalıştırın.
  3. Oracle'ın döndürdüğü tüm ayrıştırma hatalarını toplayın.
  4. Hataları yeniden deneme için LLM'e geri besleyin.

Uygulamada, tek bir yeniden deneme isimlendirme hatalarının çoğunu giderir. Yapay zeka doğru şemayı öğrenir ve çıktısını otomatik olarak ayarlar. Ayrıca ajanı salt okunur (read-only) moda kilitliyorum: SELECT ve EXPLAIN PLAN çağrıları yapabilir ancak DDL, DML ve COMMIT engellenir. Bu kum havuzu (sandbox), yapay zeka yapısını incelerken veritabanının dokunulmaz kalmasını garanti eder.

İsim kontrollerinin ötesinde, üretilen plan bariz performans uyarılarını (red flags) ortaya çıkarır. Eğer bir ifade devasa bir tabloda tam tablo taramasına (full-table scan) neden olacaksa, plan bunu herhangi bir satıra dokunulmadan önce gösterir ve geliştiricilere indeks önerme veya koşulu (predicate) yeniden yazma şansı verir.

Yaklaşımın sınırları

  • Mantıksal doğruluk doğrulanmaz. Doğru sütunlara atıfta bulunan ancak yanlış filtre uygulayan bir ifade lint testinden geçer.
  • PL/SQL blokları kapsam dışıdır. Ayrıştırıcı yalnızca tekil SQL ifadelerini işler; prosedürel kod ayrı bir doğrulama yolu gerektirir.
  • Veri düzeyinde doğrulama eksiktir. Lint, bir sabit değerin (literal value) bir sütunun alanına (domain) uygun olup olmadığını veya bir yabancı anahtar (foreign-key) referansının gerçekten var olup olmadığını söyleyemez.
  • Yalnızca geliştirme (dev) şeması. Sadece üretim ortamında görünen hatalar —örneğin, dev ortamında var olan ancak prod ortamında yeniden adlandırılan bir tablo— daha sonrasına kadar görünmez kalır.

Bu boşluklar yöntemin faydasını azaltmaz; sadece sınırlarını belirler. Çoğu LLM tarafından üretilen DML betiği için en yaygın hata modu bir yazım hatası veya yanlış nesne adıdır ve EXPLAIN PLAN tam olarak bunu yakalar.

Diğer veritabanı motorlarına taşınabilirlik

Aynı ilke Oracle'ın ötesinde de geçerlidir. PostgreSQL'in PREPARE ifadesi veya EXPLAIN komutu, bir sorguyu çalıştırmadan ayrıştırabilir. SQL Server, motoru gerçek işlemi atlayarak söz dizimini ve nesne adlarını doğrulamaya zorlayan SET PARSEONLY ON seçeneğini sunar. Ayrıştırmayı yürütmeden ayıran herhangi bir RDBMS, hafif bir linting kapısı haline gelebilir.

Sonuç

Her yapay zeka tarafından üretilen SQL ifadesinde EXPLAIN PLAN (veya eşdeğerini) çalıştırmak, bir veritabanı ayrıştırıcısını düşük maliyetli, sıfır riskli bir linting kapısına dönüştürür. En sık karşılaşılan isimlendirme ve söz dizimi hatalarını herhangi bir veri hareket etmeden yakalar; böylece geliştiricilerin LLM destekli kodlamanın verimlilik artışından yararlanmasını sağlarken eski sistemleri kararlı tutar.