Kule Yükselmeye Devam Ediyor

• Vibe coding ile üretilen yazılımların rastgele ve beklenmedik biçimlerde değişmesi, ortak dili kaybedip inşaatı duran Babil Kulesini andırıyor; ancak yapay zeka çağında, anlayış çöktükten sonra bile inşaatın sürmesiyle ayrışıyor
• Büyük ölçekli yazılımların sınırı yalnızca bireylerin kod üretim hızıyla değil; kavramlar, sınırlar, değişmez koşullar, sahiplik ve tasarımın gerekçesi etrafındaki paylaşılan anlayışın ne kadar iyi koordine edildiğine de bağlı
• Kod keşfi, soru sorma, inceleme ve ekipler arası görüşmelerde ortaya çıkan sürtünme, bir yandan israf olsa da diğer yandan karşılıklı anlayışı senkronize etme ve sistem üzerindeki mutabakatı doğrulama süreciydi
• Ajanlar OAuth ekleme, caching, veritabanını yeniden kurma gibi işleri konuşma olmadan paralel biçimde yürütüyor; her değişiklik makul ve testlerden geçiyor olsa bile insanların ortak modeli zayıflayabiliyor
• Yapay zeka destekli mühendislikte ajanlar her alanı yorumlayıp değiştirerek anlık bir başarısızlık olmadan inşaatı sürdürdüğü için, insanların sistemi birlikte akıl yürüttüğü mimari dilin kaybını fark etmek zorlaşıyor

---

Babil Kulesi'nin gücü teknolojiden çok koordinasyondaydı

• Bazı vibe coding yazılımlarının biraz rastgele ve beklenmedik şekillerde değişmesi, Bruegel'in The Tower of Babel tablosunu hatırlatıyor
• Babil Kulesi hikayesi çoğu zaman kibir, hırs ve insanların neden farklı diller konuşmaya başladığının açıklaması olarak yorumlansa da, aynı zamanda teknolojik ilerlemeyi mümkün kılan birlikteliği de gösteriyor
• Yaratılış 11:3-6 (KJV) bölümünde insanlar taş yerine pişmiş tuğla, harç yerine zift kullanarak teknik bir ilerleme sağlıyor ve göğe ulaşan bir şehirle kule inşa etmeye girişiyor
• Tanrı'nın sorun olarak gördüğü şey tuğlalar ya da üretim bilgisi değil, insanların tek bir halk olması ve tek bir dili paylaşmaları sayesinde hiçbir şeyle sınırlanmamalarıydı
• Ortak bir dille herkes kendi işini birleştirdiğinde, hiç kimsenin tek başına yapamayacağı şeyler inşa edilebilir
• Kaybolan şey tuğla ya da üretim yöntemi değil, birbirlerini anlama yeteneğiydi; bu kaybolunca koordinasyon imkansızlaştı ve inşaat durdu

Yapay zeka ajanları sürtünmeyi kaldırdıktan sonra da yükselmeyi sürdüren kule

• Yapay zeka destekli programlama, bireylere daha güçlü araçlar sunuyor ve ajan kullanan geliştiriciler kod tabanında çok daha büyük kapsamlı değişiklikler yapabiliyor
• Ancak büyük projelerin sınırı yalnızca bireyin kod üretme hızı değil, insanların değişiklik yapılan sisteme dair anlayışlarını ne kadar iyi koordine edebildiğine de bağlı
• Yazılım projelerinin ortak dili İngilizce ya da Python'ın kendisi değil, şu unsurlara dair ortak anlayıştır
  • Her kavramın ne anlama geldiği
  • Sistem sınırlarının nerede olduğu
  • Hangi değişmez koşulların önemli olduğu
  • Kimin neyden sorumlu olduğu
  • Sistemin neden mevcut yapısına sahip olduğu
• Bu anlayış tek bir yerde eksiksiz biçimde kayıtlı değildir; yalnızca dokümanlarda ve kodda değil, kod incelemelerinde, sohbetlerde, tartışmalarda ve yapılan değişiklikleri başkalarına açıklama deneyiminde de birikir
• Ajanlardan önce, başka birinin storage katmanını değiştirmek için çoğu zaman kodu okuyup soru sormak ve bağımlı servisleri işleten başka ekiplerle görüşmek gerekirdi
  • Bu süreçte israf da vardı, ama aynı zamanda bir kişinin anlayışının diğerine aktarılmasını ve iki tarafın da sistemin nasıl çalıştığı konusunda hâlâ uzlaşıp uzlaşmadığını doğrulamasını sağlıyordu
  • Bu sürtünme, insanların anlayışını senkronize ediyordu
• Ajanlar bu sürtünmeyi büyük ölçüde azaltarak, birden fazla kişinin birbiriyle konuşmadan farklı değişiklikler istemesine imkan veriyor
  • Biri OAuth ekleyebilir, bir başkası caching koyabilir, bir diğeri veritabanını baştan kurup UI'ı pembe yapabilir
  • Bu değişikliklerin her biri bağımsız olarak makul olabilir; kod derlenebilir, testlerden geçebilir ve gerektiğinde açıklama bile üretebilir
  • Kimsenin başkalarıyla konuşması ya da geçmişte bu değişiklik sürecinde öğreneceği paylaşılan modelin bir parçasını edinmesi gerekmez
• Ajanlar acı hissetmez; acıyı yalnızca insanlar hisseder ve bu sayede daha önce başkalarının yardımını gerektiren sistem alanları ile kod tabanında da değişiklik yapılabilir
• Ölçeği büyüyen vibe coding projeleri, iletişim kuramadıkları için değil, iletişim kurma gereği ortadan kalktığı için Babil Kulesi benzeri kod tabanlarına dönüşüyor
  • Her geliştiricinin elinde kulenin belirli bir bölümünü açıklayan ve istenen yerel değişikliği yapan, yorulmak bilmeyen bir çevirmen var
  • Değişiklikler uygulanmaya devam ederken, insanların sistemi birlikte akıl yürütmesini sağlayan mimari dil ortadan kaybolabiliyor
• Kutsal Kitap'taki Babil Kulesi'nde ortak dilin kaybı inşaatı durdurmuştu; ancak yapay zeka destekli mühendislikte paylaşılan anlayış çöktükten sonra bile inşaat sürebilir
• Kule çökmediği ya da anında bir başarısızlık yaşanmadığı için neyin kaybedildiğini fark etmek zordur ve kule yükselmeye devam eder

[GN⁺]

Hacker News görüşleri

• Yazılımın birleştirilebilirliğinin Tetris’teki gibi satırların temizlenmesini gerektirdiğini uzun zamandır düşünüyorum. Acenteleri acemice kullanan ya da deneyimi az mühendisler bu tür düzenlemeyi kaçırıp kuleyi sadece daha da yükseltme eğiliminde oluyor
  Acentelerin mevcut öğeleri daha iyi soyutlamalarla yinelemeli biçimde birleştirmesi sağlanabilir, ancak Fable ya da 5.6 Sol bile yazılımın incelikli evrimini öngören üst düzey mimari sezgi konusunda hâlâ insanın epey gerisinde. Mevcut sistemler, insanların sahip olduğu yüksek kaliteli, seyrek ama ölçeklenebilir dünya modelini yeterince koruyamıyor gibi görünüyor; ama farkın artık bu kadar ince bir düzeye kadar daralmış olması bile umut verici

  • Kanıtlayamam ama, gelecekteki değişiklikleri hesaba katan soyutlamalar için gereken mantık ve sezginin yalnızca tahmin edilen token dizileriyle gerçekleştirilemeyeceğine güçlü biçimde inanıyorum. Ölçülemeyen bir şey eksik
  • Geçmişte insan zihninin kapasitesi program karmaşıklığının üst sınırıydı ama vibe coding bu bariyeri aşabilir. Sorun yazılımın gerçekten o kadar karmaşık olması değil, geliştirme sürecinin özlü soyutlamalara yakınsamaması
    Bu, Brooks’un 《The Mythical Man-Month》 eserinde ele aldığı ölçeklenme sorununun AI sürümü gibi; ölçek büyüdükçe kombinatoryal patlama kötüleşiyor ve projenin çeşitli yerlerinde fiilen aynı işlevi yapan kodlar yineleniyor. AI tabanlı kodlamayı özlülüğü hedefleyecek şekilde yönlendirmenin bir yolu gerekli
  • İnsanların bağlam penceresi bugün LLM’lerinkinden çok daha küçük olabilir. Bu kısıt, işi zihinde tutulabilir kılmak için modülerleştirme ve soyutlamaya zorlaması bakımından aslında faydalı; çok daha fazla şeyi aynı anda tutabilen LLM’lerde ise aynı teşvik yok, bu da acentelerin toparlanmamış spagetti kod üretmesine yol açıyor
  • Sonuçta bu sadece zaman meselesi. gpt2 ya da llama2, bugünkü modellerle kıyaslandığında şok edici derecede kötüydü ve o zaman bile fiilen işe yaramazdı, ama biz yine de etkilenmiştik
    Bir zamanlar coşkuyla karşıladığımız GPT3.5 ve gpt4 bile artık qwen27b ya da gemma31b karşısında ciddi biçimde geride kalıyor. Yeterli zaman ve doğru pekiştirmeli öğrenme (RL) verilirse modeller de zihinlerinde mükemmel yazılım sistemi modelleri kuracaktır
  • Acaba bunun nedeni, LLM’lerin kısa zaman ufuklu görevleri çözmek üzere pekiştirmeli öğrenmeyle eğitilmiş olması mı? Test geçme görevlerinin aksine, yıllara yayılan emek, temiz mimari ve iyi sezgi kıyaslamalarla maksimize edilmesi kolay şeyler değil

• Bu yazının ana argümanı bana Lisp Curse ve Bipolar Lisp Programmer’ı hatırlatıyor. Argüman şuydu: Lisp, bireyin istediğini fazla kolay yapabilmesini sağladığı için programcıların işbirliği yapıp genel amaçlı ve karmaşık ürünler inşa etme motivasyonu zayıflıyor; bu yüzden de kamuya açık yazılım ekosistemi, ciddi emek gerektiren dillere göre daha yoksul kalıyor
  Armin de AI kodlama konusunda çok benzer bir argüman öne sürüyor gibi görünüyor: Lisp Curse, Bipolar Lisp Programmer

  • Assembly programcıları da aynı argümanı savunuyordu. Yazılım mühendisliği her paradigma değişimi yaşadığında tekrarlanan bir kanaat bu ve bazı insanlar bu geçişleri başkalarına göre daha zor yaşıyor
  • Bunun gerçekten aynı argüman olup olmadığından emin değilim. Artık bir araya gelip işbirliği yapmaya gerek kalmadan sadece bir ajan sürüsü seferber ederek hayal edilen herhangi bir karmaşık yazılımı üretebileceğine inanan yeterince çok insan var
  • Hatta TypeScript ve Rust piyasayı ele geçirmemiş olsaydı, şimdi Lisp için LLM sürücüsü olmak adına iyi bir dönem olabilirdi. Bugünün ajanları artık neredeyse hiç halüsinasyon üretmeden çoğu şeyi açıklayabiliyor; anlamaya niyet varsa, anlama eşiği fiilen ortadan kalkıyor ve yazının ana fikri de bu zaten
  • Başka dillerin aynı sonucu elde etmek için “çok daha fazla emek” gerektirdiği varsayımı açık değil. Birçok Lisp dışı geliştirici sözdizimine önem verirken Lisp geliştiricileri vermiyor ve Lisp ile düşüncelerinin genişlediğini deneyimledikten sonra bile Lisp’i tercih etmeyen çok kişi var
    İki grup arasında farklı bilişsel işleme biçimleri olabilir. Lisp’in diğer diller kadar üretken olabilmesi için homoiconicity’yi etkin biçimde kullanmak gerekir; bunun sonucu olarak ciddi Lisp programları, çoğu zaman yalnızca bir ya da iki kişinin anladığı alan özel dilleri (DSL) topluluğuna dönüşür

• Büyük ölçekli yazılım projelerinin sınırı, bireylerin ne kadar hızlı kod üretebildiği değil, sistemi değiştiren kişilerin o sistem hakkında ortak bir anlayışı ne kadar iyi koordine edebildiğidir. 30 Kasım 2022'den sonra her şeyin daha karmaşık hale geldiğini söylemek isabetli

  • Yazılım, katman üstüne katman eklenerek aşırı karmaşıklaştı; bunu yönetmek için de çok daha fazla karmaşıklık üreten araçlar kullanıyoruz. 1990'larda ve 2000'lerin başında, resmî eğitim olmadan bile Visual Basic ya da PHP ile güçlü uygulamalar yapılabiliyordu, ama bugün web ya da masaüstü geliştirme ezici derecede karmaşık ve React'i düzgün kullanmak için bile bilinmesi gereken şey çok fazla
    Buna bir de AI eklemek, mevcut karmaşıklığın üstüne bir karmaşıklık daha bindiren bir hata sayılabilir. İyi tarafından bakılırsa devasa bir donanım israfı, kötü tarafından bakılırsa ise ajanlar hata düzelttikleri kadar yeni hata üretip kırılgan çöp yazılımları çoğaltırken insanların teknik beceri öğrenmemesi yüzünden insanlığın toplam kapasitesinin zayıflaması olabilir. Yazılımın özünde bu kadar karmaşık olması gerekmiyor; çözüm için zanaatkârlığa değer vermek gerekiyor
  • Bir sistemi değiştirmeden önce onu anlamak gerektiği yeni bir fikir değil. Peter Naur'un Programming as Theory Building metni zaten 1980'lerde ortaya çıkmıştı; bunu okumamış olsanız bile, usta geliştiriciler arasında sistem anlayışının vazgeçilmez olduğu zaten sağduyu düzeyinde biliniyordu
  • Her şey daha karmaşık hale gelmiş de değil. Başlıca veritabanları artık kullanışlı yüksek erişilebilirlik araçları içeriyor, mikroservisler geri çekiliyor ve NoSQL yerine yapılandırılmış veritabanları geri dönüyor
    HTML ve önceden render etme de HTMx ve LiveView ile geri döndü; CSS de geçmişin tuhaf geçici çözümlerinden sıyrıldı. IE6'da web sayfası debug etmeyi genç bir meslektaşa anlatınca çağ farkı hissediliyor. Bazı şeyler karmaşıklaştı ama başka bazı şeyler yeterince olgunlaştığı için sadeleşti
  • “30 Kasım 2022'den sonra” değil, MÖ 2022'den beri her şeyin daha karmaşık hale geldiğini söylemek gerekir. Karmaşıklığın artışı aslında insan uygarlığının tarihidir
    MÖ 20 bin yılındaki insan yiyecek bulup soğuktan ve yırtıcılardan kaçıyordu; ama MÖ 5 bin yılındaki insan tarım yapıyor, yağmur ve hastalık hakkında kaygılanıyor, topluluğu ve toprağı yönetmek için sistemler kuruyordu. Bugün çoğu insan yiyeceğini doğrudan yetiştirmiyor, bunun yerine büyük toplumların karmaşıklığını yönetiyor. 1970'ler ve 80'lerden bir geliştiriciye göre, LLM öncesi yazılım bile son derece karmaşıktır; artık neredeyse hiç kimse soyutlama katmanları olmadan doğrudan donanıma kod yazmıyor. Kriptografide bile kütüphaneler karmaşıklığı gizliyor ve “kendin uygulama” deniyor. Artık asıl soru, LLM'nin değiştirilecek sistem hakkındaki anlayışı ne kadar hızlı koordine edebildiğidir

• Bir yazılım projesinin ortak dili İngilizce ya da Python değil; kavramların anlamı, sınırları, değişmez koşulları, sahiplik yapısı ve sistemin neden bugünkü biçimine geldiği konusunda paylaşılan anlayıştır. Christopher Alexander'ın Pattern Language yaklaşımı tam da bu sorunu ele alıyordu ve her alan için uygun bir örüntü dili oluşturmayı önermesi, sonradan meşhur GoF Design Patterns'e uzandı
  Her projede iş, ürün ve teknik alanlar için üç ayrı örüntü dilini AI'nin korumasını sağlayan bir özelliği deniyorum ve çok iyi çalışıyor. Planlama sırasında buna başvurup uygulama ve inceleme sırasında da düzenlettiğimizde, %100 AI ile kodlanmış projeler bile sistemli, alanlar arası hizalaması güçlü ve yönetmesi kolay hale geldi

  • Gerçek bir örnek merak ediyorum. Kodun olgunlaşma sürecinin bir şehrin doğal büyümesine benzediği anlatısını birçok kez duydum ama somut sonuç görmedim
  • Herhangi bir açık GitHub örneği var mı diye merak ediyorum

• Babil Kulesi'nde ortak dil kaybolunca inşaat durur, ama AI destekli geliştirmede paylaşılan anlayış çöktükten sonra bile inşaat sürer. Yazar bunun iyi mi kötü mü olduğunu açıkça söylememiş, ama bunun açıkça kötü bir şey olduğunu düşünüyorum
  Domatesin meyve olduğunu bilmek zekâysa ve onu meyve salatasına koymamak bilgelikse, AI bilgeliği hiç olmayan zekânın nihai biçimi, hatta fiilen zekâ yanılsamasına daha yakın bir şeydir. AI'nin ne yaptığını anlayacak kimse kalmadıysa durmalı ve yaptığımız şeyi kontrol edecek bilgelikten yoksun olduğumuzu kabul etmeliyiz

  • Yazarın vaaz vermek yerine görselin kendi başına anlam taşımasına izin vermesi hoşuma gitti. Tarihte birebir tekrar olmaz ama kafiye hep tutar
  • “Domatesin meyve olduğunu bilmek zekâdır” gibi çocukça klişeler, insanı yanıltma amacı yoksa kullanılmasa daha iyi olur. Sınıflandırmayı ve bağımlılık ilişkilerini anlamak zaten yeterince zor bir problem; ayrıca süpermarket ya da Nix v. Hedden vergilendirme ölçütlerinde domates sebzedir

• Ben de Babil'i ve Bruegel'in resmini düşünüyorum, ama çok daha az iyimser biçimde. Miyop küçük ajanlar, kavranamayacak kadar büyük bir bütünün kendi parçalarını geliştiriyor; bir tarafta 50 mazgal duvarı var, öbür tarafta tuhaf çıkıntılı bir kule yükseliyor, nedenini bilmeden iç avlunun üstüne kerpiç bir çatı, yan taraftaki sahanlığa da saz çatılı bir kule ekleniyor
  Tek tek tasarım kararları düzeyinde bunların hepsi makul olabilir, ama bütün girişimi bir arada tutan çok katmanlı politika ve muhakeme olmayınca ortaya tasarımın devasa bir canavarı çıkıyor. Yeterince büyük organizasyonlarda ortak dili kurup sürdürmek için disiplin gerektiği, başarılı şirketlerin ve orduların kendine özgü terminolojilerinde de görülüyor. “Gastown Mayors”, onların altındaki “polecats” ve daha aşağıdaki golemler aynı dili konuştuklarını sanırlar, ama her şey tamamlandıktan sonra, tahtta oturan kişinin kusursuz biçimde aktardığını sandığı anlayışın aslında hiç paylaşılmadığı anlaşılacaktır

• Anakin: “Ajan kullanan geliştiricilerin kod tabanını değiştirme kapasitesi dramatik biçimde artacak”
  Padmé: “Daha iyi yönde, değil mi?”
  Anakin: sessizlik
  Padmé: “Daha iyi yönde, değil mi?”

• Vibe coding'de üretilen kodu okumayın denmesinin sebebi galiba, Python dosyasının içinde sinsice bekleyen dehşeti bir kez görünce unutamamanız. Geniş anlamda istendiği gibi çalışıyor, ama hedefe ulaşma yöntemini seçtiği her noktada tutarsız kararlar veriyor
  Sadece bazı kullanıcı girdilerine tuhaf doğrulamalar uyguluyor, hiçbir neden olmadan veriyi üç ayrı aşamada yeniden sıralıyor ya da küçük harfe çeviriyor, hatta girdi CSV'sinin ilk satırındaki sütun adlarını bile tamamen string olarak hardcode ediyor. Yarısında veri sınıfları alan global fonksiyonlar yazıyor, kalan yarısını ise sınıf olarak kuruyor. Bir gün bunu sizin bizzat güncelleyip bakımını yapmanız gerekeceğini düşününce düzeltmeden bırakmak zorlaşıyor; ama böyle düzeltmeye başlayınca da kazanılmış zamanın önemli bir kısmı ortadan kayboluyor

• Ajan tabanlı programlama, gerçek programlamadan çok yönetim işine daha yakındır. Yönetici, bireysel katkı sağlayanların ne yaptığını yalnızca yüksek seviyede kavrar; tüm ayrıntıları anlamaya yetecek zaman, bilişsel kapasite ya da yetkinliğe çoğu zaman sahip değildir
  Daha fazla yazılım ajanlar tarafından yazıldıkça, yazılım mühendisinin rolü teknik bir pozisyondan çok yönetsel bir pozisyona yaklaşacaktır

  • Programcılar için de durum aynıdır. Bireysel katkı sağlayanların çoğu, çalıştıkları katmanın altında neler olup bittiğini bilmez; kütüphanelerin, framework'lerin, uzak API'lerin ve sistem çağrılarının iç uygulamasını tamamen kavrayamaz
    Her şeyi anlamaya zamanları ve kapasiteleri olmadığı için, yalnızca soyutlanmış kendi katmanlarında gereken işleri yaparlar
  • Bütün gün junior geliştiricinin kodunu inceliyormuş gibi hissettirdiği için neredeyse hiç kullanmıyorum; daha çok benim gözden kaçırdığım noktaları bulmak için kullanıyorum

• Geçmişte büyük ölçekli refactoring ciddi emek gerektirdiği için bunun için güçlü bir gerekçe lazımdı. Artık prompt biraz belirsizse ve sonuç düzgün incelenmezse, ajan kodun yarısını yeniden yazabiliyor; bu yüzden programın ruhu her gün büyük ölçüde değişebilir. Bu hem harika bir şey, hem de hiç öyle değil

  • Büyük ölçekli refactoring'in önündeki en büyük engel aslında iş yükünün kendisi değil, bug riskini en aza indirmek, işlevleri korumak ve mevcut ekosistemle uyumluluğu garanti etmekti. Yapay zeka çağında bunun daha kolay hale gelmesinin nedeni, artık bunları eskisi kadar umursamıyor olmamızdır