Savunma Hattınızı Yazılı Kurallara Emanet Etmeyin (3/5)

Çoğu AI ürünü savunmasını politika belgelerine yazar. O belgeler, ekibe yeni katılan bir mühendisle ya da gece yarısı yapılan bir refactor ile birlikte sessizce çürür. Ben savunmamı, her commit'te çalışan iki sert kontrole bıraktım: biri, asla yapmayacağıma söz verdiğim şeylerden birini gönderirsem build'i kırıyor; diğeri, zor kazanılmış bir ders aranıp bulunamaz hale gelirse ya da kendiyle çelişirse wiki'yi kırıyor. İkisi de aynı HMAC zincirinde mühürlü. Ortaya çıkan savunmanın tek bir özelliği var: geri kaçmıyor. Her ret ve her ders, sistemi hem geriye götürülmesi daha zor hem de daha işe yarar hale getiriyor.

Her commit'te iki script çalışıyor.

Birincisi, asla göndermeyeceğime söz verdiğim şeyleri tüm kod tabanında arıyor: çalışma zamanında metni koda çevirip çalıştıran her şey, secret'ın değerini döndüren tool'lar, ham sağlayıcı modülleri, agent'ların veri sızdırmasına yol açan ölümcül üçlü. Bunlardan biri koda girdiği anda build kırılıyor; uyarı vermiyor, doğrudan kırılıyor.

İkincisi wiki'yi dolaşıyor ve tam ters soruyu soruyor: burada olması gereken ama olmayan ne? Kaynağı gösterilmemiş bir iddia. Hiçbir sayfadan bağlantı almamış bir kavram sayfası. Aylar arayla yazılmış, birbiriyle çelişen iki sayfa. Birinci script sistemin bir CVE'ye dönüşmesini engelliyor; ikincisi, sistemin öğrendiğini unutmasını.

lodos'u tek bir kural üzerine kurdum: önemli olan her ret, build'in içinde bir grep'tir; önemli olan her bilgi, versiyonlanmış ve sorgulanabilir bir sayfadır.

İkisi de en ufak bir kurcalamada gürültüyle kırılan aynı HMAC zincirinin içinde duruyor. Eklemeyi reddettiğiniz şeyi yazın. Unutmayı reddettiğiniz şeyi yazın. Sonra build'i, bu ikisi olmadan hiçbir şeyi göndermeyecek hale getirin. Çoğu AI ürünü ne olmak istediğini yazar ve bunu yazılı kurallarla savunur. Daha küçük bir grup ne olmayı reddettiğini yazar ve bunu kodla savunur. En nadir grup ise unutmayı reddettiğini de yazar ve bunu, bir sayfa konudan sapar sapmaz kendi bütünlük kontrolünü kıran bir wiki ile savunur. Üst üste birikerek büyüyen tek savunma hattını işte o son grup kuruyor.

Neler çürür, neler çürümez?

Yazılı kurallara dayanan savunmalar sessizce ölür. "Secret'ları asla loglamayız." "Her tool çıktısını izole ederiz." "LLM görmeden önce doğrularız." Bu cümleler SOC 2 belgelerinde yazar ve yazıldıkları gün doğrudur. Sonra ekibe yeni katılan bir mühendis hata ayıklamak için bir logger ekler. Bir refactor, temizleme adımını bir feature flag'in arkasına taşır. Cümle belgede aynen durur, ama sistem artık o cümlenin anlattığı sistem değildir. Hiçbir şey kırılmaz. Kimse fark etmez.

Bilgi tarafındaki çürüme daha da hızlıdır. Founder gecenin ikisinde bir müşterinin neden bıraktığını anlar, çıkarımını Slack'e yazar, bir hafta içinde unutur. Ders, sonradan arayıp bulabileceği hiçbir yerde durmaz. Üç ay sonra aynı sorun aynı şekilde geri gelir ve founder aynı dersin bedelini ikinci kez öder. En pahalı çürüme budur, çünkü founder çürüdüğünü fark bile etmez.

İki çürümenin de tedavisi aynı: korumak istediğiniz şeyi, o şey bozulduğunda gürültü çıkaran bir mekanizmaya bağlayın. Bir ret geri alındığında build kırılsın. Bir sayfa hiçbir yerden bağlantı almaz, konudan sapar ya da kendiyle çelişir hale geldiğinde wiki kendi lint'ini kırsın. Çözüm bir süreç değil. Çözüm, sistemin her seferinde kendi üzerinde çalıştırdığı bir kontrol.

Karpathy'nin yönteminin ticari hâli

Bilgi tarafı bana ait değil. Andrej Karpathy, üç işlemi ve tek bir iddiası olan bir LLM wiki'si anlattı: wiki çalıştırılabilir dosyadır, ham kaynaklar kaynak koddur, LLM derleyicidir, lint testlerdir, sorgular da çalışma zamanıdır.

Yöntemi olduğu gibi aldım, sonra üç noktada bilerek ayrıldım.

• Depolama. Karpathy markdown dosyalarından oluşan bir klasör ve git kullanıyor. Ben SQLite ve her bölümü ayrı şifrelenmiş bir vault kullanıyorum. Takası şöyle yapıyorum: gizlilik uğruna birlikte çalışabilirlikten vazgeçiyorum. Temiz bir markdown dışa aktarımı, canım istediğinde Obsidian kapısını yine de açık tutuyor.
• Yetki. Karpathy LLM'in doğrudan yazmasına izin veriyor. Bende her değişiklik bir öner-onayla adımından geçmek zorunda; agent asıl sayfaya hiç dokunmuyor. Her onay bana beş on saniyeye mal oluyor. Karşılığında agent, benim davranışımı sessizce yeniden yazamıyor.
• Denetim. Karpathy düz bir markdown log tutuyor. Ben, ana paroladan türetilmiş bir anahtarla imzalanan bir HMAC zinciri tutuyorum. Log'a dokunulmuşsa, bir sonraki açılışta zincir kırılması olarak karşıma çıkıyor.

Bunlar felsefi ayrılıklar değil. Kişisel bilgi yönetimi için tasarlanmış bir yöntemin ticari uyarlamaları. Yöntemin ruhu bozulmuyor, ama ürün artık uyum denetiminden geçmek zorunda olan alıcıya satılabiliyor; o alıcı da bambaşka bir fiyat ödüyor.

İki taraf da ilerliyor, geri kaçmıyor

Ret tarafı ile bilgi tarafının biçimi birebir aynı. Biri asla var olmaması gereken şeyleri arıyor, diğeri asla eksik olmaması gereken şeyleri. İkisi de bir yokluğu denetliyor. İkisi de sessizce geçmiyor, gürültüyle kırılıyor. İkisi de aynı HMAC zincirinde mühürlü.

Wiki'ye bir soru sorduğumda gelen cevap iyiyse, arayüz tek tıkla "bunu sayfa olarak kaydet" diyor. Kaydedersem cevap kalıcılaşıyor; bir sonraki oturum onu buluyor ve aynı soruyu bir daha sormam gerekmiyor. İzlediğim metrik kaydetme oranı; o oran da zamanla yükseliyor. Wiki, sistemin ben kullandıkça yalnızca güçlenen tek parçası.

Ret tarafı da aynı şekilde çalışıyor. Bozulmaması gereken bir kuralı tehdit eden her yeni özellik, doğrulama script'ine yazılmış yeni bir kuralla birlikte geliyor. Script'teki kontrol sayısı sekiz ayda yediden otuz ikiye çıktı. Her yeni yetenek, kendi kötüye kullanım sınıfını kapatan grep'iyle birlikte gönderiliyor. Gönderilen her özellik, kod tabanını bir öncekinden daha çok şeyi reddeder hale getiriyor.

Çoğu ekip bu ikisini ayrı işler sayar. Oysa ikisi aynı disiplinin iki farklı yokluğa uygulanmış hali: asla var olmaması gereken şeyler ve asla unutulmaması gerekenler.

Bedeli ne? Asıl mesele neden o bedel?

Hız kaybettiğim yerler belli: retlerle çatışan özellikler ve wiki'yi yok sayıp ilerleyecek yeniden yazımlar. İleri bir kullanıcı satır içi bir ifade değerlendirici istedi. Reddettim. Bir müşteri secret'ın değerini döndüren bir tool istedi. Reddettim. Gelecekteki ben, yavaş hissettirdiği için onay döngüsünü söküp atmak isteyecek; build buna izin vermeyecek.

Sürüm notlarım hiçbir rakibinkine benzemiyor. Bende retler en az özellikler kadar sık geçiyor. Bilerek yapmadıklarımı es geçen, pürüzsüz bir büyüme hikâyesi anlatmanın yolu yok.

Kazandığım şey tanıtım sayfasına sığmıyor; regülasyona tabi bir sektörden gelen alıcıyla yapılan satış görüşmesine sığıyor. O alıcı için "yapamayız" ile "yapmayacağımıza söz veriyoruz" aynı cümle değil. Bir uyum sorumlusu için, kurcalandığında belli olan bir HMAC zinciri ile düz bir markdown log aynı şey değil. Bugün wiki'ye yazan founder'ı, altı ay sonra o wiki'ye muhtaç olacak founder okuyor. Bu insanların hiçbirine pazarlama cümleleriyle ulaşılmıyor.

Çalabileceğiniz beş parça

Hiçbiri diğerine muhtaç değil. Bir araya geldiklerinde yöntemin kendisi oluyorlar.

1. Hiçbir türden ifade değerlendirici içermeyen, her adımı kod değil tanım olan bir iş akışı motoru.
2. AI'ın düz metin bir secret döndürmesinin yapısal olarak imkânsız olduğu, iki depolu bir vault.
3. Negatif kanıt disipliniyle yazılmış, build sırasında çalışan ve bozulmaması gereken kuralları denetleyen bir script.
4. Karpathy'nin üç işlemini uygulayan ve log'unu bir HMAC zincirine saran bir wiki.
5. Agent'ın kendi davranışını asla kendisinin yazmadığı, yalnızca öneri üreten bir öğrenme döngüsü.

İstediğiniz sırayla kurun. Aralarındaki tek ortak şey disiplin: göndermeyi reddettiğiniz şeyleri de unutmayı reddettiğiniz şeyleri de yazın, ikisini de build'de bir kontrole bağlayın, sonra o kontrolleri bilerek ihlal etmeye çalışıp gerçekten çalıştıklarını kanıtlayın. Geri kalan her şey mühendislik.

Sırada ne var?

Doğru kurgulaması en uzun süren döngü sonuncusu oldu. Agent konuşmayı izliyor, kendi beceri kataloğunun iyileştirilebileceği anı fark ediyor ve bir düzenleme öneriyor. Ben onaylıyorum ya da reddediyorum. Düzenleme, diğer bütün wiki önerileriyle aynı diff ekranından geçiyor. Agent kendi davranışını asla kendisi yazmıyor. Asıl savunma hattı, öneri ile onay arasındaki o darboğazın kendisi. Sıradaki yazı iki şeyi anlatıyor: bu döngüyü ve agent'a nasıl davranacağını söyleyen metindeki, bütün bu mühendislik emeğini haklı çıkaran kısa bir pasajı.

Bekleme listesine katılın