Teknik borç, bilişsel borç, niyet borcu
(martinfowler.com)- LLM’lerin büyük ölçekte kod ürettiği ortamlarda yalnızca kodun kendisiyle ilgili sorunlar değil, ekibin ortak anlayışı ve sistem hedeflerine dair kayıtlar da birlikte zayıflar; bu nedenle bunu teknik borç, bilişsel borç ve niyet borcu olmak üzere üç katmanda ele alma ihtiyacı artıyor
- Technical debt, gelecekte değişiklik yapabilme imkânını sınırlar; Cognitive debt, ekibin sistem değişiklikleri üzerine akıl yürütme kapasitesini zayıflatır; Intent debt ise hedefler ve kısıtların kaydını belirsizleştirerek insanlarla AI ajanlarının sistemi sürekli evrimleştirmesinin önüne geçer
- AI’ı System 3 olarak konumlandıran Tri-System kuramı, dışarıdan üretilen yapay akıl yürütmeye eleştirel olmadan güvenip derin düşünmeyi atlayan cognitive surrender durumunu, bilişi stratejik olarak devreden cognitive offloading ile aynı şey olarak görmez
- Kodlama maliyeti düştükçe pahalılaşan şey verification oluyor; doğruluk ve başarının ölçütleri de trafik ETA’sı, kurye/şoför ataması, yüzlerce mikroservisin işletimi gibi bağlama göre değiştiği için insan yargısı ve doğrulama sistemlerinin tasarımı daha önemli hale geliyor
- Mühendisliğin ağırlık merkezi, uygulama miktarından doğrulamaya kayıyor; bundan sonra da insanlar faydalı soyutlamalar ve adlandırmalar üretme, acceptance criteria ve test harness tasarlama gibi sistemin anlamını elde tutan rolleri üstlenmeye devam edecek
Üç tür borç ve sistem sağlığı
- LLM’lerin büyük miktarda kod ürettiği ortamlarda ekiplerin sistemin ne yaptığını anlama yetisini kaybetmesi kolaylaşıyor; buna Cognitive Debt olarak bakan yaklaşım güç kazanıyor
- Üç sistem sağlığı katmanı, borcu kod, insanlar ve artefaktlar düzeyinde ayırıyor
- Technical debt kodda bulunur; uygulama kararları gelecekte değişiklik yapabilme imkânına zarar verdiğinde birikir ve sistemin nasıl değişebileceğini sınırlar
- Cognitive debt insanlarda bulunur; sistemle ilgili ortak anlayış, takviye edilme hızından daha hızlı zayıfladığında birikir ve ekibin değişiklikler üzerine akıl yürütme yeteneğini sınırlar
- Intent debt artefaktlarda bulunur; sistemi yönlendirmesi gereken hedefler ve kısıtlar doğru biçimde kaydedilmediğinde ya da korunmadığında birikir ve hem ilk başta ne inşa edilmek istendiğinin sürdürülmesini hem de insanlarla AI ajanlarının sistemi etkili biçimde geliştirmeye devam etmesini sınırlar
- Bu yaklaşım, her borç türünü teşhis etme ve hafifletme bölümleriyle birlikte ele alıyor; ayrıca bu üç borcun birbiriyle etkileştiğini de vurguluyor
- Ekiplerin, bu üç borcu kontrol altında tutmak için genel faaliyetleri birlikte yürütmesi gerekiyor
Tri-System kuramı ve bilişsel teslimiyet
- LLM’leri Kahneman’ın iki sistemli düşünme modeline ekleyen makale, AI’ı System 3 olarak konumlandırıp düşünme çerçevesini genişletiyor
- System 1 sezgiyle hızlı karar verirken, System 2 problemler üzerine bilinçli ve kasıtlı düşünme aşaması olarak ayrılıyor
- İnsanlar enerji tasarrufu için varsayılan olarak sezgiye yaslanma eğiliminde olduğundan, yeterince düşünülse fark edilebilecek unsurlar gözden kaçabiliyor
- System 3’ün sonucu olarak cognitive surrender ortaya çıkıyor; bu, dışarıda üretilmiş yapay akıl yürütmeye eleştirel olmadan güvenip System 2’yi baypas etme hali olarak tanımlanıyor
- Makale bunu cognitive offloading ile ayırıyor
- cognitive offloading ise düşünme sürecinde bilişin stratejik biçimde devredilmesi olarak ele alınıyor
- Makale, Tri-System theory of cognition çerçevesini ayrıntılı biçimde geliştiriyor ve en azından laboratuvar ortamında bu kuramın davranış tahmininde ne kadar geçerli olduğunu çeşitli deneylerle test ediyor
Kod ikonu olarak <> gösterimi
- Son dönemde bazı illüstrasyonlar kod ikonu olarak “<>” simgesini kullanıyor, ancak bu gösterim programlama dili öğelerini sarmalayan bir biçim olarak alışılmadık görünüyor
- “{ }” gibi başka semboller yerine “<>” kullanılmasının nedeni, bunun HTML veya XML’i çağrıştırması olarak okunuyor
- “</>” biçimi kullanıldığında HTML çağrışımı daha da doğrudan hale geliyor, fakat HTML genelde programcıların program yazdığı bir dil olarak görülmüyor
Kodlama ucuzladığında pahalılaşan şey doğrulama
- if coding agents make coding free, what becomes the expensive thing, kodlama ajanları kodlama maliyetini düşürdükçe pahalılaşan unsurun verification olduğunu savunuyor
- Doğruluk ölçütü bağlama göre sürekli değişiyor
- Jakarta trafiği için ETA algoritması ile Ho Chi Minh City trafiği için ETA algoritmasında “correct” kavramının anlamı farklı olabilir
- Şoför/kurye atamasında gelir adaleti, müşteri bekleme süresi ve araç kullanım oranını aynı anda dengelemek gerektiğinden “successful” için tek değil birden çok tanım ortaya çıkar
- Yüzlerce mühendisin yaklaşık 900 mikroservise sürekli dağıtım yaptığı bir ortamda “correct”, tek bir tanım olmaktan çıkıp binlerce tanıma ayrışır; bunların hepsi de sürekli değişir ve bağlama bağlıdır
- Bu tür yargılar ajanların devralamayacağı işler olarak kalır
- Ajanlar özellikle sonuçlar için iyi ve mümkünse otomatikleştirilmiş doğrulama olduğunda daha iyi çalışıyor
- Bu tür akışlar Test Driven Development yaklaşımını teşvik ediyor
- Yine de doğrulanması gereken çok şey olduğundan, insanların daha geniş test kapsamını kolayca anlayabilmesine yardımcı olacak yöntemlere daha fazla çaba gerekiyor
- Legacy modernizasyonu konusunda ise bazı karşı görüşler de aktarılıyor
- agentic coding’in legacy modernizasyonunu nihai olarak çözeceği beklentisi abartılı bulunuyor
- Buna karşılık, understanding what legacy code is doing açısından LLM’lerin büyük fayda sağladığına dair güçlü kanıtlar var
Doğrulama merkezli organizasyona geçiş
- Ajanlar icrayı üstlendikçe insanların işi verification system tasarımı, quality tanımı ve ajanların çözemediği belirsiz durumları ele alma yönüne kayıyor
- Organizasyon yapısının da bu değişime uyum sağlaması gerekiyor
- Pazartesi sabahı yapılan stand-up toplantılarında soru, “Ne dağıttık?”tan çok “Neyi doğruladık?” oluyor
- Çıktı miktarını takip etmekten ziyade sonucun doğru olup olmadığı izleniyor
- Eskiden özellik geliştiren 10 mühendisten oluşan bir ekip, 3 mühendis ve acceptance criteria tanımı, test harness tasarımı ile outcome monitoring üstlenen 7 kişiden oluşacak şekilde yeniden yapılandırılabilir
- Bu tür bir yeniden yapılanma, üretme eyleminin statüsünü düşürüp yargılama eyleminin statüsünü yükselttiği için rahatsız edici gelebilir
- Bu değişime direnmeyen mühendislik kültürlerinin daha başarılı olma ihtimali yüksek
Kaynak kodun geleceği ve LLM dostu diller
- LLM’leri programcı gibi ele alan akış güçlendikçe kaynak kodun geleceği de başlı başına bir soru haline geliyor
- several views of the future of code, kodun geleceğine ilişkin farklı bakış açılarını bir araya getiriyor
- Bazıları LLM’ler gözetilerek tasarlanmış tamamen yeni dilleri deniyor
- Başka bir görüş ise mevcut dillerin, özellikle TypeScript ve Rust gibi katı tipli dillerin, LLM’lerle daha uyumlu olabileceğini savunuyor
- Yazı çok sayıda alıntı içeriyor ve kendi analizini sınırlı tutuyor; yine de tartışmanın genelini görmek için iyi bir genel bakış niteliğinde
İnsanların üstleneceği soyutlama ve adlandırma işi
- LLM’lerle birlikte yazılım üretme sürecinde de insanlar, kodun ne yaptığını konuşmayı mümkün kılan faydalı soyutlamaları üretme rolünü sürdürmeye devam edecek
- Bu, DDD’deki Ubiquitous Language kavramıyla bağlantılı
- growing a language, LLM’lerle birlikte dili büyütme yaklaşımını ele alıyor
- Programlama, yalnızca bilgisayarın anlayıp çalıştırabileceği kod sözdizimini yazmak değil, aynı zamanda çözümü biçimlendirme işi
- Bu süreçte problemler odaklı parçalara ayrılır, ilgili veriyle davranış bir araya getirilir ve niyeti açığa çıkaran adlar seçilir
- İyi isimler karmaşıklığı keskin hatlarla ayırır, kodu herkesin takip edebileceği bir şemaya dönüştürür ve problem yapısıyla çözüm yapısı arasında daha net bir bağ kurar
3 yorum
"Niyet borcu" terimi, benim zamanında kendi çapımda tanımladığım bir terimdi; onu burada tekrar görmek hoşuma gitti. Sanırım insanların düşündükleri şeyler birbirine oldukça benziyor.
Blog yazısı: https://brunch.co.kr/@limjk/2
Değişime uyum sağlamak için organizasyonu hızla yeniden yapılandırmak da bana biraz muhafazakâr bir yaklaşım gibi geliyor ve bu yüzden ters etki yaratıyor.
Hacker News görüşleri
Dağıttığım şeylerin tamamını derinlemesine anlamadan içi rahat etmeyen biriysem, bu tür değişiklikler oldukça tedirgin edici geliyor
Artık 2 ay sürecek bir modernization projesi bile, tüm iş mantığını didik didik inceleyip birebir kopyalamaya çalışmak yerine sınırları ve arayüzleri iyi tasarlamaya odaklanılırsa yaklaşık bir haftada bitebiliyor
Ve yazıda dendiği gibi, iyi bir test harness kurup mümkün olduğunca eşdeğerliği doğrulamak yeterli
Ben de başta epey ikilem yaşadım ama düşününce, her gün bakımını yaptığım diğer sistemlerin iç uygulamasını ya da iş mantığını da aslında o kadar iyi bilmiyordum
Yıllar önce yazıp neredeyse hiç el sürmediğim kod olduğu için, bir şeyi değiştirmem gerektiğinde sonuçta ya test suite'ine güveniyor ya da kod yapısını takip ederek belirli davranışı anlamaya çalışıyordum
İşten çıkarmalar veya maliyet kısma dönemlerinde de, böyle bilgiye çok sahip kişilerin diğerlerinden daha uzun süre ayakta kaldığını defalarca gördüm
Acaba gözden kaçırdığım bir şey mi var
LLM'lerde tembelliğin erdemi hiç yok değil
Niyetine uygun bir temel prompt verirseniz, Claude tabanlı bir ajanın kod değişikliklerini en aza indirmesini, tekrarları giderme geçişi yapmasını ve oldukça kıdemli bir geliştirici içgüdüsü gibi görünen davranışlar sergilemesini gayet iyi sağlayabildim
Bence model bu bilgiyi hiç öğrenmemiş değil; sadece varsayılan ayarlarda ön planda değil
Tüm kod tabanını rastgele kurcalayan, başkalarının değişikliklerini ya da bilgi kaybı riskini hiç umursamayan aşırı düzenleme tarzı modelleri hepimiz görmüşüzdür
Doküman üretimi ve doğrulama meselesi de sonuçta geleneksel locking problemine benziyor ve bunun geleneksel çözümleri var
Ajan git'i okuyup neyin önce geldiğini, gelenek gereği başka değişiklikleri bekleme durumunda olup olmadığını fazlasıyla anlayabilir
Ben de oldukça kıdemliyim ve bu yazıda geçen bazı kişilerle gerçekten aynı takımda da çalıştım
O insanların benim mühendislik standartlarımdan şüphe edeceğini sanmıyorum
Ama benim LLM iş akışımda bu tür borçları neredeyse hiç görmedim; hatta eski standartlarla baksam bile proje kalitesinin 5 yıl, 10 yıl öncesine göre daha iyi olduğunu hissediyorum
Bu sihir değil; sadece kalite önceliklerini paylaşan ajanları iyi çalıştırmak gerekiyor
Ve ben konferanslarda ilgi çekmeye çalışmaktan çok gerçek işi çıkarıyorum
Ama geleneksel yazılım kalite metrikleri açısından bile 5 yıl, 10 yıl öncesinden daha iyi olduğu kısmı fazla muğlak geliyor
Hangi metrikleri kullandığınızı ve 10 yıl önceki, 5 yıl önceki ve şimdiki kodun bunlara göre nasıl karşılaştırıldığını daha somut duymak isterim
Böyle bir açıklama olmayınca mesaj biraz bulanıklaşıp asıl noktadan uzaklaşıyor gibi geliyor
Paylaşabileceğiniz daha fazla şey varsa gerçekten merak ederim
Practical LLM Coding gibi bir başlıkla kitap bile yazabilirsiniz
Buradaki en az takdir edilen şeyin intent debt çerçevesi olduğunu düşünüyorum
Bilişsel borç ya da teknik borç en azından kodda iz bırakır ama intent debt görünmez
Bu yüzden yerel olarak mantıklı ama genel ölçekte yanlış bir değişiklik girince ancak o zaman ortaya çıkar
Çünkü asıl kısıt hiçbir çıktıda kayıtlı değildir
En zor durum, kurumsal sistemlerde bu kısıtın düzenleyici bir gereklilik olması ama 3 yıl önce sessizce değişmiş ve kimsenin kodu güncellememiş olmasıdır
Testler geçmeye devam ettiği için bunu kaçırmak daha da kolay olur
Test suite tek başına niyeti geri getiremez
Martin'in tamamen haksız olduğunu düşünmüyorum ama bu mantık, soyutlama katmanı her yükseldiğinde öne sürülebilecek bir argüman gibi geliyor
Onun tanımına göre Assembly'den Python'a geçiş de muazzam miktarda intent debt ve cognitive debt üretiyor olurdu
Çünkü bitleri nasıl işleyeceğimizi doğrudan düşünmek yerine bunu yorumlayıcıya bıraktık
Benim itirazım şu: onun teknik niyet dediği şey sonuçta insan niyetini makine diline çevirmek zorunda olduğumuz için ortaya çıktı
Bir problemi derinlemesine düşünmek için kod içinde mutlaka alan odaklı soyutlamalar kurmak gerekmiyor
Zihin haritası çizerek, günlük yazarak ya da duvara post-it yapıştırarak da derin düşünebilirsiniz
Nesne yönelimli soyutlama kendi başına sihir değil
Bu süreçte belirsizlikler, gözden kaçan ayrıntılar, hatta yaklaşımın kendisini yeniden düşünme gerekliliği bile ortaya çıkabilir
Doğal dille yazmak da bir düşünme aracı olabilir ama düşünceyi belirsizliğe izin vermeyen biçimsel bir dile uydurmakta özsel olarak farklı bir taraf var
Bu, matematiği semboller olmadan yalnızca doğal dille yapmanın hantal ve hataya açık olmasına benziyor
Sadece bunu insanların anlaması daha kolay bir dilde yapıyoruz
Niyet ile uygulama arasında doğrudan bir eşleme vardır
Çünkü eşleme iyi tanımlıdır ve deterministiktir
Soyutlamanın amacı, altını yeniden açmadan da yaptığımız şeyin hâlâ doğru olduğuna güvenebilmemizi sağlamaktır
Bunun nedeni, benim ya da güvendiğim birinin o maliyeti bir kez ödemiş olmasıdır
Ama LLM'lerde üretim her seferinde doğrulanmak zorundadır ve o borcu her defasında yeniden ödersiniz
Bu yüzden buna soyutlama demek zor
Yazı gerçekten çok iyi yazılmış
Ben de dün kişisel notlarımda, kodu organik biçimde sürekli geliştirmiyorsanız ona gerçekten sahip olduğunuzu söylemenin zor olduğunu yazmıştım
Sanki otonom araç kullanmak gibi; eskiden en azından yol üzerindeki manzarayı hatırlıyordunuz, şimdi ise doğrudan başka bir yere ışınlanıp size sadece kaydı izletiyorlar gibi
Bu tür review'lerin etkisi düşük oluyor
Küçük araçlarda bu tür ghosted code kabul edilebilir olabilir ama veritabanı gibi sistemlerde gerçekten endişe verici
Bu yüzden artık ajanlara neredeyse hiç yazma izni vermiyorum ve 2 yıl önceki gibi manuel QA ağırlıklı yaklaşıma geri döndüm
Hatta token kullanımı ve sonuçlar açısından da o taraf daha verimli oldu
Tabii bu tamamen benim deneyimim
Ne yazık ki onun bağlantı verdiği Wharton makalesinin büyük kısmı AI ile üretilmiş gibi görünüyor ve henüz peer review'dan da geçmemiş
Bugünlerde araştırmacıların yazım için AI desteği kullandığını biliyorum ama makalenin konusu bir de cognitive surrender olunca, içeriği ciddiye almak zorlaşıyor
not merelyifadesini tam 7 kez kullanıyorLLM bu kadar aynı ifadeyi tekrar eder mi emin değilim; hatta yazarın LLM gibi yazma alışkanlığı edinmiş olması da mümkün diye düşündüm
Martin tamamen haksız değil ama ben AI'ın tembel kod ürettiği durumları doğrudan gördüm ve orada doğru cevap aslında daha fazla kod yazmaktı
Somut olarak, belirli bir mantıksal kavram kümesi için veritabanı şemasını tanımlayan Python modelleri vardı
Buna mevcut mantık kümelerine çok benzeyen yeni bir kavram eklendiğinde, Claude mevcut model setini yeniden kullanmanın yeterli olduğuna karar verdi
Teoride çalışıyordu ama gerçek tüketici tarafında çalışma zamanı tür çıkarımı yüzünden türlü türlü dolambaçlar gerekiyordu
Çalışsa da soyutlama katmanı tamamen yanlış seçilmişti
İnsanlar olarak soyutlama istiyoruz ama bazen tekrar etmek daha doğru olabiliyor
Eğer kodu makine yazıyor ve bakımını da makine yapıyorsa, eskiden gerekli olan ek soyutlama katmanları artık şart olmayabilir
Eskiden Duff's device kullanır, döngüleri elle unroll eder ve yinelenen kodu bilerek üretirdik
Şimdi derleyiciler niyeti anlayıp tekrarlayan assembly'yi kendileri üretiyor ve biz bu tekrarlarla uğraşmıyoruz
Yakın zamanda LLM ile epey sıradan olmayan birkaç hesaplamalı geometri kod parçasına ihtiyacım oldu; eskiden bir kütüphane bulmak, uyumluluk onayı almak ve kendi alan verisi yapılarını o kütüphanenin biçimine dönüştürmek gerekirdi
Bu, doğrudan implementasyondan daha ucuz olsa da hiç de önemsiz bir maliyet değildi
Artık LLM bana sadece gereken kısmı yazabiliyor ve kullandığım veri biçimini aynen koruyabiliyor
Büyük bir kütüphane eklemek gerekmiyor, veri yapısı dönüşümüne de ihtiyaç kalmıyor
Teoriye göre geometry library kullanıp tekrarları önlemek daha doğru olabilir ama burada kendi kendine yeten tek bir fonksiyon gayet iyi çalışıyor
Uzun zamandır Hacker News'te okuduğum en iyi şeylerden biriydi
Çok güçlü biçimde katılıyorum
Simon Willison'ın dediği cognitive debt ve “çalıştığını kanıtladığın kodu dağıtmak senin işin” yaklaşımı nedeniyle ben de Intent-Driven Development yönünde bir proje üzerinde çalışmaya başladım
Önceki niyet, değişiklikler biriktikçe her zaman silikleşiyor gibi görünüyordu
Bunu gerçek bir protokole dönüştürüp sonra Hacker News'te paylaşabilirim belki
Yazılarımı henüz görmediyseniz bakmanızı öneririm
Özeti şu
Şu anda problemi zihnimde görselleştirme biçimim bu diyagrama daha yakın: https://excalidraw.com/#json=y1fSSx2z8-0nFs7CDnqhp,d9Di8JdGU...
Yazılım mühendisliğindeki bilişsel darboğazın kodun içinde değil, çıktılar arasında olduğunu düşünüyorum
Kod bunlardan sadece biri
outcome → requirements → spec → acceptance criteria → executable proof → review
Ben bu geçişler arasındaki sıkıcı kısımları otomatikleştiren ve her aşamada niyetin hayatta kalıp kalmadığını doğrulamaya insanların odaklanmasını sağlayan deneysel araçlar geliştiriyorum
Buraya eklemek isteyeceğim bir katman daha proxies/metrics olurdu
Analiz ağırlıklı sistemlerde asıl kayıp çoğu zaman spec → code değil, question → proxy geçişinde yaşanıyor
Proxy acceptance criteria'ya, dashboard'lara ya da eval'lere gömülünce insanlar onu optimize etmeye başlıyor ve bunun sadece vekil bir metrik olduğu giderek unutuluyor
Telefonda pan/zoom/scroll yapmaya çalışırken sürekli canvas öğelerini oynatıyorum