CodeSpeak - Kotlin’in yaratıcısının yeni dili: LLM’lerle İngilizce yerine spec kullanarak konuşmak

• LLM tabanlı yeni nesil bir programlama dili olarak, kod tabanını 5–10 kat küçültebiliyor
• Geliştirici kod yerine kısa spec’ler yazar ve codespeak build komutuyla kod otomatik olarak üretilir
• Spec değiştiğinde sistem, spec farkını (diff) kod farkına dönüştürerek uygular
• Elle yazılmış kod ile üretilmiş kodun karışık olduğu projeleri de destekler; gerçek açık kaynak örneklerinde test geçme oranının arttığı görülmüştür
• Karmaşık yazılımlarla çalışan takım odaklı mühendisliğe odaklanır ve spec merkezli bakım sayesinde insan dostu bir geliştirme ortamını hedefler

---

CodeSpeak’e genel bakış

• CodeSpeak, LLM destekli yeni nesil bir programlama dili olup kod tabanını 5–10 kat azaltmayı hedefler
  • Site açıklamasında verimliliği vurgulamak için “Shrink your codebase 5–10x” ifadesi kullanılıyor
• Bu dil, basit bir prototipten ziyade uzun vadeli projeler için tasarlanmış, production-grade sistemler kurmaya yönelik bir araçtır
• Başlıca kullanıcı kitlesi karmaşık yazılımlar geliştiren mühendis ekipleri olarak görülür; bireysel geliştirici odaklı deneysel kodlamadan çok iş birliği merkezli geliştirmeyi hedefler

Spec tabanlı geliştirme yaklaşımı

• CodeSpeak’in merkezinde “Maintain Specs, Not Code” felsefesi bulunur
  • Geliştirici kısa spec’ler yazar ve codespeak build komutuyla kod otomatik üretilir
  • Spec değiştirildiğinde sistem, spec’teki değişikliği (diff) otomatik olarak kod değişikliğine (diff) dönüştürür
• Bu yaklaşım, kod yerine spec’i koruyup yönetmenin insanlar için daha kolay olduğunu vurgular

Karışık proje desteği

• CodeSpeak, mevcut elle yazılmış kod ile üretilmiş kodun bir arada bulunduğu projeleri destekler
  • Örnek olarak Microsoft’un MarkItDown deposunun fork’landığı bir vaka tanıtılıyor
  • Karışık projeleri adım adım ele alan bir tutorial guide sunuluyor

Kod → spec dönüşüm özelliği (yakında)

• CodeSpeak, mevcut kodu analiz ederek bunu spec’e dönüştüren bir özellik üzerinde çalışıyor
  • Bu sayede mevcut kodun bazı bölümleri 5–10 kat daha küçük spec’lerle değiştirilebilecek
  • Spec bakımının koda göre insan dostu olduğu vurgulanıyor

Gerçek vaka çalışmaları (Case Studies)

• CodeSpeak, çeşitli açık kaynak proje kodlarını spec’e dönüştürerek test etti
  • yt-dlp için WebVTT altyazı desteği: 255 LOC → 38 LOC, 6,7 kat küçülme, 37 test eklendi
  • Faker için İtalyan SSN üreticisi: 165 LOC → 21 LOC, 7,9 kat küçülme, 13 test eklendi
  • beautifulsoup4 için otomatik encoding algılama: 826 LOC → 141 LOC, 5,9 kat küçülme, 25 test eklendi
  • markitdown için EML→Markdown dönüştürücü: 139 LOC → 14 LOC, 9,9 kat küçülme, 27 test eklendi
• Her vakada test geçme oranı korunmuş ya da iyileşmiş ve bu da spec tabanlı yaklaşımın pratikte işe yaradığını gösteriyor

Özet

• CodeSpeak, spec merkezli bir yapay zeka programlama dili olarak kodun otomatik üretilmesini bakım verimliliğiyle birleştiriyor
• LLM tabanlı kod üretimi, spec-kod senkronizasyonu ve karışık proje desteği başlıca özellikleri arasında
• Gerçek örneklerde kod küçülmesi ve test iyileşmesi gösterildiği için, takım ölçeğindeki yazılım mühendisliğinde üretkenliği artırma potansiyeline işaret ediyor

[roxie]

Buna dil demek clickbait mi, yoksa gerçekten öyle bir çağa mı geldik?

[brainer]

> Joel Spolsky’nin Yale’deki konuşmasında söylediği gibi, “spec’ten program üretme” girişimleri bugüne kadar hep başarısız oldu
> Eğer bir spec programı tamamen tanımlayacak kadar ayrıntılıysa, o spec’i yazmak zaten programı yazmak kadar zordur

İlke olarak katılıyorum ama bu bana, en başta kusursuz diye bir şey olmadığını söyleyen Gödel’in kanıtı gibi, sanki kusursuz bir ürün var olabileceği varsayımı üzerinden bu tür girişimleri eleştiriyormuş gibi geliyor.

[halfenif]

MDD'yi (Model Driven Dev.) hatırlatıyor.

[GN⁺]

Hacker News yorumları

• Joel Spolsky’nin Yale’deki konuşmasında söylediği gibi, ‘spec’ten program üretme girişimleri geçmişte hep başarısız oldu
  Eğer bir spec bir programı tamamen tanımlayacak kadar ayrıntılıysa, o spec’i yazmak da neredeyse programı yazmak kadar zor demektir
  Konuşmanın orijinal bağlantısı

  • 2007’deki ‘spec tabanlı kod üretimi’ ile bugünkü anlamı tamamen farklı
    Artık eksik prompt’larla bile program üretilebiliyor ve prompt’ları sistematik biçimde ele alan araştırmaların değerli olduğu düşünülüyor
  • Artık kod giderek daha amorf hale geliyor
    Ölçeklenebilirlik, özellik eklemekten çok davranış kısıtları ve yapısal değişmezleri tanımlama tarafına kayıyor
  • İş yerinde insanların sık sık prosedürel biçimde yazı yazdığını görüyorum
    “1. Kullanıcıdan bilgi al, 2. HTTP isteği gönder, 3. Hata olursa bildir” gibi;
    bence böyle durumlarda doğrudan bir script yazmak çok daha hızlı ve deterministik
  • AI öncesi dönemde Joel’in aklına gelmeyen çözüm olarak, spec’i yorumlayacak bir ‘zihin kristali’ üretmek gerektiği yönünde esprili bir yorum yapılıyor

• Bu yeni bir dil değil, LLM tabanlı geliştirme için bir iş akışı ve araç seti
  Kod yerine Markdown spec dosyaları tutuluyor ve codespeak, spec diff’lerine göre kodu değiştiriyor
  Avantajı, prompt’ların kodla birlikte sürüm kontrolünde tutulması; dezavantajı ise spec’in kodun tüm ayrıntılarını yansıtamaması

  • C dilinin de sonuçta assembly geliştirmenin yerine geçen bir iş akışı olduğu benzetmesi ekleniyor
  • Sonunda insanların koda doğrudan dokunmak zorunda olmadığı bir dünyaya gidiyoruz ama henüz orada değiliz
    codespeak takeover adlı araçla kodu spec’e dönüştürüp bunu ajan oturumlarının prompt’larına yansıtmayı deniyorlar
    Bunu kısa vadeli ‘sprint modu’ndan uzun vadeli ‘maraton modu’na geçiş olarak açıklıyorlar
    İlgili blog bağlantısı
  • Bunu bir iş modeli olarak yürütmeye çalışmak mantıksız görünüyor
    Fikir basit olduğu için herkes tarafından hızla yeniden uygulanabilir ve yakında açık kaynak sürümlerinin yerini alacağı düşünülüyor
  • Küçük bir kod düzeltmesi için bile (ör. off-by-one hatası) spec değiştirmek gerekiyorsa bu verimsiz
    ‘küçük değişikliklere’ izin veren bir politika gerektiği öneriliyor
    Genel olarak artımlı bir sözde kod derleyicisi fikri ilginç bulunuyor
  • Fazla biçimsel hissettiriyor
    5 yıl sonra kod bu şekilde yazılmayacak; İngilizce düzeyinde bir teknik spec yeterli olacak gibi görünüyor

• Bu yaklaşım bir dilden çok, spec’i koda eşleyen bir tooling
  Ancak model deterministik değil; aynı spec her seferinde farklı sonuçlar üretebilir
  Spec, doğası gereği yüksek bilgi kaybı içeren bir özet olduğundan, büyük kod tabanlarında tutarlılığı korumak zor
  Görmek istediğim şey, metin spec → formal spec → kod şeklinde ilerleyen, doğrulanabilir bir pipeline

  • Sonuç her zaman mantıksal olarak doğruysa, kodun farklı olması sorun değildir diye karşı çıkanlar var
    Önemli olan kodun kendisinden çok davranışsal sonucun tutarlılığı
  • Ama formal spec de her seferinde farklı olabilir
    Spec koddan ne kadar soyutsa, o kadar fazla farklı implementasyon mümkündür; dolayısıyla deterministiklik yine garanti edilemez
  • Ben AGENTS.md, DESIGN.md, TECHNICAL-SPEC.md dosyaları oluşturarak gayriresmî spec tabanlı geliştirme yapıyorum
    Asıl spec rolünü otomatik testlerin üstlenmesi gerektiğini düşünüyorum
  • Modelin deterministik olmadığı iddiası sorgulanıyor
    seed sabitlenirse aynı girdiye aynı çıktının alınabileceği söyleniyor
  • Ben Kiro IDE’yi bir spec üreticisi olarak kullanıyorum
    Cursor ve Antigravity insan merkezli ‘vibe coding’ için optimize edilmişken, Kiro ajan merkezli spec tabanlı geliştirmeye odaklanıyor
    EARS ve INCOSE gibi yapılandırılmış formatlar kullanıyor, otomatik tutarlılık kontrolleri ve özellik tabanlı testler (PBT) üretiyor
    Spec sağlam olduğunda implementasyon neredeyse kendiliğinden geliyor
    Birden fazla CLI ajanını paralel çalıştırarak yüksek kaliteli sonuçlar elde ediyorum

• Formal prompt dilinin sorunu belirsizlik değil, modelin bağlamı anlama kapasitesinin yetersizliği
  Aynı prompt bile bağlama göre farklı sonuçlar verebiliyor
  Prompt’u formelleştirmek, model kod tabanını yanlış anlıyorsa işe yaramıyor

  • Sık duyulan iki tavsiye var
    1. Bağlamı düzenli olarak sıfırlamak
    2. Ajana Unix tarzı araçlar verip, onunla basit sözde İngilizce komutlarla etkileşim kurmak
       Model konuşma odaklı dile optimize edildiği için, formal bir dili doğrudan kullanmak yerine yalnızca gerektiğinde kullanmanın daha iyi olduğu düşünülüyor

• Sadece deterministik ve formal bir yöntemle bilgisayara niyet aktarabilmenin güzel olacağı söyleniyor

• Bu kavram, LLM’in iç yapısını yanlış anlama varsayımından yola çıkıyor
  Son araştırmalara göre LLM’lerde encoding ile decoding arasında ayrı bir işleme aşaması bulunuyor ve
  eğitimden sonra dilin kendisi o kadar da önemli olmayabilir
  İlgili araştırma bağlantısı

  • CodeSpeak, LLM için değil insanlar için bir yapılandırma aracı
    Amaç, insanların istediklerini daha net ifade etmelerine yardımcı olmak

• Böyle bir araca gerçekten ihtiyaç olup olmadığından emin değilim
  Doğrudan Markdown spec yazıp ajana kod üretmesini söylemek yeterli olabilir

• Tutorial’daki “Prerequisites” bölümünde Anthropic API anahtarı gerektiği yazıyor
  Alpha sürüm olduğu için geçici bir önlem olabilir ama neden özellikle API gerektiği merak ediliyor
  Claude Code gibi bir oturuma doğrudan prompt enjekte etmek de mümkün gibi görünüyor
  Referans bağlantısı

• Bu proje, üzerinde çalıştığım LLM yürütücü dili spec’i ile çok benzer olduğu için ilgimi çekti
  AIL adlı projem, YAML tabanlı olarak prompt zincirlerini tanımlayıp çalıştırıyor
  Temel fikir, kullanıcının doğal dilini yapılandırılmış komutlara dönüştüren bir ‘prompt arıtma motoru’ kullanmak
  Örneğin kullanıcının niyetini analiz edip adımlara ayırıyor ve bunu modern prompt engineering standartlarına göre optimize ediyor
  Böyle bir interceptor olursa, “Az önce söylediğimi CodeSpeak formatına çevir” gibi bir akış mümkün olabilir
  Gerçekten harika bir fikir; bunu mutlaka daha derinlemesine incelemeyi düşünüyorum