Giriş — İngilizce spesifikasyon yanılsaması
- "Yeterince ayrıntılı bir spesifikasyon koddur" yazısından ilhamla başlayan bir düşünce. İngilizce spesifikasyonlar sezgisel olarak kesin görünür, ama gerçekten uygulamaya kalkınca belirsizlikleri ortaya çıkar
- "Her şey, onu kesinleştirmeye çalışana kadar belirsizdir" — Bertrand Russell
- Programlama da yazmak gibidir; yaparken giderek keskinleştirilen yinelemeli bir faaliyettir (bu deneme de sayısız taslaktan geçti)
Vibe coding — neden işe yarıyor, neden tehlikeli
- Yapay zeka İngilizceyi çalıştırılabilir koda her geçen gün daha hızlı ve daha iyi çevirdiği için, İngilizce düzeyindeki bir "his" ile kod üretmek mümkün hale geliyor
- Yapay zekanın ürettiği sonuca tepki vererek — "butonu şuraya taşı, biraz daha mavi yap" — giderek daha kesin bir sonuca yaklaşma süreci
- "Vibe coding" ifadesinin kusursuz olmasının nedeni şu: İngilizce düzeyindeki vibe korunurken, düşünce yapay zeka çıktıları üzerinden keskinleştiriliyor
- Temel sorun: vibe, sanki kesin bir soyutlamaymış gibi bir yanılsama yaratıyor. Özellikler arttığında ya da ölçek büyüdüğünde soyutlama sızdırmaya başlıyor (
leaky abstraction) ve beklenmedik hatalar bütün günü mahvediyor
Gerçek örnek — Dan Shipper'ın vibe coding uygulaması
- Dan Shipper'ın vibe coding ile yaptığı metin editörü uygulaması viral oldu → sunucu çöktü
- Neden: "gerçek zamanlı işbirliği (live collaboration)" sezgisel olarak basit görünse de, pratikte tam bir kâbus düzeyinde karmaşıklık taşıyor
- Hepimiz Google Docs ve Notion kullandığımız için, "gerçek zamanlı işbirliği" sanki kesin biçimde tanımlanmış bir şeymiş gibi hissediliyor. Oysa neden öyle olmadığını önceden fark etmek son derece zor
- Yazar da 10 yıl önce ortak çalışmalı bir editör yaparken beklenmedik bir karmaşıklık kâbusu yaşamış. Neyin zor olduğunu mu? Onu bile hatırlamıyor! Sorunun bir parçası da bu — karmaşıklık sıkıcıdır, düşünmek istemezsin ve ayrıntılarla edge case'leri akılda tutmak zordur
- Örnek: Slack'in bildirim gönderip göndermemeye karar verdiği klasik akış şeması — "bildirim gönder" gibi basit bir ifadenin arkasında bu düzeyde karmaşıklık saklı
Soyutlama — karmaşıklıkla baş etmenin tek aracı
- İnsan beyninin temel sınırı: aynı anda yalnızca 7±2 şey işleyebilmesi
- 7'den fazlasını ele almanın tek yolu: birden çok şeyi tek bir şeye sıkıştırmak (
compress). Bu süreç sonsuza kadar özyineli biçimde tekrarlanabildiği için insanlar sonsuz karmaşıklıkla baş edebilir. İşte bu sıkıştırma adımı **soyutlama (abstraction)**dır
- "Soyutlamanın amacı belirsizleşmek değil, mutlak olarak kesin olunabilen yeni bir anlam düzeyi yaratmaktır" — Dijkstra
- Sophie Alpert'in, Slack'in kötü şöhretli bildirim akış şemasını akıllıca bir soyutlamayla çok daha sade hale getirdiği refactor örneği
- Programlamanın en iyi yanı: giderek daha iyi soyutlamalar kurup karmaşıklığı fethetmek. Tıpkı ReactJS'in ya da TailwindCSS'in kendi alanlarında yaptığı gibi
- Ortak çalışmalı bir metin editörünün temelden karmaşık olması, yalnızca daha iyi soyutlamaları aramayı sürdürmemiz gerektiği anlamına gelir
AGI — yine de iyi kod ortadan kaybolmaz
- 1, 2, 5, 10, 100 yıl sonrasını hayal edelim: yapay zeka giderek daha iyi / daha hızlı / daha ucuz oluyor ve bir gün makine zekâsı insanla ayırt edilemez hale geliyor (AGI)
- AGI dünyası, bir vibe dünyası gibi görünebilir. Ayda 1000 dolara 100 Kapas düzeyi dâhiyi kullanabiliyorsanız, neden can sıkıcı ayrıntılarla uğraşasınız?
- "Bu gerçekten komik bir düşünce." Bu tür fikirler, teknoloji daha gelmeden önce yalnızca soyut düzeyde mümkün görünür
- Eğer o düzeyde bir zekâya erişimimiz olursa, bunu daha fazla slop üretmek için kullanacak insan oranı %0 olur. Elbette olmaz
- Kafamızın karışmasının nedeni şu: kodun yalnızca yazılım üretmek için var olduğunu (yanlış biçimde) düşünüyoruz. Oysa kodun kendisi de temel bir çıktıdır. İyi yapıldığında şiir gibidir
- "Kimse 'vibe writing'den söz etmiyor, değil mi?" — Yazıda kimse ChatGPT'nin büyük romancıları ya da gazetecileri ikame edeceğine inanmıyor. Kod için de durum aynı; yalnızca çalışan kodun "gizemli" görünmesi bu yanılsamayı yaratıyor
- Yapay zeka (giderek daha az) kötü kod üretiyor. Bunu hepimiz biliyoruz. Yapay zekayı kötü koda rağmen kullanıyoruz; kötü kod yüzünden değil
- Simon Willison'dan alıntı: "Yapay zeka daha iyi kod üretmeye yardımcı olmalı"
- AGI geldiğinde yapılacak ilk iş: en zor soyutlama problemlerini çözmek olur. Daha iyi soyutlamalar kurup karmaşıklığı daha iyi anlamak ve fethetmek
- Yapay zeka akıllandıkça iyi koda duyulan ihtiyaç ortadan mı kalkacak? Bu, ChatGPT ile daha fazla slop üretmek istemekle aynı şey
- Gerçek örnek: Opus 4.6, Val Town'ın full-stack React framework'ü
vtrryi inşa ederken çözülmemiş bir problemi tek atışta çözdü. Sonuç da 50 satırlık tek dosyalı full-stack uygulama demosu oldu
Sonuç — kod daha yeni başlıyor
- Toplumun %99'u sanki "kod öldü" fikrine katılmış gibi görünüyor. Yazar, daha dün podcaster Sam Harris'in kendinden emin biçimde "herkes kodlamanın öldüğü konusunda hemfikir, artık kimsenin kod öğrenmesine gerek yok" dediğini duyduğunu söylüyor
- "Bu üzücü. Bu, matbaanın icadıyla birlikte 'hikâye anlatıcılığı öldü' demek gibi. Aptallar, kod daha yeni başlıyor. Yapay zeka kodlama için muazzam bir nimet olacak."
- Kapanış alıntıları:
- "Biçimsel sembolleri kullanma zorunluluğunu bir yük değil, onları kullanabilmeyi bir ayrıcalık olarak görmeliyiz. Böylece öğrenciler, eskiden ancak dâhilerin yapabildiği şeyleri yapabilir hale geldi" — Dijkstra
- "Ana dilinizi 'doğal' biçimde kullanabiliyor olmanız, yalnızca saçmalığı apaçık olmayan cümleleri kolayca kurabildiğiniz anlamına gelir" — Dijkstra, "Doğal Dil Programlamanın Ahmaklığı Üzerine"
- "Yazılım tasarlamanın iki yolu vardır: biri, kusurları apaçık olmayacak kadar basit yapmak; diğeri ise apaçık kusurları olmayacak kadar karmaşık yapmak" — Tony Hoare
- "Cebirsel sembollerle küçük bir alana sıkıştırılan anlam miktarı, onlar aracılığıyla yaptığımız akıl yürütmeyi kolaylaştırır" — Charles Babbage
7 yorum
İş birliğine dayalı düzenleme konusuna gelmeden bile, tek başına kullanılan bir editörü düzgün şekilde hayata geçirmek; imleç yönetimi, undo/redo yığını, IME girişi gibi beklenmedik karmaşıklıklarla dolu. Yazıda da belirtildiği gibi, "sezgisel ama hassas hissettiren bir spesifikasyon" tuzağını editörler kadar iyi ortaya koyan çok az yazılım var. Sonuçta kolay görünen şey gerçekten kolay olduğu için değil, o karmaşıklık iyi soyutlanıp gizlendiği için öyle görünüyor.
Aslında Anthropic'in demoda C derleyicisi yapmasının nedeni de muhtemelen derleyicilerin spesifikasyonlarının net olması ve test vakalarının da iyi hazırlanmış olmasıydı. Aynı zamanda fazlasıyla zor görünmeleri de cabası.
Birkaç derleyici yapmayı denedim ve şu anda üzerinde çalıştığım da var; vibe coding açısından bakınca editörü de denedim ama derleyici daha kolay geldi. Yazdığınız gibi, spesifikasyonun daha az kesin olduğunu ve kullanıcıdan kaynaklanan değişkenlerin daha fazla olduğunu düşünüyorum. Test etmesi de daha zor.
Spesifikasyon daha önemli hale geliyor ama eskiden beri tüm spesifikasyonu en ince ayrıntısına kadar yazıp her durumu kapsamanın imkansız olduğunu düşünüyorum. Spesifikasyonu da kod gibi çalışırken rafine etmek şimdilik daha iyi bir yaklaşım gibi geliyor; gerçi bunu birden fazla ajanın kendi aralarında yapmasını sağlayabilir miyiz diye de düşünüyorum. Ama sonuçta, insan müdahalesi olmadan öğrenilmiş durumların ve bilginin dışına çıkılamadığı için tamamen yeni durumlar ve işlevler zor olmaz mı diye düşünüyorum.
İlk robot süpürgeler çıktığında, robot için yerdeki eşyaları toplamak gibi "basit bir temizlik" yapmak gerektiğini duyduğum zamanki hisse benziyor. Yapay zeka için ayrıntılı spesifikasyon yazmak da başlı başına ciddi bir iş; sanki yapay zeka için çalışıyormuşuz gibi.
IDE de, PR da öldü ama kod yeniden mi dirildi?
Kod, basit sistemlerde mantıksal olarak en kesin spesifikasyondur.
Ama asıl tuzak, gerçek dünyanın karmaşık bir sistem olması.. Sonuçta yine verinin kendisi, az çok en doğru spesifikasyon.
Bunun başka doğrulama yöntemleriyle ikame edilip edilemeyeceğine bakmak gerekir gibi görünüyor. Frontend’e ne kadar yakınsa, yalnızca tarayıcı davranışıyla E2E yaparak da düzgün çalıştığını doğrulamak mümkün olacaktır. Ancak backend’e ve altyapıya ne kadar yakın bir kodsa, kod incelemesi o kadar gerekli gibi görünüyor. Aksi halde görünmeyen transaction’ların açılıp kapanması ya da API çağrılarının gitmesi gibi yan etkileri doğrulamak zor olacaktır.
Tarayıcılarda, E2E ile bile yakalanamayan tonla sorun var.