Kod Ucuzladı, Karar Pahalandı

Yapay zekâ çağında geliştiriciliğin yeni ağırlık merkezi

Yeni bir servisin planını çıkarmak için oturuyorsunuz. Yirmi dakika sonra elinizde hâlâ tek satır kod yok, ama yedi karar var:

• Bu verinin asıl sahibi hangi servis olacak?
• Bu alan gerçekten boş bırakılabilir mi?
• Anlık tutarlılık mı gerekiyor, gecikmeli tutarlılık yeterli mi?
• Asenkron mesaj işlenemezse yeniden mi denenecek, yoksa telafi işlemi mi çalışacak?
• Aynı istek iki kez gelirse sistem ne yapacak?
• Doğrulama hangi katmanlarda yapılacak: arayüz, servis, veri tabanı?
• Bunun doğru çalıştığını nasıl kanıtlayacağız?

Bunların hiçbiri yeni soru değil. Bazılarının cevabı ekip içinde daha önce verilmiş bile olabilir. Yeni olan, hepsinin aynı anda ve açık soru biçiminde önünüze gelmesi.

Üstelik modelin soru sorması iyi senaryo, çünkü kararı hiç değilse görüyorsunuz. Asıl risk sormadığında: planın içine düzyazı olarak gömülmüş, tek bir onayla kabul edilmiş kararlarda. Model yalnızca kendi belirsiz bulduğu yerde soruyor, oysa sizin bağlamınızı bilmediği için yanıldığı yerlerde gayet emin oluyor.

O yirmi dakikanın sonunda kalan yorgunluk da gerçek. Nereden geldiği ilk bakışta anlaşılmıyor.

Kıt olan dikkat

Karar vermenin yorduğu fikri yeni değil. En yaygın haliyle sosyal psikolog Roy Baumeister ile bilim gazetecisi John Tierney’nin Willpower kitabından yayıldı: irade bir kas gibi çalışır, kullandıkça yorulur. Zuckerberg’in gri tişörtü de hep bu tezle birlikte anlatıldı, günlük karar kotanı ne giyeceğine harcama diye.

Bu yazının dayandığı zemin daha dar: dikkat.

Hem iktisat Nobel’i hem de Turing Ödülü almış olan Herbert Simon, 1971'de bugün fazlasıyla tanıdık gelen bir cümle yazmıştı: bilginin bolluğu, dikkatin kıtlığını üretir. Psikolog Daniel Kahneman’ın Sistem 1 ile Sistem 2 ayrımı da bunu anlatmak için kullanışlı bir dil sunuyor: otomatik düşünme daha az, bilinçli akıl yürütme daha fazla dikkat istiyor.

Bunun deneysel karşılıklarından biri görev değiştirme maliyeti. Bir görevden diğerine geçtiğimizde tepkilerimiz yavaşlıyor ve hata ihtimali genellikle artıyor. Hazırlanmak bu maliyeti azaltıyor, ama tamamen ortadan kaldırmıyor.

Sophie Leroy’un “dikkat artığı” çalışmaları da bunun üzerine biniyor: tamamlanmamış bir işten diğerine geçtiğimizde zihnimizin bir bölümü önceki işte kalabiliyor. Aynı mekanizma askıda bıraktığımız teknik kararlarda da kendini hissettiriyor. Sabah “buna sonra bakarız” denip geçilen şema kararı, öğleden sonra yazılan kodun içinde yaşamaya devam ediyor.

Seçenek bolluğu tarafı ise daha ihtiyatlı anlatılmayı hak ediyor. Iyengar ve Lepper’ın ünlü market deneyinde, yirmi dört çeşit reçel gören müşterilerin yüzde üçü satın alırken altı çeşit görenlerde bu oran yüzde otuzdu. Sonraki meta-analizler bu etkinin her durumda ortaya çıkmadığını gösterdi. Ancak seçenekler karmaşık, tercihler belirsiz ve doğru cevabı bulma baskısı yüksek olduğunda seçenek bolluğu kararı zorlaştırabiliyor. Mimari kararlar çoğu zaman bu tarife uyuyor.

Kararı dondurmak

Obama 2012'de Michael Lewis’e şunu söylemişti:

Verdiğim karar sayısını azaltmaya çalışıyorum. Ne yediğime ya da ne giydiğime dair karar vermek istemiyorum. Çünkü verecek çok fazla başka kararım var.

Vanity Fair, 2012

Zuckerberg 2014'te gri tişörtü için neredeyse aynı gerekçeyi verdi: hayatını, işi dışındaki her konuda mümkün olduğunca az karar verecek şekilde temizlemek istiyordu.

Önemli olan ikisinin ortak noktası. Hiçbiri karar vermeyi bırakmıyor. Kararı bir kez verip donduruyorlar ve kazanç kararın kendisinden değil, her sabah yeniden verilmemesinden geliyor.

Yazılımdaki karşılığı da bu. Bir takımın her oturumda yeniden tartıştığı her konu, aslında bir kez verilip hiçbir yere yazılmamış bir karardır.

Brooks’un ayrımı

IBM’in System/360 işletim sistemi projesini yöneten ve o deneyimi The Mythical Man-Month kitabında anlatan Fred Brooks, 1986'da yazılımın iki tür karmaşıklığı olduğunu yazmıştı.

Arızi karmaşıklık, işi yapabilmek için katlandığımız yüktür: sözdizimi, kalıp kod, kütüphane imzalarını hatırlamak, bir yapılandırma dosyasının hangi anahtarı beklediğini bulmak. Asli karmaşıklık ise problemin kendisidir. Sistemin ne yapacağı, kavramların nasıl modelleneceği, sınırların nereden geçeceği.

Yapay zekâ arızi karmaşıklığın önemli bir bölümünü ucuzlattı. Geriye kalan da Brooks’un kırk yıl önce en zor kısım dediği şey:

Bir yazılım sistemi kurmanın en zor tek parçası, tam olarak neyin inşa edileceğine karar vermektir.

No Silver Bullet, 1986

Yazının başındaki yedi soru bu tanımın tam ortasına düşüyor. Hiçbiri sözdizimiyle, kalıp kodla ya da kütüphane imzasıyla ilgili değil. Hepsi asli karmaşıklığa ait. Model bu sorulara seçenekler üretebilir; fakat doğru cevabı belirleyen bağlama sahip olmadığı için kararın sahipliğini ve sonuçlarının sorumluluğunu devralamaz.

Kararlar artmadı, sıkıştı

Eskiden bu kararlar işin içine yayılırdı. Bir kısmı tasarım toplantısında alınır, bir kısmı kod yazarken şekillenir, bir kısmı hiç konuşulmadan sisteme yerleşirdi. Çoğu hiç sorulmadan, elimiz klavyedeyken kendiliğinden veriliyordu.

Şimdi hepsi planlama ekranında, madde madde, cevap bekliyor.

Sayıları belki değişmedi. Ama haftaya yayılan bir şey yirmi dakikaya sığınca insan bunu hissediyor.

Otomasyonun ironisi

İnsan-makine etkileşimi üzerine çalışan psikolog Lisanne Bainbridge, 1983'te Ironies of Automation diye bir makale yazdı. Tespiti şuydu: otomasyon düzenli ve tekrarlanan işleri üstlenir, insana istisnaları bırakır. İnsan icracıyken denetçiye dönüşür.

Sorun da burada başlıyor. Uzun süre yalnızca denetleyen kişi, gerektiğinde müdahale edecek refleksleri yavaş yavaş kaybediyor. Sistem insana en çok ihtiyaç duyduğu anda, insan sistemin ayrıntısına en uzak noktada oluyor. Nicholas Carr The Glass Cage’de buna “üretme etkisini” de ekliyor: insan, çözümüne aktif olarak katıldığı şeyi yalnızca önüne gelen bir sonuçtan daha iyi öğreniyor ve hatırlıyor.

Bugünkü karşılığı gayet somut. Üretim maliyeti hızla düşerken doğrulama aynı ölçüde ucuzlamıyor. Dört yüz satırlık bir değişikliği üretmek birkaç dakika sürebilir; içindeki yanlış varsayımı fark edip etkisini değerlendirmek çok daha uzun sürebilir.

Geliştirici komut veren bir orkestra şefine benziyor. Ama şefin yanlış notayı duyabilmesi için müziği de bilmesi gerekiyor.

Karar borcu

Teknik borcu yıllardır konuşuyoruz. Yanına bir yenisi geldi: karar borcu.

Netleştirmeden geçilen, “sonra bakarız” deyip modelin varsayımına bırakılan her tercih ileride tutarsız veri, güvenlik açığı veya yeniden yazma maliyeti olarak geri geliyor.

Karar borcunu teknik borçtan daha sinsi yapan şey görünmemesi. Teknik borç kodun içinde durur, okunur, hatta ölçülür. Karar borcu ise verilmemiş bir kararın yerine geçmiş sessiz bir varsayımdır. Kimse onu aramaz, çünkü orada bir şey olduğunu kimse bilmez.

Bir de hız meselesi var. Yapay zekâyla birlikte sorgulanmamış bir varsayım, insan incelemesi ona yetişmeden üç servise ve iki tabloya yayılabiliyor. Üretim hızı arttıkça yanlış kararın etki alanı da daha hızlı büyüyor.

Karar bütçesi

Buradan “daha az karar verin” sonucu çıkmıyor. Kararlar zaten işin kendisi. Çıkan sonuç, kararı sınırlı bir kaynak gibi harcamak.

Kararı bir kez verin ve yazın. Michael Nygard’ın önerdiği mimari karar kayıtları tam bunun için var: kararı, gerekçesini ve elenen alternatifleri kayda geçirmek. Gerekçe yazılmadıysa üç hafta sonra aynı kararı sıfırdan verirsiniz; en pahalı israf yanlış karar değil, iki kez verilen karardır. Her oturumda aynı mimari soruları baştan cevaplıyorsak asıl sebep modelin çok soru sorması değildir. Takım daha önce verdiği kararı hiçbir yere yazmamıştır. Konvansiyonlar, proje şablonları ve modelin her açılışta okuduğu bağlam dosyaları takımın gri tişörtüdür.

Kapının yönüne bakın. Bezos’un tek yönlü ve çift yönlü kapı ayrımı burada işe yarıyor: çift yönlü kapıdan geçip beğenmezseniz geri dönebilirsiniz, tek yönlü kapı ise arkanızdan kapanır. Geri dönmesi ucuz olan kararda hızlı davranın ve tartışmayı kesin. Bütçeyi tek yönlü kapılara saklayın: veri modeli, dış arayüz sözleşmesi, kimlik doğrulama sınırı, para hesaplayan kod.

Yeterince iyiyi seçin. Simon’ın “satisficing” dediği şey, en iyiyi aramak yerine belirlediğiniz eşiği geçen ilk seçeneği alıp yola devam etmek. Çift yönlü kapıların tamamında geçerli: loglama kütüphanesi, test iddia kütüphanesi, biçimlendirme kuralları, dahili bir yardımcının adı. Buralarda kusursuzu aramak hem kararı hem de sonraki pişmanlığı pahalılaştırıyor. Ama her kütüphane seçimini otomatik olarak bu kümeye koymayın; bir ORM ya da serileştirme formatı her yere sızar, geri dönüşü tek yönlü kapı kadar pahalıdır.

Varsayılanı siz koyun. Thaler ve Sunstein’ın Nudge’da anlattığı en sağlam bulgu, varsayılan seçeneğin en güçlü müdahale olduğu: organ bağışında ya da emeklilik planında kutuyu önceden işaretli bırakmak, katılım oranını her ikna kampanyasından daha çok değiştiriyor. Pratikte karşılığı şu: modele “her adımda bana sor” demek yerine “şu varsayılanlarla ilerle, sapacaksan sor” demek. Sorduğu soruların bir kısmının cevabı zaten bellidir. Şu ayrımı kaçırmamak kaydıyla: varsayılan, birinci maddede yazıya geçirdiğiniz karardır. Modelin kendi kafasından ürettiği şey varsayılan değil, varsayımdır.

Varsayımları görünür kılın. Modele kod yazdırmadan önce hangi varsayımlarla ilerlediğini, hangi kararların geri dönüşünün zor olduğunu ve sonucu nasıl doğrulayacağını sorun. Sessiz varsayım, karar borcunun başladığı yerdir.

Kararları oturumun sonunda sahipsiz bırakmayın. Planlama sırasında yeni bir soruyla karşılaşmak başarısızlık değil; soruyu cevapsız ve kayıtsız bırakmak sorun. Her önemli soru için üç sonuçtan biri oluşmalı: karar verildi, gerekçesiyle ertelendi veya bir sahibine atandı. Sessizce geçilen seçenek kısa sürede sessiz varsayıma dönüşüyor.

Yeni ağırlık merkezi

Bu noktada “geliştiricilik bitti” demek kolay. Görünen şey gerçek: klavyeden çıkan karakterin değeri azalıyor. Ama aynı tabloda artan bir şey var; problemi tanımlayan, sınırı çizen ve kararın riskini taşıyan kişinin değeri.

Muhtemelen hepimiz daha az karakter yazacağız. Buna karşılık hangi kararın makineye devredilebileceğini, hangisinin devredilemeyeceğini ayırt etmek işin merkezine oturacak.

Brooks kırk yıl önce en zor kısmın neyin inşa edileceğine karar vermek olduğunu söylemişti. Yapay zekâ diğer parçaları ucuzlattığı için o en zor kısım işin gitgide daha büyük bir bölümünü kaplıyor.

Her gün aynı tişörtü giymek zorunda değiliz. Ama takım olarak hangi kararları çoktan verdiğimizi bilmemiz gerekiyor.

Kaynaklar

Obama ve Brooks alıntıları İngilizce asıllarından çevrilmiştir. Metindeki araştırma ve kitap bağlantıları ilk kullanıldıkları yerde verilmiştir. Bağlantısı olmayan kaynaklar: Baumeister ve Tierney, Willpower (2011); Kahneman, Thinking, Fast and Slow (2011); Thaler ve Sunstein, Nudge (2008); Carr, The Glass Cage (2014); Lewis, “Obama’s Way”, Vanity Fair (2012).