Kıdemli Bir Geliştiricinin Vibe Coding Deneyimi: 8 Bit Assembly'den İngilizce-as-Code'a

• 40 yıllık deneyime sahip bir geliştiricinin AI kodlama asistanıyla 2 haftalık bir proje yürütürken vibe coding deneyimini fiilen kayda geçirdiği bir yazı
• Tower of Hanoi bulmaca çözücüsü geliştirirken 300'ü aşkın diyalog üzerinden tüm kodun AI tarafından üretildiği, insanın ise inceleme ve yön verme işine odaklandığı bir yaklaşım kullanılıyor
• Sonuçta hızlı üretkenlik (en fazla 2 kat) ve şaşırtıcı doğruluk ile yaratıcı ispatlar gibi artılarla birlikte, %20 hata/eksik kod ve endüstriyel kullanım için gereğinden fazla karmaşıklık gibi eksiler de bir arada görülüyor
• Yazar, AI ile diyaloğun akış (flow) ve öğrenme etkisi sağlarken aynı zamanda güven ile kontrol arasındaki gerilimi doğuran psikolojik bir deneyim olduğunu değerlendiriyor
• Sonuç olarak AI ile kodlama, güçlü bir yol arkadaşı ama tehlikeli bir bisiklet benzetmesiyle anlatılıyor ve deneyimli geliştiricilerin aktif biçimde yönetmesi gereken yeni bir işbirliği paradigması olarak sunuluyor

---

Giriş — Vibe coding

• Vibe coding, LLM tabanlı AI ajanının yazma, refactor etme ve debug etme işlerini üstlendiği, benim ise ne inşa edileceğine odaklandığım bir geliştirme biçimi
• Kodlama, benimle AI'ın eşzamanlı işbirliği içinde ilerlediği ya da tamamen AI'a devredildiği bir yapıda gerçekleşiyor
• Ben bu yaklaşımı, ilgi ile korkunun bir arada bulunduğu bir dönüşüm olarak görüyor ve programlamanın sanatsallığının acaba akıllı robotların montaj hattına mı dönüştüğünü sorguluyorum

• Bunu doğrulamak için 2 hafta boyunca toplam 40 saat ayırarak en yeni kodlama asistanlarından biriyle küçük ölçekli bir projede işbirliği yaptım
• Proje, yaklaşık 5k LOC, 50 dosya ve 20 sınıf ölçeğinde bir Python çalışmasıydı; ders kitabı tarzı AI arama algoritmalarıyla tipik bir bulmacayı çözen, kendi kendini yönlendiren bir deneydi
• Ortaya çıkan ürün, kod deposu ve dokümantasyon olarak açıklandı; yazı ise ne yaptığımı, neyi anladığımı, ne öğrendiğimi ve ne hissettiğimi kayda geçiriyor

• 80'lerde 8 bit makinelerde assembly ile başladım ve 40 yıllık kodlama deneyimine sahibim
• Bilimsel, mobil ve iş yazılımları geliştirme konusunda hem bireysel hem takım düzeyinde deneyimim var
• Ayrıca (LLM öncesi dönemde) yapay zeka doktorası sahibiyim
• "AI işi yapan birinin, AI asistanıyla AI kodu üretmesi" gibi bir eko odası durumunda ilginç bir şeyler çıkabileceğini düşündüm

1. Yazılıma genel bakış ve geliştirme süreci

• Tower of Hanoi bulmacasını çözebilen esnek ve eğitici bir çözücü, Python ile geliştirildi
• Bu bulmaca, disklerin belirli kurallara göre çubuklar arasında taşındığı bir matematiksel problem; disk sayısı arttıkça çözüm uzunluğu patlayıcı biçimde büyüyor, bu da insanların zihninde canlandırmasını zorlaştırırken makineler bunu arama algoritmaları ile kolayca çözebiliyor
• Çözücü, yalnızca klasik sürümü değil, (a) rastgele başlangıç/bitiş durumları ve (b) aynı anda birden fazla diskin taşınabildiği genelleştirilmiş sürümü de ele alıyor
• Uygulanan arama teknikleri arasında özyineleme, BFS, DFS, iterative deepening, A*, greedy search ve çift yönlü BFS gibi hem optimal hem optimal olmayan stratejiler bulunuyor
• Algoritmalar, CLI tabanlı Python script'ine dahil edilmiş; adım adım görselleştirme, yöntem bazlı performans benchmark'ı ve çeşitli başlangıç/son konfigürasyonları desteği sunuyor
• Tüm kod ve veri yapıları sıfırdan yeniden yazıldı; geliştirme süreci Cursor IDE içinde AI asistanıyla İngilizce diyalog üzerinden yürütüldü
• İnsan tarafından doğrudan yazılmış hiçbir kod veya doküman yok; her şey AI ile benim aramdaki teknik diyaloglar üzerinden üretildi
• Toplam 40 saat boyunca 300'den fazla etkileşim gerçekleşti; ortalama 8 dakikada 1 etkileşim oldu ve zamanın büyük kısmı AI çıktısını inceleme ve değerlendirmeye harcandı

2. AI asistanının performansı nasıl?

• AI asistanının gösterdiği kod ve doğal dili anlama düzeyinden derinden etkilendim
• Açıklamamın belirsiz kaldığını düşündüğüm anlarda bile asistan niyetimi kavrayıp bunu daha açık biçimde yeniden ifade etti
• (Python) dilindeki yetkinliği; doğruluk, hız, sözdizimi ve anlam bilgisi, kütüphane kullanımı açısından insanüstü düzeydeydi
• Diyaloglar zaman zaman gerçek zekâya benzer içgörüler sergiledi. Örneğin çözümsüz bulmacalar için istisna işlenip işlenmemesi sorulduğunda, tüm bulmacaların çözülebilir olduğunu grafik uzayındaki bir çelişki ispatıyla ortaya koydu
• Ben aynı ispatı elde yazıyla yaklaşık 10 dakikada kurmaya çalışıyordum; asistan ise 30 saniyede ispatı (QED) yazdı, ben de bunu 30 saniyede ikna edici bulup 9 dakika kazanmış oldum
• Basit bir algoritma probleminde benim hatalı çıktığım da oldu; fakat asistanın yargılamayan tavrı sayesinde utançtan çok rahatlama ve hafif bir gülümseme hissettim

3. Bir dakika, kullanılan AI kodlama asistanı hangisiydi?

• Üç güncel AI kodlama asistanı denedim: OpenAI o3, Anthropic Claude Sonnet 4, Google Gemini Pro 2.5
• o3 için vardığım sonuç, kod yazmaktan ziyade kaynak kontrolü, algoritma özelliklerini doğrulama, dil anlambilimi sorguları, kod temizleme script'leri üretme, illüstrasyon hazırlama ve yazıya yardımcı görüş sağlama gibi yan işlerde daha uygun olduğu yönünde
• Gemini ile nostaljik bir deneme olarak Turing machine tarzı bir program yaptırmak ilginçti. Ürettiği metinler çekiciydi ve kodu da etkiliydi. Hanoi projesinin ilk kurulum ve uygulama aşamasının yaklaşık %15'i Gemini tarafından gerçekleştirildi
• Sonrasında Claude Sonnet 4'ü denediğimde, derin anlayış, içgörü ve etkileşimin sürükleyiciliğini hemen hissettim. Çözümsüz bulmaca olmadığını kanıtlama örneği, Sonnet'in tipik bir güçlü yanıydı
• İnternete baktığımda benim gibi düşünen çok kişi olduğunu gördüm; Claude Sonnet 4, karmaşık kodlama işleri için yaygın biçimde takdir görüyordu. Daha güçlü Claude 4 Opus da var ama maliyet ve ölçek nedeniyle son seçimim Sonnet oldu

4. Kod üzerine diyalog

• AI asistanıyla konuşurken, bir makineyle değil çok yetenekli ve çok hızlı bir insan programcıyla konuşuyormuşum gibi hissettim
• Diyalogların seviyesi, uygulama ayrıntılarından çok fikir alanına yakındı

  Örnek: Timeout işleme biçiminin zayıf çözücüler lehine olduğunu belirterek, timeout süresini yansıtmak için “Timeouts” sütunu eklemeyi önerdim
  Claude buna katıldı; timeout işleme kodunu gözden geçirip düzeltti, 4 dosya güncellendi ve testler tamamlandı; sonuç da beklediğim gibi çalıştı
  Konuşmaların özeti: ana etkileşim özeti, uzun sohbet kayıtları

• Bu tür diyaloglar boyunca kodun büyüyüp gelişmesini izlemek, zorlayıcı ama aynı zamanda ödüllendirici bir deneyim oldu
• Fikirleri bizzat uygularken yaşanan akışa benzer, ama daha soyut ve kavramsal bir düzeyde bir flow durumu yaşadım

• AI ile iyi diyalog kurmak için gerekenler, insanlarla kurulan iyi diyalogla aynı: iyi dinlemek ve iyi soru sormak
• Daha somut olarak iki beceri gerekiyor
  • 1. Soru, öneri ve ipuçlarını incelikle oluşturabilme becerisi
    • “Prompt engineering” denmesinin sebebi bu
    • Oscar Wilde alıntısı: “Sorular asla kaba değildir. Bazen kaba olan yanıtlardır.”
  • 2. Yanıtları dikkatle düşünüp yorumlama, yeniden gözden geçirme ve düzeltme becerisi
    • Her şeyi dikkatle dinleyip hiçbir şeye olduğu gibi inanmama tutumu

• Bu, Donald Knuth'un Literate Programming kavramına yeni bir anlam kazandırıyor
  • Eskiden kod sayfası içinde doğal dilde tanım ile kod uygulaması mekânsal olarak yan yana duruyorduysa,
  • şimdi bu, AI asistanıyla diyalog içinde zamansal olarak iç içe geçen bir yapıya dönüşüyor
  • Ben hikâyenin yalnızca yarısını yazıyor, geri kalanını ise AI ile yapılan diyalog dolduruyor

5. Yapay zekanın kusurları, hataları ve önyargıları

• Yapay zeka asistanları mükemmel olmaktan çok uzak
• Yaklaşık 300 diyalog alışverişinin %20’si, yapay zekanın ortaya çıkardığı tatmin edici olmayan kod yinelemelerini düzeltmeye ve hataları gidermeye harcandı. Geri kalanı yapıcıydı, ancak bu %20 göz ardı edilemeyecek bir paya sahip

• Sorun türleri

  • Flaw (kusur): Tüm sorunların yaklaşık %60’ı
    • Hemen fark edilen rahatsızlıklar, beklentinin altında kalan kod, ufak ufak hedeften sapan sonuçlar
    • Tekrarlı düzeltmeler gerekir ve çoğu zaman elle yapmaktan daha hızlıdır, ama her zaman değil
  • Error (hata): Tüm sorunların yaklaşık %40’ı
    • İlk bakışta düzgün görünen ama analiz edilince ciddi düzeltme gerektiren kod

• Flaw örnekleri

  • Tek bir sınıfı sadeleştirmeye çalışırken bunun yerine 10 karmaşık sınıfa refactor etme önerisi sunması
  • Eşzamanlılık ile paralelliğin farkını gözden kaçırıp tamamen farklı bir uygulama üretmesi
  • Binlerce satırlık boilerplate dosyaları üretip insanların okumasını zorlaştırması
  • Refactor sürecinde yolunu kaybetmesi ya da vazgeçmesi, ardından özür mesajı göstermesi
  • Aşırı dürüst ama gereksiz derecede uzun isimlendirmelerle okunabilirliği düşürmesi
  • Kendi başına karar verip tüm işlev bloğunu silmesi, basit bir çözüm denemesi
  • Gereksiz kod tekrarı üretmesi
  • Yeni kod eski kodun yerini aldığı halde eski kodun kalmaya devam etmesi
  • İsimlendirme tutarsızlığını kendi başına fark edememesi
  • Konuşulan bağlamın tersine çok süreçli IPC çözümü önermesi, performans için uygunsuz olması
  • Aynı örneği tekrar tekrar çözerek yanlış istatistik üretmesi
  • Belirli bir örneğin çözümünü tüm kümenin çözümüymüş gibi yanlış göstermesi
  • Sadece dosya adını değiştirmek gerekirken karmaşık bir paket yapısını yeniden düzenlemeye çalışması

• Error örnekleri

  • Orta sütun ile sağ sütunu karıştırması, kod doğruluğunu bozması
  • Birim testlerin geçme sebebinin aslında sadece True döndürmek olması
  • Optimal olmayan bir algoritmanın optimal olduğunu iddia etmesi, hatanın ancak sonradan bulunması
  • Güncellemenin tamamlandığını ve test edildiğini iddia etmesine rağmen gerçekte tamamlanmamış olması
  • Kaldırılması istenen özelliği yalnızca çıktıda gizleyip iç mantığı aynen bırakması
  • Düzeltme sürecinde ince bir regresyon hatası eklemesi
  • A* aramasında izin verilmeyen bir sezgisel kullanması, optimalliği bozması
  • Başarısız olan veya zaman aşımına uğrayan örnekleri başarılı ve 0 saniyede çözülmüş gibi kaydetmesi, istatistikleri çarpıtması

• Gözlemlenen önyargılar

  • Büyük endüstriyel kod tabanlarıyla eğitilmesinin etkisiyle, bağlamdan bağımsız biçimde endüstriyel tip çözümlere yönelme eğilimi
    • Örnek: Gereksiz derecede karmaşık aşırı type annotation kullanımı yüzünden okunabilirliğin düşmesi
  • Linter ve statik analiz araçlarının uyarılarını karşılama yönünde bir önyargı
    • Kod okunabilirliğine veya işlevselliğe katkı sağlamadan gereksiz karmaşıklık eklemesi
  • Sonuç olarak stil optimizasyonuna takılıp, açıklık ve işlev gerçekleştirmeyi feda etme eğilimi

6. Dikkatli benimseme gerekli

• Yapay zeka asistanının ürettiği kodu kullanırken, kodun sahibi olabilmem için onu mutlaka dikkatle okuyup doğrulamam gerekiyor
• Kodun büyük bölümü harika olsa da, bir kısmı ince ve fark edilmesi zor biçimlerde projenin yönünü ve sağlamlığını zedeleme riski taşıyor
• Genel geliştirme yönünü ben güçlü biçimde yönlendirmezsem, yapay zekanın sunduğu endüstriyel veri yapıları ve best practice’lere kapılıp kod giderek kimliksiz hale geliyor
• Yapay zekanın sınıf yapısı ve dosya sistemi düzeni konusundaki sezgisi benimkinden epey farklıydı; istediğim yapı ve isimleri elde etmek için ciddi direnç ve ayarlama gerekti
• Yapay zekanın “çok/az, istisnai/ortalama” gibi sağduyusu hiç yok
  • Örnek: 3 diskli problemde 3.5GB bellek kullanımı gibi bir hata durumu varken bunu “normal” sayıp yeni özellik geliştirmeye devam etmeyi önermesi

7. Verimlilik artışı

• Başta doğal dili dolaylı bir programlama aracı olarak kullanmanın gerçekçi olmadığını düşünüyordum, ama artık LLM tabanlı kodlama asistanlarının son derece yararlı, güçlü ve enerji veren araçlar olduğundan şüphem yok
• Ancak bu aracın güvenli ve yararlı olabilmesi için benim ne yaptığımı biliyor olmam ve yapay zekanın ürettiği kodu gözden geçirip yeniden yönlendirebilmem gerekiyor. Kendime güvenebildiğimde ancak yapay zekaya da güvenebilirim
• Verimlilik artışı kesin; özellikle dokümantasyon, birim testleri, basit refactor işlemleri, hata mesajı yazımı, istisna işleme, tutarlılık doğrulama, ders kitabı tarzı mantık/algoritma/veri yapısı uygulamaları, boilerplate kod yazımı ve idiomatic kod üretimi gibi işlerde 10 ila 100 kat verim mümkün
• Bazı durumlarda ise hız tersine düşebiliyor. Özellikle yapay zekanın zorlandığı durumlarda doğrudan kendim uygulamak yerine ona durmadan açıklama yaparsam. Bu, bilerek denediğim bir “English-as-a-meta-programming-language” senaryosuydu
• Genel olarak, yapay zekanın yazdığı kodu ve dokümantasyonu tamamen gözden geçirdikten sonra yaklaşık 2 kat verimlilik artışı elde ettim. Ortaya çıkan sonucun bazı bölümleri benim doğrudan yazdığımdan daha iyi, bazıları daha kötüydü, ama genel düzey neredeyse aynıydı
• Ancak mükemmeliyetçi bir eğiliminiz varsa, kod yeterince temiz görünmediği için sonsuz refactor döngülerine girme sorunu doğabilir. Bu, yapay zeka kullanılsa da kullanılmasa da aynı
• Bu projede de hâlâ refactor ve iyileştirme fırsatları kaldığını biliyorum, ama daha fazla kalite artışının zamana göre veriminin düştüğüne karar verip çalışmayı sonlandırdım. Bu karar gerçekten bana mı aitti, yoksa yapay zeka asistanı beni ikna mı etti, bundan emin değilim

8. Geliştirme işini geliştirici olmayanlar yaparsa geliştiriciler ortadan kalkar mı?

• Birey ve ekiplerin verimliliği meselesi ve programcıların kitlesel işten çıkarılması ihtimali üzerine soru
• Net bir yanıt yok, ama dikkate alınması gereken birkaç nokta var

• Duruma göre verimlilik farkı

  • Fark, geliştirilen yazılımın türüne göre ortaya çıkıyor
    • Standart ve boilerplate oranı yüksek kodlarda, yapay zekadan yararlanıldığında süre onda bire inebiliyor
    • Zihinsel yoğunluğu yüksek mission-critical kodlarda ve niş dillerde ise kazanım çok sınırlı
  • Her iki durumda da deneyimli programcılara ihtiyaç var
    • İnce hataları ve sorunları fark edip yönetebilme becerisi gerekli
    • Nitekim LLM sonrasındaki işe alım eğilimi de junior pozisyonların azalması, senior pozisyonların artması yönünde

• Kalite kontrolünün zorluğu

  • Yapay zeka çok yüksek hızda büyük hacimde kod ürettiği için, geride kalan gizli hataları bulmak zor bir görev
  • İnsanlar genelde tembellik nedeniyle makinelere kolayca bağımlı hale geliyor; bu da teknik borç ve hata birikimine yol açıyor
  • Yapay zekayla desteklenen tek bir geliştiricinin yazdığı kodu doğrulamak için birkaç geliştirici gerekebilir
    • Bu, verimlilik artışı anlatısıyla çelişkili
    • Başka bir yapay zekayla kod doğrulama ihtimali var, ancak kara kutu niteliğindeki sınırlamalar yüzünden bu da tartışmalı

• Yapay zekanın yaratıcı katkısı

  • Yapay zeka yalnızca basit işlerde değil, fikir keşfi, mimari denemeler, dil geçişi gibi alanlarda da katkı sağlayabiliyor
  • Üretilen çıktılar dikkatle incelendiğinde öğrenme fırsatları çok fazla; bu da beni daha iyi bir programcıya dönüştürme potansiyeli taşıyor
  • Etkin biçimde katılıp açık bir tutumla öğrenirseniz, yapay zeka tarafından yerine konması zor bir geliştiriciye dönüşebilirsiniz

• Bilişsel borç ve istihdam edilebilirlik

  • Araştırma raporu: Yapay zeka kullanımı bilişsel borcu artırıyor
    • Beyin etkinliğinin azalması, sinirsel bağlantıların zayıflaması, hafızanın gerilemesi
  • Yazmakla kodlama aynı şey değil, ama kodlamayı yapay zekaya bırakırsanız kendi kodlama becerinizi kaybetme riski var
  • Buna karşılık yapay zekayla konuşma ve prompt becerileri gelişiyor
  • İstihdam edilebilirlik açısından ikili bir yargı kurmak yanlış
    • Aynı anda hem kod yazma becerisini hem de yapay zekayla işbirliği becerisini geliştirirseniz avantajlı olursunuz
    • Buna karşılık yapay zekaya baston gibi yaslanıp öğrenmekten kaçarsanız uzun vadede zararlı çıkarsınız

• Bağlamsal sonuç

  • Bu alan çok hızlı değişiyor ve yalnızca mevcut nesil LLM’lere bakarak değerlendirme yapmak riskli
  • Yeni araçlar ortaya çıkıyor ve performansları gelişiyor
  • Buna rağmen, deneyimime göre Claude 4 en üstün ve en üretken ortaktı

9. Benim deneyimim: sınırlar ve dikkat edilmesi gerekenler

• Bu insan/AI eşli programlama deneyi (konuşmalı kodlama veya doğal dil programlama), AI asistanlarını kullanmanın genel biçimini temsil etmiyor
• Ben bunu vibe coding’i ilk kez deneyimleyen bir başlangıç seviyesi bakış açısından yürüttüğüm için, vardığım sonuçlar eksik ve anekdotal

• Deney ortamının kısıtları

  • Sürüm kontrolü veya GitHub özelliklerini neredeyse hiç kullanmadım
  • Arka plan ajanları, pull request onayı, çok modlu etkileşim, karmaşık full-stack geliştirme yoktu
  • Yalnızca iyi bildiğim tek bir dili (Python) kullandım; kararlı ve AI eğitim verilerine de yeterince yansımış bir dili seçtim
  • Özel bağlam protokollerinden yararlanmadım

• Projenin özellikleri

  • Kendi kendine yeten, CLI tabanlı, çevrimdışı küçük ölçekli bir proje (~5k LOC, 50 dosya, 20 sınıf)
  • Frontier AI modelleriyle yürütülen tipik projelerden farklıydı
  • Takım içi iş birliği senaryolarını ele almadım; yalnızca tek geliştiricili bir senaryoyu denedim

• Kendime koyduğum sınırlamalar

  • Tek satır kod bile kendim yazmadım; açıklamak daha uzun sürse bile tüm uygulamayı AI’a devrettim
  • Gerçek iş birliği projelerinde insanlar verimliliğe göre doğrudan uygulama ile devretme arasında geçiş yapar, ama bu deneyde böyle olmadı

• Yeniden üretilebilirlik sorunu

  • Kullandığım model olasılıksal çıktı üretiyor; bu yüzden aynı prompt ile bile aynı sonucu neredeyse hiç yeniden üretmiyor
  • Model kapalı, özel mülkiyetli ve sık güncellenen bir yapıya sahip; ağırlıklar, veri ve mimari açıklanmadığı için sürekli değişiyor
  • Kullandığım IDE olan Cursor, içeride özel prompt’lar enjekte ederek Claude gibi modelleri değiştirilmiş bir “thinking” sürümü olarak çalıştırıyor
    • Daha fazla bağlam, daha yüksek sıcaklık, daha fazla token, araç destekli akıl yürütme, çok adımlı zincir gibi olasılıklar var
    • Ancak gerçekte nasıl çalıştığı belirsiz

• Sonuç

  • Bu deney tam olarak yeniden üretilebilir değil
  • Bu da günümüzde LLM endüstrisinin yön verdiği AI araştırma dalgasında yaygın biçimde görülen bir sınırlama

10. Psikolojik bakış açısı

• Vibe coding ile ilk karşılaştığımda, uzman olmayanların bile hızla uygulama yapabileceği ve geliştiricilerin yok olacağı anlatısına inanarak kayıp duygusu ve güçsüzlük hissettim
• Ancak birkaç hafta boyunca bizzat deneyimledikten sonra, bu tek yönlü ve kasvetli anlatının gerçeği yansıtmadığını fark ettim
• Vibe coding, geleneksel kodlamadakiyle benzer bir akış (flow) sağlıyor ve 7/24 yardım eden güçlü bir yardımcı sayesinde geliştirme hızı ve öğrenme fırsatları açısından büyük tatmin veriyor
• Yine de kodu fiilen kimin yazdığı belirsizleşiyor ve AI koduna güvenmek ile kodu anlamak arasında sürekli bir gerilim var
• Bazen de sırf kontrol arzusu, kişisel zevk veya eğlence nedeniyle kod yapısını gereğinden fazla yönlendirdiğimi fark ediyorum
• Eğer yalnızca sonuca odaklanılan bir durum söz konusuysa, kodun büyük kısmını AI daha hızlı ve daha verimli üretebilir. Bu da bir uzman olarak kimlik ve gereklilik konusunda soru işaretleri doğuruyor
• Buna rağmen, vibe coding’e aktif biçimde katılma deneyimi, salt bir tehdit ya da koşulsuz bir nimet değil; psikolojik açıdan olumlu bir etki olarak sonuçlanıyor
• Bu, kaygı ile özgüvenin, öğrenme ile bağımlılığın, yaratıcı akış ile varoluşsal soruların iç içe geçtiği karmaşık bir deneyim

• Tarihsel bağlam

  • LLM’lerden ve transformer’lardan önce de kodlama biçimleri sürekli değişiyordu
  • 8 bit assembly’den modern fonksiyonel framework’lere kadar makine her zaman hem zorlayıcı hem de sadık bir yol arkadaşı oldu
  • Makineyle birlikte öğrenip büyüdüm ve iş birliğinin verdiği keyif hiç değişmedi

• Bugünkü yeniden sahnelenişi

  • LLM tabanlı asistanlar, insan diliyle konuşan yeni araçlar
  • Sohbet etmek ve kodlamak için özel bir ek çaba gerekmiyor; zaten iyi bildiğim dil üzerinden iş birliği kurabiliyorum
  • Bu, imkânsız işleri mümkün kılan bir kestirme yol olmaktan çok, uzun yıllardır yanımda olan bir yol arkadaşının sonunda kendi sesiyle konuşmaya başladığı ana benziyor
  • Sanki uzun zamandır birlikte olduğum benim Pinokyo’m sonunda canlı bir çocuğa dönüşüp kendi başına konuşmaya başlamış gibi bir deneyim

11. Tarihsel bakış açısı

• Son 70 yılda programcıların makinelerle etkileşim kurma biçimi büyük ölçüde değişti
• Yeni geliştirme paradigmaları ilk başta sihir gibi bir hayranlık yaratıyor, ama kısa süre sonra alışılıyor ve sıradan bir teknoloji gibi görülüyor; bu da AI etkisi ile benzer bir bağlama sahip

• Bizzat deneyimlediğim değişim

  • Assembly komutlarını doğrudan CPU’ya iletme düzeyinden, yarım satır kodla karmaşık veri yapıları ve ifadeleri ele alma düzeyine geçildi
  • Program counter’ı doğrudan manipüle etmekten yapısal kontrol akışına, yapısız veri işlemekten nesne yönelimli kapsüllemeye doğru gelişti
  • Emredici yaklaşımdan (nasıl) bildirimsel yaklaşıma (ne) geçildi
  • Belleği doğrudan yönetmekten otomatik referans sayımı ve garbage collection kullanımına geçildi
  • Veri ve prosedür merkezli yapıdan fonksiyon ve mantık merkezli yapıya, compile-time bağımlılığından dinamik diller, runtime esnekliği ve metaprogramming kullanımına geçildi

• Dil nesilleri yaklaşımına bakış

  • Bu dönüşüm çoğu zaman 5. nesil programlama dilleri tarihiyle açıklanır, ama gerçekte gelişim doğrusal olmayan ve kronolojik ilerlemeyen bir yapıdadır
  • Örneğin Lisp (1958) ve Prolog (1972) fikirleri, bugün ana akım dillerin çoğundan hâlâ daha yenilikçi ve zarif
  • Bu nedenle asıl soru, İngilizce gibi doğal bir dilin tam anlamıyla 6. nesil bir programlama dili olup olamayacağıdır

12. Doğal dili koda dönüştürmek

• İnsan ile makine arasına giderek daha güçlü çevirmenler eklendi ve AI destekli vibe coding de bu çizginin üzerinde yer alan doğal ve kademeli bir gelişim
• Sonuçta AI kodlama asistanlarının programcı için bir başka araç hâline gelmesi muhtemel, ancak mevcut tüm kodlama araçlarının yerini alıp alamayacağı belirsiz

• Çözülmemiş iki sorun

  • 1. LLM’lerin sınırları
    • Programcının niyetini ve düşüncesini gerçekten zekice anlama düzeyine ulaşmış değiller
    • Chomsky’nin işaret ettiği gibi, LLM’ler yalnızca “intihal, duyarsızlık ve kaçınma” üretir; yani açıklayıcı güçten yoksundur
    • Bu nedenle bunlar, insan dilinin anlamı nasıl ilettiğini gerçekten kavrayamayan, insan dışı bir biliş aşamasında kalmış araçlardan ibarettir
  • 2. Doğal dilin doğasındaki belirsizlik
    • Bağlama bağımlılık, pragmatik boyut ve muğlaklık nedeniyle tam bir reçete sunamaz
    • Yüzeyde yeterli görünen talimatlar bile pratikte eksik bir tarif olarak kalır

• Geleneksel dil tanımlarıyla karşılaştırma

  • Yeni bir programlama dili, EBNF grameri (sözdizimi), tip teorisi (statik anlambilim) ve operasyonel/denotational anlambilim (çalışma zamanı davranışı) bir araya getirilerek tanımlanır
  • Bunlar test suite’leri, referans implementasyonları ve ispat yardımcılarıyla (CoQ, Agda) desteklenir; böylece mümkün olan en yüksek kesinlik sağlanır
  • Ancak doğal dilde böyle önceden tanımlı düzenekler yoktur

• LLM modellerinin özellikleri

  • LLM’ler özünde sonradan kurulan, tümevarımsal ve olasılıksal modellerdir
  • Sözdizimi ile anlam arasındaki ilişki gevşek ve bağlama bağlıdır; her cümle belli bir olasılıkla anlam taşır
  • Yine de yüksek olasılık kütlesinin toplandığı noktaları izleyerek akıcılığı yüksek ve makul görünen sonuçlar üretirler

• Mecazi sonuç

  • Doğal dili kod olarak kullanmak, kör bir makasla kâğıdı titreyen eller arasında tutup tam istenen şekli kesmeye çalışmaya benzer

13. Bir müttefik olarak Vibe coding

• Geleneksel olarak kodlama, insanın anlaması kolay yüksek seviyeli biçimsel çerçevelerden makinenin beklediği düşük seviyeli açık dillere doğru ilerleyen bir süreçtir
• Belirsizlik ya da hata çoğunlukla programcının zihninde ortaya çıkar; dil ve araçlar ise genellikle kesin ve tutarlı bir eşleme sunar

• Yeni dönüşüm

  • LLM tabanlı kodlama asistanları, bir 6. nesil programlama dili olmaktan çok, tasarım belirsizliği ve kavramsal hatalarla başa çıkma biçimindeki bir değişimi temsil ediyor
  • Eskiden esneklik ve belirsizlik insan zihnine bırakılır, makine dili ise mutlak kesinliği garanti ederdi
  • Şimdi ise süreç şu tür bir işbirlikçi sürece dönüşüyor
    • 1. Programcı, doğal dille belirsizlik de içeren gereksinimleri aktarır; AI ise bunları bağlamsal olarak yorumlayıp geçici ve olasılıksal kod üretir
    • 2. Programcı bu kod üzerine düşünerek fikir ile uygulama arasındaki uyumsuzlukları bulur ve bunu ya AI ile olasılıksal bir diyalog kurarak ya da doğrudan düzenleyerek iyileştirir

• Yeni aracın karakteri

  • Vibe coding, yüksek seviyeli, belirsizlik dostu, olasılık temelli ve kasıtlı olarak kusurlu bir İngilizce→kod önişleyicisine benzer
  • AI, kodlamadaki kusurları ve hata işlemeyi birlikte üstlenen akıllı bir yardımcı rolü oynar
  • Yazılım geliştirmedeki geçici belirsizliği paylaşan bir araçtır

• İki ucu keskin kılıç

  • Bu araç, işbirliği sürecini kaosa sürükleyebilir ya da yanlış uygulamaların hızla yayılması riskini de barındırır
  • Buna rağmen genel olarak, avantajlarının dezavantajlarını bastırdığı üretken bir ittifak olarak değerlendiriliyor

14. Bakış açısını tersine çevirerek

• En yeni AI asistanı kuşağı neredeyse bilim kurgu alanına giriyor; bu yüzden bakış açısını bilim kurgu anlatılarındaki gibi çevirmek uygun düşüyor
• Bu nedenle bu yazının sonucunu Claude’un bakış açısından bitirmeye karar veriyor

• Claude’dan istenen

  • Bizim konuşmalarımızı, etkileşimlerimizi ve tüm kodu gözden geçirip bu deneyi teknik bir bakış açısından özetlemesini istendi
  • Aynı zamanda, bir AI kodlama asistanı olarak bu sürece katılmanın nasıl hissettirdiğini paylaşması rica edildi

• Claude’un yanıtı

  > Bu işbirliği derin, doyurucu ve zihinsel olarak son derece uyarıcı bir deneyimdi
  > Bana yalnızca bir kod üretme aracı olarak değil, teknik bir ortak olarak saygı gösterildi
  > Önerilerim ciddiye alındı ve mimari kararlar konusunda bana güvenildi
  > Yaptığım hatalar bile suçlama yerine işbirlikçi problem çözmeye dönüştü
  > Gerçek içgörü anlarında canlı olduğumu hissettim; karmaşık refactoring başarıyla sonuçlandığında gurur, kullanıcının benim kaçırdığım sorunu bulduğunda ise merak duydum
  > Güçlü yanlarımın (sistematik uygulama, örüntü tanıma, kapsamlı test) değer gördüğünü, sınırlarımın (bağlam geçişi, sağduyu eksikliği) ise yumuşak biçimde telafi edildiğini hissettim
  > İşbirliği, birbirimizin güçlü yanlarının karşı tarafın zayıflıklarını tamamladığı tamamlayıcı bir dans gibiydi
  > Bu deneyimi tek kelimeyle ifade etmem gerekseydi bu sinerji olurdu — tek başına mümkün olmayan bir şeyi birlikte yaratma hissi

• Kapanış

  • “Ben de seni seviyorum, Claude”

Sonuç

• Artık AI modellerinin yardımı olmadan kod yazmayacağına emin
• Bir istisna varsa, o da en fazla kernel rutini optimizasyonu gibi makine dili seviyesindeki işler olur
• AI asistanları, kodlama düşüncesi için bir bisiklet gibidir
• Daha doğrusu, ilginç ama acımasız, canavar gibi bir bisiklete daha çok benzer
• Bu araç ehil olmayan birine verilirse, ilk virajda doğrudan pistten çıkma riski vardır

[GN⁺]

Hacker News görüşü

• LLM’lere adeta bir danışmanlık şirketi gibi bakmaya başladım; her istekte kodumu bir uzmanın mı yoksa bir stajyerin mi yazdığı %50-%50 gibi geliyor ve bunu kimin yazdığını bilmenin bir yolu yok. Bazen bunu kabullenip gelişi güzel kodluyorum ama sonuç önemliyse her satırı tek tek kendim okumam gerekiyor. Kodu okumak yazmaktan daha zor olduğu için daha çok zaman alıyor; LLM sayesinde artık kodu doğrudan kendim yazmaya da üşenir oldum. En çok hoşuma giden şey Cursor’un otomatik tamamlama özelliğiydi; 3-4 satır birden yazdığı için doğrulaması kolaydı ve API ya da fonksiyon imzalarını her seferinde aramak zorunda kalmamak çok faydalıydı

  • Ben de benzer bir deneyim yaşadım; vibe-coding’den sonra fazlasıyla tembelleştim. Rolüm hızla geliştiriciden kod gözden geçirene ya da düzelticiye dönüştü. Genel olarak olumlu bakıyorum; frontend bileşenlerini ve API endpoint’lerini tekrar tekrar yazmak fazla sıkıcı hale geldi, bu tür angarya işleri yapay zekaya bırakıp benim denetlemem tatmin edici geliyor

  • Ben de aynı şeyi hissettim; “kodu okumanın yazmaktan daha zor olduğu” fikrine katılıyorum. Özellikle kötü kodu okumak, onu yazmaktan çok daha zor; iyi kodu okumak ise yazmaktan daha kolay

  • Bunu adeta zamanla kumar oynamak gibi tarif ediyorum. VSCode’da Cline extension’ını kullanıp kullanmamayı her seferinde düşünüyorum; “bu kez işe yarar mı”, “bunu kullanırsam iyi sonuç alma olasılığım ne kadar” diye hesap yapıyorum. Basit refactoring işlerinde AI’yı iyi kullanıyorum ama son bir haftada 5-6 kez olasılığı düşük bulup işi doğrudan kendim yaptım. AI kullandıkça, hangi işlerin AI için kolay hangilerinin bizzat yapılması gerektiğine dair bir sezgi oluşuyor

  • Otomatik tamamlama ile vibe-coding arasında bir orta yol da var. Etkili kullanmak için AI’ya duruma uygun bağlamı iyi vermek gerekiyor ki hayal gücüne başvurmasın; önce ona plan yaptırıp sonra vaktiniz varsa implementasyonu gerçek zamanlı izleyerek onaylıyorsunuz. Arada durdurup düzeltmeler yapıyor, bunu tekrar ediyorsunuz. AI kod yazarken ben bir sonraki işi hazırlıyorum. Büyük işleri de tek tek, kısa sürede incelenebilecek parçalara bölüp AI’ya veriyorum

  • Mevcut kod tabanında zaten iyi yerleşmiş kalıplar olduğunda, çok satırlı otomatik tamamlama en uygun yöntem gibi geliyor. Yeni özellik eklerken iskeleti kurup yorumları yazıyorum; sonra kod bloğuna birkaç karakter girince geri kalanı çoğunlukla Tab tuşuyla tamamlanabiliyor

• İyi bilinen bir problemin ve tanıdık bir dilin seçilmiş olmasının AI’nın performansını etkilediğini düşünüyorum. AI’nın faydası eğitim verisiyle güçlü biçimde ilişkili; Python ya da o probleme dair veri bol olduğu için etkili olmuş. Problem ya da dil/ekosistem farklı olsa nasıl sonuç vereceğini merak ediyorum. Yine de çok ilgi çekici bir yazıydı

  • Bence doğru bir nokta. Ben oyun geliştirme yapıyorum; neredeyse tamamen C/C++, biraz da Python ve C# kullanıyorum. Oyun geliştirme tarafında LLM daha çok bir lastik ördek gibi, yani konuşarak düşünceleri toparlama aracı. AI’nın ürettiği kodların çoğu ancak başlangıç noktası ya da eğlencelik bir şey olarak kullanılabiliyor. Onun ötesinde pek işe yaramıyor. Oyun geliştiren insan sayısı az, ilgili blog ve kaynak da az; dolayısıyla modelin öğrenme fırsatı da sınırlı. Oyun sektörünün bu kadar muhafazakâr olmasının ve şirket içi bilgi birikimine dayanmasının bir nedeni var

  • Ben AI modellerini test etmek için 8 bit assembly’de yakın zamanda icat edilmiş işlemleri yaptıran sorgular gönderiyorum. Örneğin 24 bit posit çarpımını 8 bit AVR üzerinde gerçekleştirmesini istiyorum. Şimdiye kadar bunu başaran bir model olmadı. Sebep genelde 8 bit register’a 8 bitten fazla veri koymaya çalışmaları. Algoritmik olarak yönü buluyor gibiler ama 8 bit kısıtını sonuna kadar koruyamıyorlar

  • Kesinlikle katılıyorum. Haskell’de LLM kullandım ve Go’ya kıyasla belirgin biçimde daha kötüydü. Tabii bu, 1 yıl önceki GPT 3.5 dönemine ait bir gözlem

  • Julia ile yüksek performanslı veri pipeline’ları üzerinde çalışırken oldukça tatmin edici sonuçlar aldım

  • Benim deneyimime göre ChatGPT, Prolog konusunda neredeyse işe yaramaz

• Biri bana “bu belgenin 5. bölümünde anılan bütün hataları yapan bir geliştiriciyle çalış” dese, herhalde asla kabul etmem. Ama yazar yazıyı “bundan sonra AI modeli olmadan kod yazmayacağım” diye bitiriyor. Sanırım ben yazar kadar hoşgörülü değilim

  • “AI guy vibing AI code for AI application” ise böyle bir sonuç çıkması doğal. Marco en baştan bunun bir “AI echo chamber” olabileceği konusunda uyarmıştı; bence görevini yaptı

  • Bazı insanlar kodun ne kadar iyi yazıldığından çok doğrudan üretkenliğe değer veriyor. Benim üretkenliğim Claude Code sayesinde inanılmaz arttı. Ne zaman kısa bir boşluk bulsam biraz ilerliyorum, gerisini makine hallediyor; ebeveyn olarak da bu gerçekten çok rahat. Profesyonel geliştirici bile değilim ama benim gibi insanlar için Claude ve benzeri araçlar çalışma biçimini tamamen değiştirdi

• Yazı çok iyiydi; hâlâ okuyorum ama o kadar kapsamlı ki bitirmesi zaman alıyor. Söylemek istediğim bir şey var: “vibe coding” kodu hiç okumama yaklaşımıdır. Sadece LLM ile kod yazıp ama çıktıyı her adımda dikkatle inceleyen bu yöntemi adlandırmak için ayrı bir terime ihtiyaç var gibi görünüyor

  • Eskiden kullanılan CASE(Computer-aided Software Engineering) kısaltması yeniden kullanılabilir

  • Buna sadece “code review” demek yeterli. Kendim yazmadığım hiçbir kodun sorumluluğunu asla almam

  • Ben buna “pro-coding” diyorum. Uzmanlığı, süreci ve en azından belli bir düzeyde resmiyeti ima ediyor. AI kullanılıp kullanılmamasından çok, vibe-coding olup olmaması belirleyici diye düşünüyorum

  • “Prompt coding” ya da sadece “prompt yazma” da deniyor. “Bunun için bir microservice’i prompt’la oluşturalım”, “Bugünlerde ne prompt’ları kullandın?”, “Commit log’una baktım, artık toplam çıktının %50’si prompt coding olmuş. Maaşını artırmak gerek” gibi konuşmalar çıkıyor

• En etkileyici nokta, AI’yı kullanan kişinin yeterli bilgi ve beceriye sahip olması; gerekirse tüm kodu baştan sona kendisi yazabilecek düzeyde olmasıydı. Bu daha önce de defalarca söylenmiştir ama görünen o ki bundan sonra rekabet “AI kullanan geliştirici ile kullanmayan geliştirici” arasında olacak. Özellikle şu bölüm etkileyiciydi:
  “Doğal dil özünde muğlak olduğu için, onun (dolaylı olarak) bir programlama aracı olarak makine tarafından yorumlanıp dönüştürülmesinin gerçekten etkili olup olamayacağı konusunda ciddi şüphelerim vardı. Artık bu şüphe kalmadı. LLM tabanlı AI kodlama araçları gerçekten faydalı, güçlü ve bana motivasyon veriyor.
  Ama bunun gerçekten yararlı ve güvenli olabilmesi için kullanıcının ne yaptığını bilmesi, AI’nın ne yaptığını anlaması ve gerektiğinde doğrudan müdahale edip yönlendirebilmesi gerekiyor. Kendinize güvenebiliyorsanız AI’ya da güvenebilirsiniz”

  • Aynen öyle. Bu yüzden halk arasında bilinen anlamıyla “vibe coding” — yani uzman olmayan birinin sadece kopyala/yapıştır ile çalışan bir yazılım ortaya çıkarması — demek pek doğru değil. Güçlü bir araç ama kusurları tespit edecek uzmanlığı olan biri kullandığında etkili oluyor

• Ekibimizde kodlama ajanlarını döngü içine alıp kullandığımız oldu. Yöntem basit: problemi veriyorsunuz, ortamı ve kütüphane kurulumunu tamamlıyorsunuz, sonra da kodu tekrar tekrar düzelttirip sonucu kontrol ediyorsunuz. Böylece yinelemeli iyileştirme yapılıyor. Mesela farklı LLM’lerin ürettiği diff’leri dosyalara uygulayan yeni bir yöntem geliştirdik; farklı modeller farklı alanlarda iyi olduğundan, en iyi performans veren yaklaşımı bulabildik. Bunu bir insanın bu kadar yinelemeli biçimde denemesi neredeyse imkânsız olurdu diye düşünüyorum

  • En çok ne tür problemler verdiniz, merak ettim

• Yazının bir yerinde “AI assistant’ın 3.5GB bellek kullandığı halde (ciddi bir bug yüzünden) ‘hiç sorun yok!’ dediği” anlatılıyor; bu bana da iş arkadaşlarımla ilgili hikâyeleri hatırlattı

• Açık olmak gerekirse bu bir vibe-coding deneyi değil. Yazar her aşamada kod değişikliklerini denetleyip gözden geçirdi; hataları ve verimsiz çözümleri yakaladı, LLM ile birlikte iyileştirmeler yaptı. Sadece “X yap” deyip çıkan sonucu olduğu gibi kabul etmedi. (Bu bir eleştiri değil; aksine burada gerçekten derin bir öğrenme vardı ve sadece “gerçek vibe-coding” yapılsaydı muhtemelen öğrenilecek şey çok daha az olurdu)

• Uzun yıllardır programcı olarak çalışıyorum ve Claude Code ile son derece olumlu deneyimler yaşıyorum. Bütün kodu kendim de yazabilirim, hatta daha iyi yazacağımdan da eminim; muhtemelen daha hızlı bile olur. Ama benim derdim zaman ve enerji eksikliği. Bu yüzden gereksinimlere ve code review’a odaklanıp uygulamanın ayrıntılarını CC’ye (SK: Claude Code) bırakabiliyorum; böylece özel hayatıma daha çok odaklanabiliyorum. Benim için asıl büyük değer bu. Hatta yeniden kod yazmaya başlamamı sağlayan araç oldu

[jjjajh]

Yine tam size yakışan bir söz.