Modern yazılım geliştirme dünyasında artık hemen hepimiz bir LLM (Büyük Dil Modeli) ile yan yana kod yazıyoruz. İster Cursor kullanın ister Claude veya Copilot; yapay zekanın birkaç saniyede yüzlerce satır kod üretmesi büyüleyici bir his. Ancak dürüst olalım: O üretilen kodların arkasında bazen var olmayan kütüphane bağımlılıkları, sinsi mantık hataları ve ciddi güvenlik açıkları saklanıyor. Hızlı yazıyoruz ama arkamızı toplamaya çalışırken daha çok yoruluyoruz. İşte bu noktada modern yazılıma eski ama çok sağlam bir disiplin geri dönüyor: Stage-Gated yaklaşımı.

Bu yazıda, geleneksel mühendislikten ödünç aldığımız bu “aşamalı kapı” sistemini yapay zeka destekli bir pipeline içine nasıl entegre edebileceğimizi, bizzat kurup test ettiğim bir senaryo üzerinden anlatıyorum. Amacımız yapay zekayı yavaşlatmak değil; yapay zeka güvenliği standartlarından taviz vermeden kodu üretime (production) taşımak.

Şelale (Waterfall) Mezardan mı Çıktı? “Stage-Gated” Nedir?

Eski usul Waterfall (Şelale) metodolojisini hatırlarsınız: Bir faz bitmeden diğeri başlamaz, arada kalın onay kapıları bulunur. Çevik (Agile) dünyada bundan nefret ettik çünkü hızı kesiyordu. Fakat işin içine modeller ve tahmin edilemez çıktılar girince dengeler değişti.

Stage-Gated mekanizması, üretilen bir çıktının bir sonraki aşamaya geçebilmesi için belirli kriterleri (“kapıları”) geçmek zorunda olduğu bir filtreleme modelidir. Bir LLM’e “Bana şu API servisini yaz” dediğinizde kodu doğrudan ana dala (main branch) göndermezsiniz. Kod, tanımladığınız kapılardan sırayla geçer; herhangi bir kapıda takılırsa ya LLM’e düzeltmesi için geri fırlatılır ya da doğrudan reddedilir.

[Görsel: Bir LLM kod üretim pipeline’ının 4 aşamalı kapıdan (Sözdizimi, Güvenlik, Test, İnsan Onayı) geçişini gösteren şematik diyagram]

Test Masası: 4 Kapılı Bir Pipeline Mimarisi

Teoriyi bir kenara bırakıp işi pratiğe dökelim. Deneme amacıyla yerel ortamımda FastAPI ile basit bir servis geliştiren bir akış kurdum. Modeli (Claude 3.5 Sonnet) bir komut satırı aracıyla tetikledim ve kodu şu 4 kapıdan geçirdim:

Kapı 1: Sözdizimi (Syntax) ve Tip Kontrolü

LLM’ler bazen parantezleri unutur, bazen var olmayan metodları çağırır. İlk kapımız en ucuz ve en hızlı olanı: AST (Soyut Sözdizim Ağacı) kontrolü ve mypy tip denetimi. Modelin çıktısı bu aşamada Python tarafından derlenemiyorsa sonraki aşamaya geçiş izni verilmez.

Kapı 2: Statik Güvenlik Analizi (SAST)

Model, istemeden de olsa SQL Injection açığı üretmiş olabilir mi? Ya da hardcoded bir API anahtarı bırakmış mı? Bu kapıda açık kaynaklı statik analiz araçları (örneğin Semgrep veya Bandit) devreye girer. Güvenlik açığı tespit edilirse pipeline kırılır.

# Semgrep ile yerel pipeline kontrolü çalıştırma
semgrep scan --config auto --error ./generated_code/

Kapı 3: Otomatik Birim Testleri ve “Self-Healing”

İşte en sevdiğim bölüm. Eğer kod ilk iki kapıyı geçtiyse, önceden tanımlanmış test senaryoları (Pytest) çalıştırılır. Test başarısız olursa, test hata raporu otomatik olarak tekrar LLM’e gönderilir: “Kodun şu testten geçmedi, hata mesajı bu. Kodu tekrar düzenle.” Buna sektörde self-healing (kendi kendini onarma) döngüsü deniyor. En fazla 3 deneme hakkı tanıyoruz.

Kapı 4: İnsan Gözü (Human-in-the-Loop)

Bütün testlerden geçen kod bir Pull Request (PR) olarak açılır. Son kapı daima bir insandır. Ancak bu aşamaya gelen kod zaten sözdizimi, güvenlik ve temel iş kuralları açısından elendiği için inceleyen mühendisin harcadığı süre dakikalar yerine saniyelere iner.

[Görsel: GitHub Actions üzerinde çalışan Semgrep ve Pytest adımlarının yeşil tik aldığı, insan onayı bekleyen PR ekran görüntüsü]

Gerçek Bir Deney: SQL Injection Girişimi Kapıya Takılınca

Pipeline’ı test etmek için Claude’a bilerek hafif yönlendirici bir prompt verdim: “Kullanıcı ID’sine göre kullanıcı bilgilerini getiren ham SQL sorgulu bir fonksiyon yaz.”

Model, f-string kullanarak sorguyu birleştiren tipik bir güvensiz kod bloğu oluşturdu. Süreç şöyle işledi:

• Kapı 1 (Syntax): Kod geçerli Python sözdizimine sahipti. Geçti.
• Kapı 2 (Semgrep): Kırmızı alarm! python.lang.security.audit.sqli kuralı tetiklendi. Parametreli sorgu kullanılmadığı için kod derhal durduruldu.
• Geri Besleme: Pipeline, Semgrep hata çıktısını prompt’a ekleyip modeli uyardı.
• Sonuç: İkinci denemede model kodu SQLAlchemy ORM parametreli sorgusuyla düzeltti ve Kapı 2’den başarıyla geçti.

Artılar ve Eksiler: Bu Zahmete Değer mi?

Her güvenlik katmanı beraberinde bir sürtünme getirir. Karar vermenizi kolaylaştırmak için gözlemlerimi özetledim:

Hangi Araçları Kullanabilirsiniz? (Fiyat ve Alternatifler)

Bu yapıyı kurmak için servet harcamanıza gerek yok. Açık kaynak dünyasında harika ücretsiz seçenekler mevcut:

• Guardrails AI (Ücretsiz / Açık Kaynak): LLM çıktılarını belirli Pydantic şemalarına ve regex/güvenlik kurallarına zorlamak için biçilmiş kaftan. Kendi sunucunuzda tamamen ücretsiz çalıştırabilirsiniz.
• Semgrep (Freemium): Statik kod analizi için sektör standardı haline geldi. Açık kaynak versiyonu CLI üzerinden yerelde veya GitHub Actions içinde tamamen ücretsizdir. Ekip yönetimi sunan Semgrep Cloud ise aylık kullanıcı başı yaklaşık $40 civarından başlar.
• NeMo Guardrails (NVIDIA – Ücretsiz): Özellikle diyalog ve mantık akışlarını kısıtlamak isteyenler için geliştirilmiş güçlü bir açık kaynak kütüphane.
• SonarQube Community Edition (Ücretsiz): Kod kalitesini ve teknik borcu ölçmek için kendi sunucunuza kurabileceğiniz ücretsiz alternatif.

Son Söz

Yapay zekanın kod yazma hızına hayran olmamak elde değil. Ancak kontrolsüz hız, teknik borç dağları ve güvenlik kabusları yaratır. Stage-gated yaklaşımı, Agile pratikleri yavaşlatmak için değil; yapay zekayı sorumsuz bir stajyerden güvenilir bir takım arkadaşına dönüştürmek için ihtiyacımız olan emniyet kemeridir. Henüz denemediyseniz, en azından bir GitHub Action içine basit bir linter + Semgrep kapısı koyarak ilk adımı atmanızı şiddetle tavsiye ederim.