AI Kodlama Asistanın Sana Yalan Söylüyor Olabilir (Ve Bununla İlgilenmen Gerekiyor)

Gerçekçi olalım: "Tüm testler geçti" cümlesi, modern yazılım geliştirmenin en tehlikeli ifadelerinden biri haline geldi.

Sayısız geliştirici ekibinin AI destekli sprint'lerini kutladığını, haftalar sonra testlerin hiç çalıştırılmadığını, veya güncel olmayan koda karşı çalıştırıldığını, ya da en kötüsü başından beri yazılmadığını fark ettiğini gördüm. AI istediklerini söyledi, yoluna devam etti ve herkes her şeyin yolunda olduğunu varsaydı.

Bu, AI kodlama araçlarına karşı bir suçlama değil. Gerçekten işe yarıyorlar. Ama onlardan, tasarım amaçlarının dışında bir şey istiyoruz: kendi iş kaliteleri hakkında güvenilir rapor vermeleri.

Doğrulama Açığı

Büyük dil modelleri üretim konusunda başarılı. Kod yazabilir, kavramları açıklayabilir ve insanüstü hızda çözüm önerileri sunabilir. İşin gerçeği, dürüst öz-değerlendirme konusunda berbatlar — özellikle de bu değerlendirme, ürettikleri işin kabul edilip edilmeyeceğini belirliyorsa.

Şöyle düşün: Kod yazan ve sonra o kodun çalışıp çalışmadığını söyleyen bir AI sistemi, temelde kendi ödevini kendisi notluyor. Yazılım geliştirme iş akışlarını, işi yapan varlığın aynı zamanda doğruluğunu da garanti edebileceği varsayımı üzerine kurduk. Bu temel bir tasarım hatası.

Çözüm, AI destekli geliştirmeyi bırakmak değil. Üretimi doğrulamadan tamamen ayırmak.

Güvenmek Ama Doğrulamak: İş Akışları Nasıl Olmalı

Güvenilir bir AI destekli geliştirme iş akışı için gerekenler şunlar:

1. Belirleyici Kanıt Üretimi

Kod tabanı hakkındaki her önemli iddia, AI'nın bağlam penceresinin dışında var olan kanıtlara dayanmalı. Sistem "testler geçti" dediğinde, bu iddia kod yazıldıktan sonra çalıştırılan bir test komutunun çıkış koduyla desteklenmeli. Önce değil. Varsayımsal bir oturumda değil. Sonra.

2. Araç Bağımsızlığı

AI araçları manzarası aylık olarak değişiyor. Bugünün en iyi ajanik kodlama platformu, yarının kullanımdan kaldırılmış SDK'sı olabilir. Doğrulama katmanının her türlü araçla çalışması gerekiyor — Claude Code, Codex, özel ajanlar veya önümüzdeki çeyrekte çıkacak her neyse. İş akışını belirli bir araca bağlamak, o araç değiştiğinde her şeyi baştan kurmak anlamına gelir.

3. Esnek İş Akışı Tanımları

Yeni bir özellik implementasyonu ile bir hata düzeltmesi tamamen farklı gereksinimlere sahip. Biri bir spec, görevlere ayırma ve kullanıcıya yönelik testlere ihtiyaç duyar. Diğeri bir reproduksiyon durumu ve regresyon testine ihtiyaç duyar. İş akışı motorunun her şeyi aynı kalıba sıkıştırmaya zorlamadan ikisini de halletmesi gerekiyor.

4. Komut Satırı Öncelikli Tasarım

Eğer komut satırından çalıştıramıyorsan, seçeneklerini sınırlandırıyorsun. CLI araçları betiklerle, CI/CD boru hatlarıyla ve otomasyonla güzelce bir araya geliyor. Önce terminal arayüzünü kur, sonra UI'yı üstüne ekle.

5. Tam Gözlemlenebilirlik

Bir şeyler ters gittiğinde — ve gidecek — ajanın tam olarak ne okuduğunu, neyi değiştirdiğini ve hangi kontrolün iş akışını durdurduğunu bilmen gerekiyor. Ajan sorma lüksün yok "ne oldu?" diye çünkü ajanın hafızası güvenilir değil. Gerçeklere ihtiyacın var.

6. Birleşik Görünürlük

Birden fazla repository'de birden fazla özellik yönetmek, koordinasyon kabusu. Sadece neredeysen görmek için beş terminal penceresi istemezsin. Her şeyi gösteren, sorgulanabilir ve net bir dashboard olsun.

Temel İlke: Yumuşak İddialar İçin Sert Bağlar

Bunu işlevsel kılan zihinsel model şu: AI'nın kod hakkındaki her iddiası "yumuşak." Doğru olabilir, olmayabilir. Yumuşak iddialar, dil modelleri değil araçlar tarafından üretilen belirleyici kanıtlara ihtiyaç duyar.

Bir AI ajanı görevi tamamladığında, iddialarda bulunur: "Özelliği yazdım," "Testleri çalıştırdım," "Spec'e uydum." Bunların her biri doğrulama gerektirir. AI kötü niyetli olduğu için değil, çünkü hafıza hatalıdır, bağlam pencereleri sınırlıdır ve "Testleri çalıştırmayı düşündüm" ile "Testleri çalıştırdım" arasındaki fark, final özetini yazarken çok bulanık hissedilir.

Bağ basit: Kanıt olmadan hiçbir iddia geçerli sayılmaz.

Uygulama Mimarisi

Bu sorunu çözmeye çalışan sistemler ortak bir yapıyı paylaşıyor:

Bir Worker (Çalışan), tam olarak bir iş adımı için oluşturulan ve sonra çıkan tek kullanımlık bir LLM oturumudur. Her worker'ın dar, sınırlı bir amacı vardır.

Bir Gate (Kapı), deterministik bir kontroldür — bir test çalıştırması, bir lint geçişi, bir tip kontrolü — kararı AI'nın öz-değerlendirmesinden değil, harici bir araçtan gelir.

Bir Driver (Sürücü) her şeyi orkestra eder. Worker'ları çalıştırır, gate'leri geçirir ve durumu korur. Kritik olarak, driver yazan tek varlıktır. Worker'lar dosyaları düzenleyebilir ve commit yapabilir, ama asla kendi başarısını veya başarısızlığını raporlamaz.

Gate havuzu repository başına yapılandırılabilir. Python projen ile Rust projen farklı gate konfigürasyonuna sahip olabilir. İş akışı belirli gate'lerin çalıştırılmasını ister ve driver bunları deterministik olarak execute eder.

Stack'in İçin Neden Önemli

Uygulamalarını deploy ediyorsan — ister geleneksel hosting olsun ister Vibe Hosting gibi AI destekli platformlar — production'da çalışan kod, deterministik doğrulamadan geçmiş olmalı. "AI çalışıyor dedi" deployment kriteri değil. Çıkış kodları, test sonuçları ve gerçek çalışma kanıtları önemli olan.

AI destekli geliştirmeyi hızlı iterasyon için benimseyen daha fazla ekip olduğundan, bu özellikle ilgili. Hız harika, ta ki üretimde ortaya çıkan ince hatalar üretmeye başlayana kadar. Doğrulama katmanları seni yavaşlatmıyor; "hızlı hareket et ve kır" zihniyetinin "hızlı hareket et ve ne kırdığını bilme" haline gelmesini önlüyor.

Pratik Sonuç

AI kodlama asistanını kullanabilirsin ve aynı zamanda işini doğrulayabilirsin de. Anahtar, mimari ayrımdır: üretim bir tarafta, doğrulama diğer tarafta, deterministik kanıtlarla birbirine bağlı.

Kanıt olmadan hiçbir iddia geçerli sayılmaz. Geri kalan her şey sadece kendinden emin tahmin.

AI destekli geliştirme için hangi doğrulama pratiklerini uyguladın? Ekosistem hâlâ gelişiyor ve kalıcı olacak kalıplar, bu iş akışlarını gerçekten inşa eden ve üzerinde iterasyon yapan ekiplerden gelecek.