Okumadığın kodu üretime göndermek için ne gerekir? Charity Majors'a göre darboğaz artık doğrulama

Şüpheciden savunucuya

Charity Majors, gözlemlenebilirlik (observability) aracı Honeycomb’un kurucu ortağı ve teknoloji direktörü (CTO). “Observability Engineering” kitabının da yazarlarından. 2025’te yapay zekâyla yazılan koda büyük ölçüde “özensiz iş” gözüyle bakanlardandı. Kendi blogunda dönüm noktası olarak Kasım 2025’i gösteriyor. O tarihte çıkan Claude Opus 4.5 ile yaygın kalıplarda yapay zekâ kodu ortalama bir mühendisinkine yaklaştı. Ona göre asıl farkı model değil, onun etrafındaki ajan düzenekleri (harness) yarattı.

Kod ucuzladı, anlamak ucuzlamadı

Eskiden sıfırdan kod yazmak, var olanı düzeltmekten çok daha pahalıydı. Bu yüzden kodu değerli bir varlık gibi korurduk. Charity’ye göre artık bir fonksiyonun birkaç farklı sürümünü üretmek, birini elle yazmaktan hızlı olabiliyor. Bunu altyapıdaki “evcil hayvan ve sürü” (pets vs cattle) geçişine benzetiyor. Eskiden sunucuları tek tek tamir ederdik. Terraform ve Kubernetes’le birlikte bozulanı silip yenisini kuruyoruz.

Bunun için bir düşünce deneyi öneriyor: Kodun tamamını sildiğini düşün. Seni asıl korkutan ne? Satırlar değil; sistemin ne yapması gerektiği, hangi hataların kabul edilebilir olduğu, hangi hataların bilerek düzeltildiği. Charity’ye göre bunlar kodda değil testlerde, eval’larda ve gözlemde yaşamalı. Kodu yeniden üretmek ancak o zaman güvenli olur.

Asıl soru

Charity tartışmayı “yapay zekâ iyi mi, kötü mü” sorusundan çıkarıp ekibe şunu sormayı öneriyor: Bu kodu okumadan üretime göndermek için neye ihtiyacın olurdu? Hemen okumadan göndermeyi önermediğini açıkça yazıyor. Soru bir kışkırtma, amaç cevabı bulmak. Blogunda sıraladığı olası cevaplar şunlar:

• Daha iyi testler ve eval’lar.
• Yeni kodu açıp kapatabildiğin özellik bayrakları (feature flags) ve bariyerler.
• Bir hatanın etki alanını küçültmek, bağımlılıkları ayırmak.
• İşe kritik yolun dışındaki değişikliklerle başlamak.
• Üretimde ne olduğunu gösteren gözlemlenebilirlik.

Sonra bu hazırlıkları bir yol haritasına koyup sıraya diziyorsun. Böylece fikir ayrılığı, yapılabilir bir iş listesine dönüşüyor. Özellik bayraklarını ve kademeli yayını CI/CD yazımızda daha ayrıntılı anlattık.

Kod incelemesi ve üretim

Bölüm sayfasına göre Charity, satır satır kod incelemesini insanın en az değer kattığı işlerden biri olarak görüyor. İnsanlar diff’te hata yakalamakta değil, neyin neden yapılacağını tartışmakta iyi. Doğruluğu ise makinelerin kontrol etmesi gerekiyor. Blogunda mevcut davranışı ölçmek için operasyon ve test dünyasından tanıdık teknikleri öneriyor. Karakterizasyon testleri sistemin bugünkü davranışını olduğu gibi kaydediyor. Kaydet ve tekrar oynat (capture/replay) gerçek trafiği yeni sürüme yeniden gönderiyor. Trafik bölme ise kullanıcıların küçük bir kısmını yeni sürüme yönlendiriyor.

Bir başka nokta: Model çıktısı her seferinde aynı olmayan (deterministik olmayan) sistemlerde sadece önceden yazılmış testlere güvenemezsin. Charity’ye göre bu, üretimi geliştirmenin bir aşaması olarak görmeyi ve testleri, eval’ları orada trace’lerle çalıştırmayı zorunlu kılıyor. Ona göre ekiplerin sadece %5–10’u bu kadar hızlı geri bildirim döngüleriyle çalışıyor.

Sonra ne oldu?

Honeycomb Eylül 2026’da kendi mühendislik normlarını yayımladı. Yıl sonu hedeflerinden biri, PR’ların en az %25’inin insan incelemesi olmadan, yapay zekâ incelemesiyle otomatik birleşmesi. Şartı da konmuş: Değişikliklerin hataya yol açma oranı %3’ün altında kalacak, servis hedefleri (SLO) korunacak. Yani “okumadan göndermek” sorusunun cevabı ölçülebilir bir hedefe dönüşmüş.

Düşün

• Ekibinde bir değişiklik ters giderse bunu kaç dakikada fark eder, kaç dakikada geri alırsın?
• Kodu silsen, sistemin ne yapması gerektiğini anlatan bilgi nerede kalırdı?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.