- Ajanik kodlama için ortaya atılan “spesifikasyon belgesi kodun yerini alabilir” iddiasına karşı, spesifikasyon yeterince hassas hale geldiğinde sonunda kodla aynı biçime yakınsamak zorunda olduğuna dair temel bir sınıra işaret ediliyor
- OpenAI’nin Symphony projesine bakıldığında, ilgili SPEC.md’nin bir spesifikasyon değil fiilen Markdown biçiminde sözde kod olduğu görülüyor
- Gerçekten de Symphony spesifikasyonuna dayanarak bir Haskell uygulaması denenince, çok sayıda hata ve ajanın sonsuz beklemesi gibi güvenilirlik sorunları ortaya çıktı
- Spesifikasyon çalışması aslında kodlamadan daha derin düşünmeyi gerektirir; ancak sektördeki mevcut hız optimizasyonu eğilimi içinde AI tarafından üretilen düşük kaliteli spesifikasyonların çoğaltıldığı bir yapı oluşuyor
- “garbage in, garbage out” ilkesi kodlama ajanları için de aynen geçerli; açıklık ve ayrıntıdan yoksun belgelerle güvenilir kod üretimi mümkün değil
Ajanik kodlamaya dair iki yanlış kanı
- Ajanik kodlama savunucularının dayandığı iki temel yanlış kanı var
- Yanlış kanı 1: Spesifikasyon belgesi, karşılık gelen koddan daha basittir — mühendisi spesifikasyon yazan bir yöneticiye dönüştürüp işleri bir ajan ekibine devretmeyi mümkün gören dış kaynak odaklı bakış
- Yanlış kanı 2: Spesifikasyon işi, kodlama işinden mutlaka daha düşüncelidir — spesifikasyon belgesinden geçmenin kaliteyi artıracağı ve daha iyi mühendislik pratiklerini teşvik edeceği iddiası
Kod gibi davranan spesifikasyon: Symphony vakasının analizi
- OpenAI’nin Symphony projesi, spesifikasyon belgesinden (SPEC.md) üretilmiş bir ajan orkestratörü olarak tanıtılıyor; ancak gerçek SPEC.md içeriği spesifikasyondan çok Markdown biçiminde sözde koda daha yakın
- SPEC.md’de yer alan içerik türleri:
- Veritabanı şemasının düzyazı dökümü —
session_id, thread_id, codex_input_tokens gibi alanların sıralanması
- Kodun düzyazıya dönüştürülmesi — eşzamanlılık denetimindeki
available_slots = max(max_concurrent_agents - running_count, 0) gibi ifadeler, yeniden deneme backoff formülü (delay = min(10000 * 2^(attempt-1), agent.max_retry_backoff_ms)) vb.
- Modelin kod üretmesine yardımcı olmak için açıkça eklenmiş "Config Fields Summary (Cheat Sheet)" gibi yinelenen bölümler
start_service() işlevi gibi fiilen kodun kendisi olan “Reference Algorithms” bölümü
- Spesifikasyon belgesinin kodun yerine geçtiğini iddia ederken, belgenin kendisinin kod gibi okunması aldatıcı
- Bir spesifikasyon belgesini yeterince hassas yapmak için onu kaçınılmaz olarak kod biçimine dönüştürmek ya da son derece yapılandırılmış biçimsel İngilizceyle yazmak gerekir
Dijkstra’nın “dar arayüz” argümanı
- Dijkstra’nın yazısına atıfla, arayüz seçiminin basit bir iş bölümü olmadığı; arayüzü aşan iş birliği ve iletişim maliyeti de eklediği söyleniyor
- Yunan matematiğinin dilsel ve görsel etkinlikler düzeyinde kalıp durakladığı, İslam cebrinin retorik üsluba geri dönerek gerilediği ve Batı Avrupa’nın Orta Çağ skolastisizminin “nafile dilsel kesinlik girişimlerinden” kurtularak Vieta, Descartes, Leibniz, Boole gibi isimlerin biçimsel simgesel sistemleri sayesinde ilerlediğini gösteren tarihsel örnekler veriliyor
- Ajanik kodlayıcılar, mühendislik emeğinin gerektirdiği “dar arayüzden” (= kod) kaçamaz; bu emeği yalnızca yüzeyde farklı görünen ama aynı kesinliği gerektiren bir biçime dönüştürebilirler
Kararsızlık: spesifikasyon tabanlı kod üretiminin güvenilirlik sorunu
- Symphony README’sinin önerdiği gibi Claude Code’dan Haskell ile uygulama istenince, sonuç çalışmadı
- Çok sayıda hata ortaya çıktı ve prompt üzerinden düzeltme gerekti (commit geçmişinde görülebilir)
- Hata mesajı olmadan “çalışıyor” göründüğü durumlarda bile
codex ajanı, basit bir Linear bileti (“boş bir git deposu oluştur”) karşısında hiç ilerleme olmadan sonsuza dek bekledi
- Dijkstra’nın ifadesiyle, Symphony’nin “nafile dilsel kesinlik girişimleri”nin hâlâ güvenilir bir uygulama üretmekte başarısız olduğu doğrulanıyor
- Bu sorun yalnızca Symphony’ye özgü değil — YAML spesifikasyonu gibi aşırı ayrıntılı, yaygın kullanılan ve hatta uygunluk test paketi bulunan spesifikasyonlarda bile, çoğu YAML uygulaması spesifikasyona tamamen uyamıyor
- Symphony’nin spesifikasyonu, zaten içerilen Elixir uygulamasının 1/6’sı büyüklüğünde; daha da genişletilirse Borges’in “Bilimde Kesinlik Üzerine” metnindeki — imparatorlukla aynı boyutta bir harita yapıp onu sonunda işe yaramaz hale getiren — duruma ulaşılır
- “Daha ana akım bir dilde üretilirse sonuç daha iyi olur” itirazına karşı, ajanın Haskell kodu üretmekte zorlanması eğitim verisinin ötesine genelleme yeteneğinin eksikliğine işaret eder
Slop: AI üretimi spesifikasyonların kalite sorunu
- Spesifikasyon çalışması aslında kodlamadan daha zor olmalı; amacı, kodlamaya başlamadan önce projeye düşünsel ve eleştirel bir açıdan bakmayı teşvik etmektir
- Ancak teknoloji şirketlerinde emeği küçültme ve değersizleştirme yönündeki sektör eğilimi içinde, “spesifikasyon işi kodlamadan daha kolaydır” varsayımıyla başlandığında başarısızlık kaçınılmazdır
- Teslim hızını optimize etmeyi hedeflerken, spesifikasyon yazımının gerektirdiği zor ve rahatsız edici işi yapmak imkânsızdır
- Symphony SPEC.md’nin Section 10.5’i (
linear_graphql extension contract), tipik bir slop örneği — “spesifikasyon gibi görünen” cümlelerden oluşan, tutarlılık, amaç ve büyük resmi kavrayıştan yoksun ajan çıktısı
query boş olmayan bir string olmalı, tam olarak bir GraphQL işlemi içermeli vb. tekil kurallar sıralanıyor ama genel bağlam yok
- Bu tür spesifikasyon belgeleri, insan yazmış olsa bile kaçınılmaz olarak slop olur — çünkü tutarlılık ya da açıklık için değil, teslim süresine göre optimize edilmiştir
- Kod parçalarının sözdizimi vurgusu olmadan
text olarak işaretlenmesi de AI üretimi belge belirtisi — modelin isteğin amacını değil, kelimesi kelimesine ifadesini izlemiş olabileceği düşünülüyor
Sonuç
- Spesifikasyonlar başlangıçta zaman kazandıran araçlar olarak tasarlanmadı
- Amaç teslim süresini optimize etmekse, araya bir spesifikasyon belgesi koymak yerine kodu doğrudan yazmak daha avantajlıdır
- “garbage in, garbage out” ilkesi burada da aynen geçerlidir — açıklık ve ayrıntıdan yoksun bir belge verildiğinde, kodlama ajanının bu eksikleri güvenilir biçimde tamamlayabileceği bir dünya yoktur
- Kodlama ajanları zihin okuyan varlıklar değildir; öyle olsalar bile, düşüncenin kendisi dağınıksa yapabilecekleri bir şey yoktur
6 yorum
Model odaklı geliştirme zamanındakiyle aynı şey gibi görünüyor.
Spesifikasyon tabanlı geliştirme olan SDD zaten baştan beri var olan bir şey değil miydi?
Python veya JavaScript tabanlı çözümlerde yalnızca ayrıntılı bir spesifikasyon belgesiyle tatmin edici bir uygulama yapılabiliyor gibi görünüyor. Ben C/C++ tabanlı oyun/tıp tarafındayım; bırakın tam yetkili bir AI agent’a devretmeyi, yalnızca ayrıntılı spesifikasyon belgesiyle otomasyona geçirmek bile bugünlerde bana fazlasıyla riskli geliyor.
Hacker News görüşleri
Belirsiz belgeler verildiğinde bile kodlama ajanlarının ayrıntıları dolduramayacağı iddiasına katılmıyorum
LLM özünde bir dil enterpolasyonu/ekstrapolasyonu makinesi ve eksik ayrıntıları tamamlama konusunda oldukça yetenekli
Yalnızca kısa ve öz açıklamalarla çalışan kod ürettiği birçok örnek var
Ancak bu tür ayrıntı tamamlama her zaman doğru olmuyor; güvenilirlik için kritik kısımların açıkça sınırlandırılması gerekiyor
Şu anda bir kod yazma kültürümüz var ama NASA gibi yerler dışında aşırı hassas spesifikasyon yazma kültürü neredeyse yok
Kod ne kadar kısa ve yaygınsa o kadar iyi çalışıyor, ama karmaşık açıklamalarda kolayca dağılıyor
Sonuçta “ayrıntı tamamlama yanlış olabilir” demek, güvenilir üretimin zor olduğunu kabul etmek demek
Örneğin Synquid gibi program sentezi dilleri var
Bunlar matematiksel olarak doğru spesifikasyonların program üretiminde hangi sınırlara sahip olduğunu gösteriyor
specification gap denilen sorun, yani bir programın spesifikasyonu sadakatle uyguladığını kanıtlamak, temel mesele
Doğal dil fazla muğlak olduğu için program tanımlamakta uygun değil
LLM'in makul görünen ayrıntıları doldurması bu boşluğu çözmüyor
Matematiksel spesifikasyon dilleri hassas ama öğrenme eğrileri dik; yalnızca Markdown ile prompt yazmaktan çok daha zor ve emek yoğun
Model ilgi alanlarımı hatırlayabiliyor ya da kendi bilgisini kullanarak boşlukları doldurup tamamlanmış uygulamalar, oyunlar, whitepaper'lar oluşturabiliyor
Bazen “tam olarak istediğim şey”, bazen de “anlatmaya çalıştığım hissin aynısı” oluyor
Anlam, bağlam ve nüansla başa çıkma becerisinde bazı yönlerden insanın üstünde bile olabilir
AI giderek daha zeki ve yetkin hale geliyor
Yani tamamen yeni ayrıntılar yaratmaktan çok, eğitim verisinden çekip getirmeye daha yakın
“Yeterince ayrıntılı bir spesifikasyon zaten koddur” sözüne katılıyorum
Bu, Brooks'un No Silver Bullet tezinin aynısı
Ama çoğu insan o düzeyde ayrıntı istemiyor
“AI'a bir to-do uygulaması yap” dendiğinde, aslında kastedilen “Benim hayal ettiğimden daha iyi bir uygulama yap” oluyor
Ama bu yaklaşım başka tür yazılımlara iyi ölçeklenmiyor
Sonuçta bu farklılığı spesifikasyon olarak ifade etmeniz gerekir
Ama veritabanı, dosya sistemi, paralel hesaplama gibi doğruluk ve performansın önemli olduğu alanlarda uygulama, spesifikasyondan çok daha zordur
Böyle yerlerde AI'ın biçimsel doğrulamadan geçen kod üretmesi büyük bir meydan okuma
Para kazanmak ya da rekabet etmek için somut gereksinimlere ihtiyaç vardır
vibe coding'e bilgi kuramı açısından bakarsanız, küçük bir prompt uzayından faydalı programlar uzayını geri kuran bir decoder'ın var olduğu varsayımıdır
Buradaki sıkıştırma oranı, vibe coding'in kazancıdır
“IRC kanal tabanlı ekip iletişim uygulaması” gibi bir prompt, Slack'i bilmiyorsanız çözülemez
Dolayısıyla neyin eksik olduğunu fark etmek önemlidir
Etkili AI coding için prompt'ları küçük parçalara ayırmak ve mevcut belgeleri ya da denenen kodları birlikte vermek gerekir
Algorithmic Information Theory'ye göre bir dizgenin bilgi miktarı, onun en sıkıştırılmış kendi kendine yeterli gösteriminin uzunluğuna eşittir
Ancak “kendi kendine yeterli” koşulu, yalnızca modelin ağırlıkları codebook rolü oynuyorsa geçerlidir
İnsanlar LLM'lere kıyasla çok daha fazla paylaşılan bağlam varsaydığı için decoder'ın sınırlarını olduğundan büyük görüyor olabiliriz
Ama güçlü kısıtları ve net vurgu noktaları olan bir sistem, vibe coding'in sıkıştırma oranını patlayıcı biçimde artırabilir gibi geliyor
Doğal dil, programlama dillerine erişimi daha düşük olan insanlar için yeni bir arayüz sunuyor
LLM bizim yerimize düşünmüyor ama fikirleri çalışan sistemlere dönüştürmek için yeni bir kanal açıyor
Yakında insanlar model performansı ve token verimliliği için LLMSpeak gibi bir tür teknik İngilizce lehçesi geliştirecek gibi görünüyor
Amaç belirsizliği azaltmak, token tasarrufu sağlamak ve karmaşık kavramları tek bir kelimeye sıkıştırmak olurdu
Dilbilgisel olarak da Oxford comma gibi kurallar ortaya çıkıp açıklığı artırabilir
O kadar ayrıntılı spesifikasyon yazacaksanız prompt kullanmanın pek anlamı kalmaz
Sonunda yine insan dilinde yeniden tanımlamak zorunda kalacağınız için token tasarrufu sınırlı olur
Lojban wiki, Lojban konuşuru videosu
Yapay lehçe girişimleri büyük olasılıkla Esperanto gibi başarısız olur
Böyle diller daha çok LLM'lerin kendi aralarında iletişiminde faydalı olabilir
Zaten programlama dilleri bugün bu rolü görüyor
Bir spec, koşulları karşılayan tüm programları kapsayan bir zarf(envelope) gibidir
Bu zarfı oluşturmak, tek bir program yazmaktan daha zordur
LLM'in her seferinde farklı kod üretmesi gibi, bir spesifikasyon da hem iyi hem kötü uygulamalara izin verir
Pratikte bir uygulama benimsendiğinde, bir sonraki sürümün fiili spesifikasyonu da o olur
Mevcut kod tabanı olan ortamlarda(brownfield) spesifikasyon temiz olmadığı için LLM'in iyi başa çıkması zordur
Bir spesifikasyon satırının başka satırlarla nasıl etkileşeceğini düşünmeyi gerektiren bir kombinatoryal patlama var
Ama derleyici açısından kod da sadece bir spesifikasyondur
Sonuçta “kod spesifikasyondan daha kolaydır” ifadesi göreli bir şey
“Kullanıcı kimlik bilgilerini saklar” spesifikasyonu, bcrypt'ten düz metin cookie'ye kadar her şeyi kapsayabilir
İnsanda “bunu yapmamalısın” diye bir içgüdü vardır ama ajan bunu açıkça söylemezseniz bilemez
Bu yüzden güvenliği sağlamak için yapılmaması gerekenleri de spesifikasyona yazmak gerekir
Performans ya da güvenlik önemliyse, bu özellikleri ayrıca belirtmeniz gerekir
Örneğin “bu program O(n) olmalıdır” cümlesi, uygulamanın kendisinden çok daha basittir
İnsanlar spec kelimesini farklı anlamlarda kullanıyor gibi görünüyor
Benim için spec “ne yapılacağını(what)” tanımlar, plan “nasıl(how)”ı, build packet ise “ayrıntılı adımları” ifade eder
Çoğu durumda önemli olan “ne” kısmıdır
Verinin A'dan B'ye, C üzerinden gidip D'de korunacağını ve E'de F biçiminde gösterileceğini spesifikasyon olarak yazmak, bunu Rust koduyla gerçekleştirmekten çok daha kolaydır
“Ajanik mühendislik” yaparken, spesifikasyon belgelerinin koddan uzun olduğu durumlar sık görülüyor
Doğal dil eksik ama kod kesindir
Spesifikasyonun amacı, birden çok yinelemeli geliştirme turunda işlevselliği korumaktır
Testlerden ya da yorumlardan daha çok waterfall tarzı tasarım belgeleri etkili oldu
Bu yöntemle tamamen vibe coding ile yapılmış projeleri refactor etmek ya da dillerini değiştirmek de sorunsuz ilerledi
Şu an sanki 70'ler ve 80'lerin geliştirme akışına geri dönmüşüz gibi hissettiriyor
“TCP arayüzünü uygula” gibi bir cümle gerçek koddan çok daha kısadır
Sonuçta açık bir şemaya eşlenebiliyorsa doğal dil de yeterince sıkıştırılmış olabilir
Spec → LLM yönü verimsiz ve savurgan
Asıl daha gerçekçi olan LLM → Spec yönü
Spesifikasyon derlenebilir bir biçimde mevcutsa, LLM bu geri bildirimi alıp daha iyi kod üretebilir
“Doğrulanmış İngilizce(validated English)” yaratma çabaları ise karmaşıklığı artırıyor
Sonunda önemli olan şey gerçekten çalışan kod
Kod, bir spesifikasyondan çok daha fazlasını içeriyor
Çoğu projede bunun %90'ı framework ya da altyapı kodu, yalnızca %10'u iş mantığıdır
Spesifikasyon dil ya da framework ayrıntılarıyla ilgilenmediği için çok daha özlüdür
Böylece neredeyse spesifikasyonla aynı düzeyde kod elde edilir
Alan uzmanları da bunu okuyabilir ve test etmek kolaylaşır
Ama gerçek kod oldukça fazla değişir
Spesifikasyonu bir yönetim aracı olarak gören bakış ile bir mühendislik aracı olarak gören bakış arasındaki çatışma bilişsel uyumsuzluk yaratıyor
Yöneticiler spesifikasyonu devredilecek bir ticket gibi görürken, geliştiriciler onu düşünceyi rafine eden bir düşünme aracı olarak kullanıyor
Bazı geliştiriciler kolaylık olsun diye yöneticilerin bakış açısıyla başlıyor ama kısa sürede farkına varıyor
Hype ya da yatırım toplantılarıyla bir süre idare edebilirsiniz, ama sonunda kullanıcılar gerçek bir ürün ister
Sırada herhalde waterfall ile agile’ı da yeniden icat ederler.
C gömülü geliştiricisi olarak, Feature/Subfeature için neredeyse tüm akışı chart ile doğrulayabilecek şekilde spesifikasyonu hazırladıktan sonra
spesifikasyonu uzun uzun gözden geçirip nihai olarak kesinleştirdikten sonra
spesifikasyonla tamamen bire bir eşleşen kodu üretip kullanıyoruz.
Spesifikasyon üzerinden inceleme yapınca, kod incelemesine kıyasla okunabilirlik çok daha iyi oluyor.