LLM’in Yazdığı Kodları Review Etmek Neden Bu Kadar Zor?

LLM'ler görünüşte mükemmel ama içinde kritik hatalar barındıran kod üretiyor. AI tarafından yazılan PR'lar insan koduna göre 1.7 kat daha fazla sorun içerirken, geliştiricilerin %80'i bu kodun daha güvenli olduğuna inanıyor. Bu yanlış güven hissi, production'da pahalıya mal oluyor.

Mükemmellik Tuzağı

Son bir yıldır GitHub Copilot, ChatGPT ve Claude gibi araçlar yazılım geliştirme sürecimizi kökten değiştirdi. Artık boilerplate kod yazmak için saatler harcamıyoruz. Ama bu mucize gibi görünen yardımcıların karanlık bir tarafı var: yazdıkları kodları review etmek, insan yazdığı koddan çok daha zor ve tehlikeli.

İlk bakışta LLM'in yazdığı kod harika görünür. Variable isimleri açıklayıcı, indentation kusursuz, yorumlar detaylı. Hatta geliştiricilerin %73'ü, LLM kodunun okunabilirliğini pozitif ya da nötr olarak değerlendiriyor. Code review sırasında göze hoş gelen bu "görsel mükemmellik", tehlikeli bir güven hissi yaratıyor.

# LLM'in yazdığı görünüşte temiz kod:
def get_user_data(user_id):
    """Retrieve user data from database"""
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query)

Bu kod compile olur, çalışır, hata vermez. Ama SQL injection açığı için altın bilet. LLM, güvenlik intent'ini anlayamaz.

Hallucination: Mantık Hataları

LLM'lerin en tehlikeli özelliklerinden biri hallucination. Ürettiği kodda üç temel hallucination türü öne çıkıyor:

1. Görev Gereksinimlerini Yanlış Yorumlama

"Kullanıcıların son 7 günlük aktivitesini göster" dersiniz, son 7 kaydı getirir. Fonksiyon çalışır ama istediğiniz şeyi yapmaz.

2. Kütüphane ve API Bilgisi Yanılgıları

Deprecated metodları çağırır, parametre sıralarını karıştırır, var olmayan fonksiyonları kullanır.

3. Proje Context'ini Karıştırma

En tehlikelisi budur. Yanlış IP adresleri, yanlış port'lar, yanlış database isimleri. Production'a giden bir AI kodu, staging database referansı içerebilir.

Güvenlik: Her Üç Koddan Biri Tehlikeli

Araştırmalar gösteriyor ki AI üretimi kodun yaklaşık %50'si bug içerirken, %62'si tasarım hatası veya güvenlik açığı barındırıyor. En yaygın açıklar:

• Input Sanitization Eksikliği: Kullanıcı girdileri doğrulanmadan işleniyor
• SQL Injection: Sadece %80 güvenli kod üretimi
• Hardcoded Secrets: API key'ler ve secret'lar doğrudan koda gömülüyor

GitHub Copilot ile yazılan 1,689 programın %38.8'i güvenlik açığı içeriyor. Bu, her üç AI kodundan birinin potansiyel güvenlik riski taşıdığı anlamına geliyor.

Architectural Drift: Sessizce Batıran Tekne

LLM'lerin en sinsi problemi architectural drift. Her task için kod üretirken, projenin genel mimari prensiplerinden yavaş yavaş uzaklaşır.

# İnsan developer - batch pattern:
def update_users(user_ids):
    users = db.query(
        "SELECT * FROM users WHERE id IN (?)",
        user_ids
    )
    for user in users:
        user.update()

# LLM - her iterasyonda DB call:
def update_users(user_ids):
    for user_id in user_ids:
        user = db.query(
            "SELECT * FROM users WHERE id = ?",
            user_id
        )
        user.update()

İkinci yaklaşım çalışır, testler pass eder. Ama 8x daha fazla I/O operation yapar. SAST tools flag etmez çünkü syntax hatası yok. Code reviewer fark etmez çünkü "fonksiyon çalışıyor".

Production'a çıktığında, 1,000 kullanıcıyla test ettiğiniz endpoint 100,000 kullanıcıyla çöker. Root cause: AI'ın seçtiği naïve implementation pattern.

AI Kendi Kodunu Review Edebilir mi?

LLM'lerin kendi kodlarını review etme performansı da hayal kırıklığı yaratıyor:

Yani AI'ya kendi yazdığı kodu review ettirdiğinizde, her üç hatadan birini kaçırıyor. AI reviewing AI, çözüm değil.

Gerçek Dünya Senaryoları

Senaryo 1: SQL Injection

// AI yazdı, review'dan geçti, production'a çıktı:
app.get('/search', (req, res) => {
    const query = req.query.q;
    db.execute(
        `SELECT * FROM products
         WHERE name LIKE '%${query}%'`
    );
});

İlk XSS saldırısı 2 gün sonra geldi.

Senaryo 2: Excessive I/O

Bir e-ticaret platformu, AI ile yazdırdığı "recommended products" endpoint'ini production'a çıkardı. Her kullanıcı için 50+ ayrı database query. İlk Black Friday'de sistem crash etti.

Senaryo 3: Context Hallucination

AI, "user authentication" görevinde ürettiği kodda, development environment'ın JWT secret'ını hardcode etti. Code review'da kimse fark etmedi çünkü "secret var" kontrolü yapılmıştı. Ama yanlış secret kullanıldığı görülmemişti.

Çözüm: Dört Katmanlı Savunma Stratejisi

AI'dan vazgeçmek değil, daha akıllı review stratejisi geliştirmek gerekiyor:

Katman 1: Otomatik Ön Kontrol

Codedog, PR Agent (Qodo) veya RovoDev gibi araçlar kullanarak otomatik güvenlik taraması yapın. Bu araçlarla %73 security defect reduction sağlanıyor.

Katman 2: İnsan Review Checklist'i

• Input validation her endpoint'te var mı?
• Database queries batch pattern kullanıyor mu?
• Error handling generic try-catch'ten öte mi?
• Security model'e uygun mu? (RBAC, JWT scope vb.)
• Proje conventions'larına uygun mu? (naming, structure)

Katman 3: AI'ya Özel Test Yazın

# AI kodu için özel test yazın:
def test_sql_injection_resistance():
    malicious_input = "1' OR '1'='1"
    result = get_user_data(malicious_input)
    assert result is None or isinstance(
        result, SafeResult
    )

Katman 4: Runtime Monitoring

Production'da AI kodunu izleyin. Anormal I/O pattern'leri, beklenmeyen API çağrıları, abnormal response time'lar. Erken uyarı sistemi kurun.

Sonuç: Güven Değil, Doğrulama

LLM'ler inanılmaz güçlü araçlar. Hızlı prototyping, boilerplate elimination ve brainstorming için mükemmeller. Ama "güvenilir kod üretici" değiller. Final code quality'den sorumlu olan hep insandır.

"Trust, but verify" sözü, AI çağında "Verify, period" haline geldi. LLM yazdı diye güvenmeyin.

— Güvenlik Prensibi

Görünüşte mükemmellik aldatıcıdır. Her satırı, sanki düşmanınız yazmış gibi review edin. Çünkü gerçek şu: AI kodunun en büyük tehlikesi yazdığı hatalar değil, bizde yarattığı yanlış güven hissi. Ve bu güven, production'da çok pahalıya mal oluyor.