Ajan Çağında Edebî Programlamayı Yeniden Değerlendirmeliyiz

 (silly.business)
14 puan yazan GN⁺ 2026-03-11 | 2 yorum | WhatsApp'ta paylaş
  • Kod ile doğal dilde açıklamaları tek bir anlatıda birleştiren Edebî Programlama (Literate Programming), kod ve açıklamayı birlikte güncel tutma yükü yüzünden yaygınlaşamadı; ancak AI kodlama ajanları bu temel emeği ortadan kaldırabilir
  • Emacs Org Mode içindeki org-babel ile çok dilli edebî programlama mümkün, ancak büyük ölçekli projelerde kaynak kod çıkarma (tangling) sürecinin zahmeti bir sınır oluşturuyor
  • Ajana Org dosyası tabanlı bir runbook yazmasını söyleyince, niyetin açıklamalarla anlatıldığı, kod bloklarının etkileşimli biçimde çalıştırıldığı ve sonuçların belgeye kaydedildiği bir iş akışı mümkün oluyor
  • Ajan, açıklama ile kod arasındaki senkronizasyonu ve tangling işlemini otomatik yürüttüğü için, kod değiştiğinde açıklamayı yeniden yazma zahmeti ortadan kalkıyor; böylece LLM'lerin en iyi yaptığı çeviri ve özetleme becerilerinden yararlanılıyor
  • Mühendis rolünün kod yazmaktan kod okumaya odaklanmaya kaydığı bir akışta, ajanların sürdürdüğü anlatı biçimindeki kod tabanlarının pratikliği temel soru haline geliyor

Edebî Programlama kavramı ve sınırları

  • Edebî Programlama (Literate Programming), kod ile doğal dil açıklamalarını harmanlayarak, ön bilgiye sahip olmayan bir okurun bile kod tabanını tek bir anlatı gibi okuyup nasıl çalıştığını anlayabilmesini amaçlayan bir fikir
  • Çekici bir kavram olsa da pratikte kodun kendisi ile açıklamalar olmak üzere iki paralel anlatıyı birlikte sürdürme yükü doğuyor; benimsenmesini sınırlayan temel neden de bu
  • Pratikte en yaygın biçimi, açıklama, hesaplama ve sonuçların web tarayıcısında birlikte gösterildiği veri bilimi topluluğundaki Jupyter notebook'ları

Emacs Org Mode ve Edebî Programlama

  • Emacs Org Mode, org-babel paketi aracılığıyla çok dilli edebî programlamayı destekliyor; istenen herhangi bir dili çalıştırıp sonuçları belge içine alabiliyor
    • Yine de bu yaklaşım, yalnızca az sayıda hevesli kullanıcının benimsediği niş bir kalıp olarak kalmış durumda
  • Büyük yazılım projelerinde Org dosyalarını kaynağın asıl gerçeği (source of truth) olarak kullanırsanız, kaynak kod fiilen derlenmiş bir çıktı haline geliyor ve her düzenlemeden sonra kodu çıkarıp ("tangle") hedefe yerleştirmeniz gerekiyor
    • Bu otomatikleştirilebilir, ancak kullanıcı ya da ajan gerçek kaynak kodu doğrudan düzenledikten sonra bir sonraki tangle işleminde üzerine yazılma sorunu kolayca ortaya çıkabiliyor

Ajanlardan önceki kullanım kalıpları

  • Kişisel yapılandırma yönetiminde (bookkeeping personal configuration) edebî programlama kullanımı yeterince verimli olduğu için, LLM'ler ortaya çıkmadan önce de bu fikirden vazgeçilmemişti
  • Org Mode'u elle test ve not tutma için kullanma kalıbı: komut satırı yerine editörde komut yazıp çalıştırmak, her adımı doğru olana kadar düzenlemek ve sonucu bulunduğu yere kaydetmek
    • "Not tutma ile test çalıştırmayı birleştirirseniz, test bittiğinde notlar da bedavaya oluşur"

Ajanlarla birlikte yeni iş akışı

  • Claude, Kimi gibi kodlama ajanları Org Mode sözdizimini iyi anlıyor ve Org, LLM'lerin çok iyi işlediği esnek bir işaretleme dili
    • Org Mode'un geniş sözdizimi insanlar için dezavantaj olabilir, ama dil modelleri için sorun değil
  • Özellik testi sırasında ajandan Org runbook yazmasını isterseniz:
    • Açıklamalar, her adımın niyetine dair modelin düşünümünü içeriyor
    • Kod blokları gözden geçirildikten sonra tek tek ya da bir script gibi topluca etkileşimli olarak çalıştırılabiliyor
    • Sonuçlar, Jupyter notebook'ta olduğu gibi kodun altına kaydediliyor
  • Açıklamaları düzenleyip modelden kodu güncellemesini isteyebilir, kodu düzenleyip modelin bunun anlamını açıklamalara işlemesini sağlayabilir ya da ajan iki tarafı da aynı anda değiştirebilir
    • Böylece paralel anlatıları birlikte sürdürme sorunu ortadan kalkıyor

Ajanın ortadan kaldırdığı temel emek

  • Tangling işini ajana bırakırsanız, kod çıkarma sorunu da çözülüyor
  • AGENTS.md dosyasıyla ajana Org Mode dosyalarını kaynağın asıl gerçeği olarak görmesini, her zaman açıklama yazmasını ve çalıştırmadan önce tangle yapmasını söyleyebilirsiniz
    • Ajan bütün bu işlerde yetkin ve kodu değiştirdikten sonra açıklamaları yeniden yazmaktan asla yorulmuyor
  • Edebî programlamanın yaygınlaşmasını engelleyen temel ek emeği ajan ortadan kaldırıyor; bu da LLM'lerin en iyi yaptığı çeviri ve özetleme becerilerinden yararlanmak anlamına geliyor

Beklenen faydalar

  • Kod tabanı farklı biçimlere aktarılabilir (export) ve rahat okunabilir hale getirilebilir
    • Mühendislerin temel rolü yazmaktan okumaya kayıyorsa bu özellikle önemli
  • Verilerle desteklenmese de, her kod bloğunun niyetini açıklayan anlatı kodla birlikte bağlamda yer aldığı için üretilen kodun kalitesinin de artabileceği tahmin ediliyor
  • Şimdiye kadar büyük ve gerçek anlamda kapsamlı kod tabanlarında denenmedi; şu anda test ve elle yürütülen süreçlerin belgelenmesi iş akışlarında kullanılıyor

Org Mode'un sınırları ve alternatifler

  • Org biçimi, Emacs ile sıkı biçimde bütünleştiği için bir sınırlayıcı unsur; Org'un Emacs dışına çıkması gerektiği yönünde eski bir inanç var
  • Alternatif olarak Markdown önerilmek istense de, Markdown'da metadata ekleme yeteneği yetersiz
    • Org Mode'daki Properties kavramı, belgeyi Emacs Lisp ile programatik olarak işlemenizi sağlıyor; artık LLM'ler de o belgeye özel özelleştirmeleri file variables bölümüne Emacs Lisp olarak yazabiliyor
    • Markdown'da, Org Mode'daki header arguments gibi kod bloklarının nasıl çalıştırılacağını (nerede çalışacağı, uzak makine olup olmadığı vb.) belirleyen bir özellik yok
  • Heyecan verici olan şey Emacs'in belirli uygulaması değil, fikrin kendisi

Temel soru

  • "Ajanlar sayesinde, anlatı gibi okunabilen büyük ölçekli bir kod tabanına sahip olmak ve kod değişiklikleriyle açıklamaların senkronize kalmasını yorulmak bilmeyen bir makinenin sürdürmesi pratik hale gelebilir mi?"

İlgili okumalar

2 yorum

 
GN⁺ 2026-03-11
Hacker News görüşleri

  • En basit yaklaşımın, LLM’in kendi yorumlarını kendisinin yazmasını sağlamak olduğunu düşünüyorum
    Böylece LLM daha sonra kodu yeniden okuduğunda kendi yorumlarına başvurur ve bu, bir tür tam zamanında uzun süreli bellek (just-in-time memory) işlevi görür
    <summary> içine özeti, <remarks> içine gerekçeleri ve bağlamı, <params> içine kısıtları yazdırıp satır içi yorumları minimumda tutuyorum
    Bu sayede PR incelemesinde LLM’in düşünce sürecini doğrudan <remarks> içinde görebiliyor, niyetten farklı anladığı yerleri kolayca tespit edebiliyorsunuz

    • Benim deneyimimde LLM’in eklediği yorumlar fazla geveze ve çocuksu oluyor
      Sonuçta kendi bağlamını gereksiz bilgilerle kirletiyor ve anlama becerisi daha da düşüyor
      Hâlâ insan seviyesinde okuryazarlık (literacy) düzeyinden uzak
    • İnsana bakınca LLM yorumları çoğu zaman gürültülü ve gereksiz bilgi gibi geliyor
      Ama LLM aynı kodu tekrar okuduğunda takıldığı noktalar tam da bu yorumlar olduğundan, aslında değerli bilgi olabilirler
    • İnsanlar kodu neden yazdıklarını hatırlar, ama LLM’in bağlam penceresi sınırlı olduğu için bu bilgiler çabucak kaybolur
      Bu yüzden böyle yorumlar o belleği koruma işlevi görür
    • Bunu görünce, ajanların yazdığı yorumlara imza eklenip ayırt edilebilir olması gerektiğini düşündüm

  • Programlama dillerinin, doğal dildeki belirsizlik yüzünden ortaya çıktığını düşünüyorum
    Bu yüzden kod yorumları da sonuçta belirsizleşir ve çalıştırılmadıkları için hızla eskir
    LLM’ler kod çevirisinde güçlü ama doğal dil istemlerini koda dönüştürmekte hâlâ zorlanıyor gibi geliyor
    İyi kod niyeti açıkça ifade etmelidir; çok yorum olması bazen kod kalitesinin düşük olduğunun işareti olabilir

    • Yalnızca iyi kod yeterli olsaydı, belgeleri okumadan sadece kaynak koda bakmak yeterdi
      Ama iyi yazılım, iyi dokümantasyonu da içermelidir
      Literate programming, uygulama ayrıntılarından çok açıklama odaklı bir yazım biçimidir
    • Hukuki dilin ortaya çıkma nedeni gibi, istemler de ne kadar somutsa o kadar etkilidir
      Kod “nasıl”ı dar biçimde tanımlar ama doğal dil “ne”yi merkeze alarak ifade edebilir; bu da LLM’e daha iyi yöntemler önermesi için alan bırakır
    • Kod ile belgeler, karşılıklı hata düzeltme kodları gibi birlikte çalışmalıdır
      Hataları tespit edip düzeltmek için yinelenen bilgiye ihtiyaç vardır
    • Programlama dilleri de tamamen açık seçik değildir
      Sadece yorum serbestisini daraltan kurallar koyarlar
      Bazen metafor ya da belirsizlik daha uygun bir ifade olabilir
    • LLM’e literate programming yaptırmıyorum ama ödünleşimleri açıklatıyorum
      Örnek kod ve belgeleri şablon olarak verirseniz halüsinasyon azalıyor

  • Literate programming tarzı yorumların insanların kodu anlamasına yardımcı olduğunu gösteren araştırmalar var
    Google araştırmacıları, LLM’lerin bu yorumları güncelleyip güncelleyemeyeceğini ve bunun insan kavrayışına yardımcı olup olmadığını test etti
    Sonuç, niyeti açıklayan blok düzeyindeki yorumların en etkili olduğu yönünde
    (Bkz.: 2024 arXiv makalesi "Natural Language Outlines for Code")

  • Son dönemde ilginç olan şu: Eskiden insanlar insanlara yardımcı olsun diye README ya da mimari belgeleri yazmaya üşenirdi
    Ama artık LLM için yazıyoruz denince çok daha istekli davranıyorlar

    • İnsanlar belgeleri neredeyse hiç okumaz, yalnızca gerektiğinde soru sorar
      Ama LLM her görevde belgelere başvurduğu için, dokümantasyon motivasyonu çok daha güçlü hâle geliyor
    • Eskiden “mühendislik hijyeni” diye küçümsenen alışkanlıklar artık ajanlara büyük fayda sağlıyor
      Commit mesajları ve ADR gibi kayıtları insanlar okumasa da LLM hepsini okuyor
      Sonuçta bu alışkanlıklar insan yeni başlayanlar için de faydalı oluyor
    • Daha önce duyduğum bir söz var
      Bilgisayarlarla konuşmayı öğrenirken insanlarla konuşmayı öğrenemeyenlerin mezuniyet sonrası daha çok geride kaldığı söylenirdi
    • Belgeler, koddan daha hızlı çürür
      Çünkü kodun çalışması için belgelerin doğru olması gerekmez
      Bu yüzden çoğu zaman belgeye bakmaktansa doğrudan koda bakmak daha iyi geliyor
    • Muhtemelen bu tür alışkanlıklar yönetici bakış açısından zaten daha doğal görünüyordu

  • Ben hafif bir literate programming yaklaşımının, gelenek ağırlıklı dillerle birlikte ajan çağında iyi çalıştığını düşünüyorum
    Go gibi hızlı derlenen ve net stil kılavuzları olan diller iyi oluyor
    Ajanların kod yazarken Google Go Style Guide belgesine başvurmasını sağlarsanız oldukça iyi sonuçlar çıkıyor

  • LLM bir dil modeli olduğu için açık ve net yazıya yatırım yapmak değerli
    Mutlaka literate programming düzeyine çıkmak gerekmese de, iyi isimler, docstring’ler, tip imzaları ve “neden”i açıklayan yorumlar önemli
    Sonuçta mesele, hem insanlar hem de LLM’ler için iletişim kalıpları oluşturmak

    • Gerekli olan şey docstring ile literate programming arasında bir orta nokta
      Dosya, dizin ve proje düzeyindeki üst yapıyı açıklayan belgeler özellikle önemli
      Ama bu kavramlar birden çok dosyaya yayıldığı için, bunların nereye yazılacağı ve belge-kod senkronizasyonu her zaman sorun oluyor
    • Notebook’ların kendisinin de literate programming’in bir biçimi olduğunu düşünüyorum

  • Son 10 yıldır neredeyse bütün kodlarımı literate programming tarzında yazıyorum
    nbdev’i oluşturarak notebook tabanlı biçimde kodu, belgeleri ve testleri birlikte yönettim
    Son dönemde LLM entegreli Solveit adlı bir araç yaptım ve bunu şirket genelinde kullanıyoruz
    (Solveit bağlantısı)
    Literate programming, programlama dışındaki işler için de faydalı

    • Yalnız Solveit adı çok yaygın olduğu için aramada bulunması zor ve tanıtım videosu da fazla uzun
      Kısa bir demo ya da ekran görüntüleri eklemek iyi olabilir

  • LLM ile yorumlar ve kod arasındaki uyumsuzluğu otomatik tespit etme fikri ilginç
    Belgeler zamanla kaçınılmaz olarak koddan sapıyor; bunu otomatik algılayabilmek büyük değer yaratır
    Bunun üzerine bir startup bile kurulabilir gibi duruyor

    • 2023’ten beri bu alanda 10’dan fazla startup zaten ortaya çıktı (yazan kişi teknik yazar)
    • Benim de eskiden düşündüğüm bir fikir vardı: Her dizin, modül, sınıf ve fonksiyon için DocString/JSDoc zorunlu olan bir sistem
      Değişiklikler belge PR’ıyla başlar, geliştirici bunu koda yansıtır
      İnceleme sırasında belge ve kod yan yana gösterilerek doğrulama yapılır
      Belgeler arasındaki bağlantılarla bağlam keşfi de mümkün olacak şekilde tasarlanır
    • Promptless.ai gibi benzer startup’lar zaten var
    • CI’a AI bağlanarak düzenli biçimde belge-kod uyumsuzluğu ya da mimari sürüklenme tespit edilebilir
      Örn: GitHub gh-aw, Continue.dev
    • Ama “AI’ya doğrudan kodun ne yaptığını sormak varken buna gerek var mı?” sorusu da akla geliyor

  • Test kodu ile prodüksiyon kodunun eşli yapısı, muhasebedeki çift taraflı kayıt gibi faydalı
    Testler kodun niyetini açıklar, kod da testlerin anlamını tamamlar
    İnceleme sırasında bir taraf kafa karıştırıyorsa öbür tarafa bakabilirsiniz
    Dezavantajı kod miktarını artırması ama okunabilirlikteki artış buna değiyor

  • Ben de yakın zamanda niyet odaklı kodlama üzerine yazdım; bu tartışmayla örtüşüyor
    (blog bağlantısı)
    Önemli olan, kod tabanını farklı biçimlere dönüştürüp okuması kolay hâle getirebilmek
    İleride teknik olmayan kişiler de koda daha çok yaklaşacak ve doğal dilin dahil edilmesi onların üretkenliği ile öğrenmesine büyük katkı sağlayacak
 
xguru 2026-03-11

Wikipedia - Literate programming
> Edebi programlama (literate programming), programlama metodolojilerinden biridir; programlama yaparken bilgisayar tarafından derlenebilen kod üretmekten çok, insanların anlamasını kolaylaştıran kod üretmeye odaklanan bir yaklaşımdır. Başka bir deyişle, insanların okuyup anlayabileceği şekilde, sanki bir belge yazar gibi programlama yapmayı amaçlar. Hedef, "tıpkı bir edebiyat eserini okur gibi programı okuyabilmeyi sağlamak" olduğu için buna "edebi programlama" adı verilmiştir.