Vibe coding yaptığınızı anlayabiliyorum

 (alexkondov.com)
7 puan yazan GN⁺ 2025-08-01 | 2 yorum | WhatsApp'ta paylaş
  • Son zamanlarda ekibimiz içinde LLM tarafından üretilmiş kodu kolayca ayırt edebiliyorum.
  • Bu kodlar, proje konvansiyonlarına uymasa da açık ve iyi test edilmiş görünüyor.
  • Çeşitli mevcut desenleri ve kütüphaneleri görmezden gelip doğrudan yeni bir uygulama geliştiriyor.
  • Yazılım geliştirmede yalnızca hıza odaklanma eğilimi konusunda artan bir endişe var.
  • Sonuçta önemli olan, kalite ve tutarlılık ile zaman içinde bakımı sürdürülebilir olan kodun kalmasıdır.

Vibe Coding'in İzleri

  • Bazı ekip üyelerinin yazdığı kodlardan bir kısmı açık ve işlevsel olarak kusursuz görünmesine rağmen, projenin kendine özgü konvansiyonlarını takip etmediği için bunun LLM tarafından oluşturulduğu hemen fark ediliyor.
  • Örneğin, projede zaten bulunan bir veri çekme kütüphanesi olmasına rağmen tüm hata senaryolarını kapsayan bir HTTP istek implementasyonunu sıfırdan yazıyor.
  • Var olan bir modülün yardımcı fonksiyonlarını tekrar tekrar yeniden üretiyor veya bir modül bazlı yapılandırma değiştirme mekanizması varken yine global ayarları değiştiriyor.
  • Kodlama kültürü fonksiyonel biçimde yazmaya yönelmiş olmasına rağmen yine de yeni sınıf tabanlı kod yazılıyor.
  • Bu kod stili, bir insanın birkaç yıl önce asla yazmayacağı bir stil.

Bakım ve Yazılım İlkelerinin Önemi

  • Yazılım geliştirmede uzun zamandır zaman içinde bakımı mümkün kalıplar ve standartlar oluşturmak için çok emek verildi.
  • Aslında çalışan bir kodu herkes yazabilir ama asıl zorluk, uzun vadede yönetimi ve güncellenmesi kolay bir kodu üretmek.
  • Önemli olan yalnızca fonksiyon geliştirmek değil; zaman geçtikçe sürdürülebilir bir kod tabanına sahip olmaktır.
  • “Vibe coding”, bu tür felsefe ve standartları zayıflatabilir.

Hızı En Yüksek Kural Saymak mı?

  • Bir kahve dükkanında yeni bir baristanın aceleyle koşturup kahveyi dökmesi örneğiyle, hıza takıntının doğru sonuç getirmediği vurgulanıyor.
  • Bugün geliştirici ekipler de aynı şekilde çok hızlı yeni bir yazılım üretmeye çalışırken kalite düşüşü yaşıyor.
  • İnsanların aslında istediği, biraz daha bekleseler bile doğru sonucu almaktır.
  • Daha önce hız odaklı olmanın yalnızca yazılım dışı mesleklerin sorunu olduğunu düşünürdüm; ancak meslektaş geliştiricilerin de ilkelerinden vazgeçip sadece hız peşinde koşmasını hayal kırıklığıyla izliyorum.

Gerçekte İstenen Şey

  • Kodu IDE'ye nasıl yerleştirdiğininize bakılmaz.
  • Önemli olan, geliştiricinin kaliteye gösterdiği özendir.
  • LLM'nin güçlü bir teknik yenilik olduğunu kabul etsek de, gerçek yazılımı yapmak sorumluluğu hâlâ geliştiricinin üzerindedir.
  • “Daha iyi prompt yazımı”, “doğru kütüphane seçimi”, “örnek sağlama” ve “küçük dosya birimlerinde çalışma” gibi somut mevcut ilkeleri bilip uygulamak öneriliyor.
  • Kod kalitesi ve sürdürülebilirliği yalnızca modelin ‘ağırlıklarına’ bırakmamak gerekir.

İlgili okumalar

2 yorum

 
GN⁺ 2025-08-01
Hacker News görüşü

  • Projenin içinde hâlihazırda tüm edge case’leri kapsayan bir veri çekme kütüphanesi varken kimsenin sıfırdan yeni bir HTTP fetch implementasyonu yazmadığı, zaten mevcut bir utility function modülü dururken yeniden yazmadığı, global ayarların ayrı modüllerde değiştirilebilmesine rağmen bununla oynamadığı ve ekip ağırlıklı olarak fonksiyonel yaklaşım kullanırken gidip yeni class’lar oluşturmadığı bir takımda çalışmak isterdim; ama gerçekte birçok geliştirici bunları sık sık tekrar ediyor

    • Dürüst olmak gerekirse, büyük projelerde dokümantasyon zayıfsa bunun olması gerçekten çok kolay. Çalıştığım akademik araştırma projesinde kod dokümantasyonu, kodun kendi kendini anlattığı varsayımına dayanıyor ve yalnızca CMake ayarlarıyla build ve benchmark alma yöntemlerinden kısaca söz ediyor. İç kurallar ya da team convention’lar ise yaşayarak öğreniliyor. Yeni biri geldiğinde zaten yapılmış özellikleri yeniden yazması ya da global ayarları bozması sık görülen bir şey. Sonunda codebase’i indeksleyip doğrudan LLM’e sormak en iyi seçenek oluyor (çünkü projenin kilit isimleri ya ayrılmış oluyor ya da ancak uzun süre sonra cevap veriyor)

    • Bence yazarın asıl noktasını kaçırıyorsun. Eğer hız en yüce erdemse, bunlar sürekli tekrar eder. Hız mutlak değer olacaksa, teknik borcu dengeleyebilmek için üretim miktarının üstel biçimde artması gerekir. Hız dışında başka şeyler de önemliyse borcu akıllıca yönetmek ve geri ödemek gerekir. Ama bugünlerde hissiyat, borcu iyice biriktirip bir şekilde idare ederiz yönünde. Ve birçok insan gerçekten borç yönetiminde kötü

    • İnsanların fırsat buldukça tekerleği yeniden icat ettiğini, beklenen convention’ları görmezden geldiğini ya da karışık pattern’ler kullandığını sık görüyorum. Yazar buna "vibe coding" diyor olabilir ama bu aslında sadece LLM’e özgü bir sorun değil; aceleyle sadece sonuç çıkarmaya çalışan ya da deneyimi az olan herkesin başına gelir. "Takımdaki hiç kimsenin yazmayacağı türden kod" ifadesine bakınca, bunun belirli bir kişiye yönelik bir sitem olma ihtimali de var. Bu bakışı başka yerlere genellemekte dikkatli olmak gerekir

    • Yeterli olan ilk ORM varken sırf "ara sıralar popüler" diye ikinci bir ORM kütüphanesi ekleyen geliştiriciler de gördüm. İster geliştirici olsun ister LLM, herkesin kendi önyargıları var. Proje içindeki kuralları ve pattern’leri öğrenip o çerçevede çalışmak çok önemli. Bağlamı dikkate almadan kendi tarzında bir şeyler üretmek son derece tehlikeli. İnsanlar için bunu code review kültürü ve kod okuma alışkanlığıyla çözebilirsin; ama LLM söz konusuysa tüm pattern ve kuralları açıkça rehberlik ederek vermen gerekir. Aksi hâlde projeyle uyumsuz kod üretme riski çok yükselir. Asıl önemli olan, değerleri ve net ölçütleri açıkça tanımlamaktır

    • Ben öyle iyi bir takımda çalışma deneyimi yaşadım. Çoğu, küçük ölçekli (2-4 kişi) ama önemi yüksek projelerdi. Böyle ortamlarda kalite ile hızı dengeleyen bir geliştirme kültürü ve ortak mutabakat oluşturmak daha kolay oluyor. Böyle takımlarda ister insan ister LLM olsun, kimse yukarıdaki türden koda asla PR onayı vermez

  • Ben kişisel olarak LLM’i çok junior bir geliştirici gibi görüyorum. İşini iyi yapmaya çalışıyor ve talimatları izliyor ama codebase’i ve pattern’leri anlama seviyesi düşük. Her adımı tek tek yönlendirmen, potansiyel hataları da açıklaman, küçük ve somut görevler vermen ve çıkan kodu dikkatle incelemen gerekiyor. Ben de önce veri modelini zihnimde kurup sonra koda geçerim; bu yüzden somut açıklama önemli. Benim bir altın kuralım, dosyanın en üstüne her zaman dosyada ne olduğunu anlatan bir blok yorum koydurmak. Oturum yeniden başladığında bu adeta ikinci prompt işlevi görüyor. Bu yöntem "sihirli" hissettirmeden iyi çalışıyor; yine de ortada yaklaşık %30 oranında kod düzenleme, yeniden adlandırma ve refactoring ihtiyacı kalıyor ki okunur hâle gelsin. Buna rağmen LLM sayesinde her şeyi elle yazmaya göre çok daha hızlı çalışabiliyorum

    • "Junior geliştirici" ya da "copilot" benzetmesi bazen LLM’in güçlü ve zayıf yönlerini tam yansıtmıyor. Sıradan bir insandan farklı olarak çok kolay unutuyor ve çok temel hatalar yapabiliyor; ama bazı alanlarda da benden daha iyi (örneğin array’lerle ilgili off-by-one sorunları gibi). Ayrıca internetteki neredeyse her şeyi ansiklopedik biçimde biliyor. Bizzat kullandıktan sonra LLM’in bir av köpeğine benzediğini düşünmeye başladım. Avı yöneten ve işi bitiren kişi sahibi olmak zorunda

    • LLM ile junior geliştirici arasındaki fark, öğrenebilme kapasitesinde. Junior zamanla öğrenir ve gelişir; LLM ise böyle değil. Prompt’a ne kadar çok talimat koyarsan, bir o kadar çok şeyi unutup yeniden genel geçer cevaplara dönme olasılığı artıyor. Her yeni prompt başladığında en baştan yönlendirmek gerekiyor

    • Bana göre LLM, internetten kod arayıp kopyala-yapıştır yapmaktan çok da farklı değil. Sonuçta geliştiricinin kodu bizzat kontrol edip düzgün çalıştığını doğrulaması gerekiyor. Son zamanlarda göz sağlığım yüzünden 20 dakikalık bloklarla çalışıp ara vermem gerekiyor, bu yüzden verimlilik daha önemli hâle geldi. LLM’in kod üretim hızı insanınkinden açık ara yüksek olduğu için, ona yalnızca temel işleri yaptırmak bile büyük avantaj. Şu anda Unity C# ve LINQ ile SIMD için struct’lar üretiyorum; istediğim koşulları LLM’e söyleyince, elle kopyala-yapıştır yapmaktan çok daha hızlı biçimde istediğim kodu ya da string’i alabiliyorum. AI’ı bir HUD gibi kullanma fikri gerçekten hissediliyor. Bana göre ihtiyaç olan şey, tüm programı yazan bir AI’dan çok küçük ölçekte güçlü bir geliştirme yardımcısı

    • Benim için LLM, StackOverflow’a kıyasla çok daha iyi bir alternatif. Aklıma takılanı anında sorup doğru yanıt alabiliyorum. Sonra o cevabı referans alıp kendi koduma göre yeniden yazarım ya da sadece function oluştururum. Kopyalamadan önce kodu tamamen anlamaya da mutlaka çalışırım. Bazen, dürüst ve kalite odaklı çalışmaktansa 400 bin satırlık bir PR’ı iyi bilmediğim bir dilde bir open source projeye göndermenin kariyer açısından daha faydalı olup olmadığını düşündüğüm oldu. Bunun nedeni de pratikte Years of Experience’ın skill’den daha fazla değer görmesi

    • LLM’e işi başarılı biçimde yaptırmak için, düşünme tarafını değil gerçek coding aşamasını hedeflemek daha iyi sonuç verdi. Görevi parçalara ayırıp spesifik bir spec, değiştirilecek dosyalar, referans örneklerin yeri gibi bilgileri mümkün olduğunca ayrıntılı verirsen uygulanma oranı yükseliyor. Aşırı mikro yönetim gerekmiyor ama ne kadar çok ipucu verirsen başarı ihtimali o kadar artıyor. Üretilen kodu da git add -p ile parça parça kendim kontrol ediyorum. Hazırlık ve inceleme zaman alıyor ama her şeyi tek başına yazmaktan ya da dağınık kodu olduğu gibi bırakmaktan kesinlikle daha az zaman ve enerji harcatıyor

  • Vibe coding’in en büyük riski, yetkin bir geliştiriciyi sadece biraz daha hızlandırması değil; yetersiz bir geliştiricinin çok daha büyük miktarda kötü kodu çok daha hızlı üretmesini sağlaması. Asıl soru şu: Bu tür geliştiriciler vibe coding ile gerçekten gelişiyor mu, yoksa sadece orada mı takılı kalıyor

    • Deneyimime göre mediocore (vasat) bir geliştirici bile çok hızlı şekilde kötü bir geliştiriciye dönüşebilir. Sebebi yanlış bir özgüven ve kod üretimindeki patlama. AI’ın ürettiği kodda genel mimari, bilgi akışı ya da single responsibility principle neredeyse hiç gözetilmiyor. Güvenli kod yazmak adına exception fırlatmak yerine placeholder döndüren yapılar kuruluyor. Sonra çağıran kodun her seferinde dönen sonucun placeholder olup olmadığını kontrol etmesi gerekiyor. Daha girişte input parameter’ları kötüyse, AI bunu kendi kendine "düzeltmeye" çalışıp gather_parameters → call → process_results yapısını da bozuyor. Test aşamasına gelince sorun daha da büyüyor

    • Artık birçok geliştirici, net-negative programmer diye bir kavramı yeniden keşfedecek gibi görünüyor

  • Bana göre burada en kıt kaynak özen göstermek. Vibe coding bunun sebebi değil; AI sadece bir araç. Yazarın saydığı bütün sorunlar insan junior geliştiriciler için de aynen geçerli ve daha iyi yönlendirme ya da iletişimle iyileştirilebilir. AI yüzünden kaliteye verilen önemin azaldığını düşünmüyorum (zaten önemsemeyen insanlar eskiden de önemsemiyordu). Sık gelen karşı argümanlardan biri, "junior yetiştirme fırsatı kaçıyor" denmesi; ama çoğu zaman buna ayıracak kapasite yok ve AI geçici bir çözüm olarak kullanılıyor (işe alım yapmakta zorlanan benim startup’ım da buna dahil). AI araçları yüzünden yazılım kalite standartları değişebilir ve bence önümüzdeki dönemde bu konuda daha çok dönüşüm göreceğiz

  • LLM’in sadece mevcut durumu değil, geçmiş commit geçmişini de bağlam olarak kullanması gerekiyor. Birçok codebase, pattern A’dan B’ye kademeli geçiş yapıyor ve farklı pattern’ler bir arada yaşıyor. Migration tek seferde yapılamadığı için eski ile yeni genelde uzun süre karışık kalıyor. HTTP örneğinde olduğu gibi, LLM bir pattern’i fark etse bile hangisini izlemesi gerektiği çoğu zaman şansa kalıyor

    • 20 yılı aşkın süredir birleşmeler, isim değişiklikleri ve satın almalar yaşamış büyük bir codebase’de çalıştım. Çok eski API çağrısı örnekleri hâlâ duruyor; gerçekte daha yeni kod mevcut ama bazı müşteriler için eski olanlar da tutuluyor. Hiç dokümantasyonu olmayan benzer API’ler de çok fazla, bu yüzden istediğim veriyi almak için hangisini kullanmam gerektiğini tek tek araştırmak zorunda kalıyorum

    • CLAUDE.md gibi dosyalarla "şu pattern’i izle, bundan kaçın" diye net yönlendirme vermek bir yöntem olabilir

    • Ama bence bundan da etkili olan, her bölüm için çalışma biçimini ve örnekleri çok somut şekilde anlatmak

    • Sorun şu ki, bu tür bağlam farkındalığı vibe coding yapan insanlarda da çoğu zaman eksik. Birçok kişinin LLM’den önce de coding deneyimi sınırlıydı

    • Bunun işlemesi için commit message’ların düzgün yazılmış olması gerekiyor; ama gerçekte çoğu mesaj "bu dosya değişti", "bug fix" gibi şeylerden ibaret

  • LLM kullanırken linter, formatter ve strict type check gibi otomasyon araçları çok büyük fayda sağlıyor. Özellikle kod stili ya da örtük kuralları bilmeyen kişilerden (veya LLM agent’larından) katkı geldiğinde, kodu otomatik denetleyip mümkün olanları anında düzeltebilirsin. Testler için de aynısı geçerli. İster insan ister agent olsun, otomatik doğrulama sistemleri kaliteyi korumakta çok yararlı

    • Yine de bence bu araçlar, yazıda sözü edilen vibe coding örneklerinin çoğunu gerçekten engelleyemiyor

    • Bu tür araçlar bazen problemi gizleyip sadece yüzeyi temiz gösteriyor

  • Bütün büyük AI assistant’lar bu sorunu hafifletmek için bazı yöntemleri zaten varsayılan olarak sunuyor: Claude Code’un /init komutu, Cursor’ın /Generate Cursor Rules özelliği gibi. Bunlar basit context engineering’in ötesinde, organizasyon geneline daha otomatik biçimde uygulanabiliyor. Sonuçta bu araçların geliştirici topluluğunu nasıl böldüğü de ilginç bir konu

    • Gerçekte CLAUDE.md içinde her şeyi ne kadar açık yazarsan yaz, CC’nin (Claude Code) bunu sık sık görmezden geldiğini fark ettim. Diyalog uzadıkça aynı problemleri tekrar yaşıyormuşum gibi geliyor ve hâlâ tam tatmin edici bir çözüm bulabilmiş değilim. Bu yüzden bu makaleyi sadece AI karşıtı bir metin diye geçiştirmek doğru olmaz

    • Cursor’ı yeniden değerlendiriyorum. Beklediğim kadar hız kazandıramamasının sebebi yalnızca küçük hatalar (LM’nin : yerine , koyması gibi) değil; codebase’in çok büyük, çok eski ve kalite açısından çok düzensiz olması da etkili. LLM sonuçta en yaygın kullanılan, yani çoğu zaman en kötü pattern’leri daha sık kopyalıyor. Çok net şekilde "şu kısmı referans al" diye belirtsem bile, tüm codebase’in genel etkisinden kurtulamıyor. Bunu rule olarak tanımlamak da prompt’a doğrudan yazmaktan çok farklı görünmüyor. Bunun bir çözümü var mı merak ediyorum

    • Mesele aslında araç değil, vibe’ı önemseyen “coder”. Ortada özen yoksa kod da gevşek oluyor

  • Benim deneyimime göre bu sorunların neredeyse tamamı sınırlı context window ve yeterince iyi olmayan context engineering yüzünden çıkıyor. LLM’e global function’lar gibi önemli bağlamlar düzgün verildiğinde bunları fena kullanmıyor. Asıl mesele, hangi bağlamın nasıl kesintisiz biçimde korunup sunulacağı. Gelecekte sub-agent benzeri yapılarla bu konuda çok ilerleme olacağını düşünüyorum

    • "Agent global function açıklamasını biliyorsa iyi kullanır" denmiş ama aslında ortada bir "agent" yok; sadece input ile output’u bağlayan matematiksel bir function var. LLM’i insan gibi anlatmak doğru değil; insanla makine tamamen farklı şeyler

  • Bence bunların hepsi doğru. LLM’i kullanmanın en iyi yolu, compiler’ın assembly’ye göre daha üst bir soyutlama düzeyi sunması gibi, gereksinimleri ve giriş/çıkışları açıkça tanımlayıp onun mantıksal çeviriyle kod üretmesini sağlamak. Bu yüzden girişteki karmaşayı (entropy) mümkün olduğunca azaltmak gerekiyor. LLM özünde bir translation engine; onu "üretim"den çok "çeviri" için kullanmak daha verimli. Buna rağmen düzenli aralıklarla daha akıllı ve daha sezgisel modeller çıkıyor ve sonuç almak için daha az dikkat gerektiriyor. Sonunda bir gün LLM’lerin her görevde insan geliştiricilerden daha iyi sonuç verdiği bir döneme gireceğiz; insanın başka rollerinde de benzeri olacak

    • Bu yanlış bir benzetme. LLM, doğal dili yüksek seviyeli koda "compile" eden bir motor değil. Programlama dilleri ile makine dili açık ve tutarlı anlam sistemleri gerektirirken, doğal dilin soyutlama katmanı bambaşka. Aynı LLM bile farklı seed değeri ya da yeni bir versiyonda farklı sonuç üretebilir. Oysa compiler, aynı input verildiğinde her zaman aynı output’u üretmek zorundadır

    • LLM’in compiler benzeri bir soyutlama katmanı olduğu fikrine katılamıyorum. Bana göre LLM sadece rastgele token üreten bir makine. LLM kullanılarak oluşturulmuş ve gerçekten işe yarar bulduğum bir çıktı hiç görmedim. Singularity ya da sonsuz veri bulunabilirliği gibi tekno-iyimser anlatıların da gerçekçi bir temeli yok. Yüksek kaliteli veri elde etmek başlı başına inanılmaz maliyetli bir iş. Şu an için bu tür iyimser tahminler anlamsız

  • Yazarın fark ettiğinden daha geç fark ettim ki, "çoğu insan iyi kahveden çok hızlı ve ucuz kahveyi istiyor." Gerçek hayatta çoğunluk için kalite değil hız ve fiyat daha önemli

    • Keurig kahve makinelerinin popülerliğine bakmak bile bu eğilimi görmek için yeterli
 
dkmin 2025-08-02

HN yazısı, asıl metinden daha tatlı.