Vibe Mühendisliği

• "Vibe Engineering", yapay zeka kodlama araçlarını kullanan profesyonel bir geliştirme biçimi için yeni bir ad olup; hızlı, sorumsuz "vibe coding"den farklı olarak usta bir mühendisin LLM’lerden yararlanırken kod kalitesini ve sorumluluğu koruduğu bir yaklaşımı ifade eder
• Claude Code, OpenAI Codex CLI ve Gemini CLI gibi kodlama ajanlarının ortaya çıkmasıyla gerçek dünya projelerinde LLM kullanımı hızla arttı; bazı mühendisler birden fazla ajanı aynı anda çalıştırarak paralel iş yürütüyor
• LLM’leri etkili kullanmak için otomatik testler, önceden planlama, kapsamlı dokümantasyon, sürüm kontrolü, kod inceleme kültürü gibi zaten yerleşmiş üst düzey yazılım mühendisliği pratikleri gerekiyor
• Yapay zeka araçları mevcut uzmanlığı büyütme eğilimine sahiptir; kıdemli bir mühendisin sahip olduğu beceri ve deneyim arttıkça LLM kullanımıyla daha hızlı ve daha iyi sonuçlar alınabilir
• Bu terim, "vibe coding" ile net bir ayrım kurarak prodüksiyon yazılım geliştirme için daha zor ve daha rafine bir yapay zeka kullanım biçimi olduğunu vurgular; mühendislik ile "vibe"ın çelişkili birleşimi ise terimi daha akılda kalıcı kılar (yapay zeka araçları geliştikçe geliştirme süreçlerinin değişmesi ve uzmanlığın öneminin öne çıkması)

---

Vibe coding ile vibe mühendisliği arasındaki ayrım

• Vibe coding, yapay zekayla hızlı, gevşek ve sorumsuz bir yazılım geliştirme biçimidir; tamamen prompt odaklıdır ve kodun nasıl çalıştığına dikkat etmeyen bir yaklaşım izler
• Yelpazenin diğer ucunda ise LLM’lerle işini hızlandırırken ürettiği yazılımın sorumluluğunu güvenle üstlenen, yaptığı işle gurur duyan yetkin uzmanların yaklaşımı vardır; buna vibe mühendisliği adı verilir
• Oyuncak projeler değil gerçek projeler üzerinde bir yazılım mühendisi olarak LLM’lerle verimli çalışmanın sanıldığından daha zor olduğu pek bilinmeyen bir gerçektir; araçların nasıl kullanılacağını anlamakta ciddi bir derinlik gerekir ve kaçınılması gereken çok sayıda tuzak vardır

Kodlama ajanlarının yükselişi ve etkisi

• Şubat 2025’te çıkan Claude Code, Nisan’da çıkan OpenAI Codex CLI ve Haziran’da çıkan Gemini CLI gibi kodlama ajanı araçları, gerçek kodlama problemlerinde LLM’lerin faydasını dramatik biçimde artırdı
  • Bu araçlar, belirtilen hedefe ulaşana kadar kodu tekrar tekrar düzenleyip aktif biçimde test ederek çalışır
• Deneyimli ve güvenilir yazılım mühendisleri, birden fazla ajanı aynı anda çalıştırarak çeşitli sorunları paralel biçimde ele alıyor ve iş kapsamını genişletiyor
  • Yazar başlangıçta şüpheci olsa da bizzat paralel kodlama ajanları çalıştırdıktan sonra bunun zihinsel olarak yorucu ama şaşırtıcı derecede etkili olduğunu gördü
• tools.simonwillison.net koleksiyonunun büyük kısmı klasik vibe coding tarzında inşa edilmiş olsa da, kodlama ajanlarıyla iteratif şekilde çalışarak ileride bakım yapılabilecek prodüksiyon kalitesinde kod üretmek tamamen farklı bir süreç gibi hissettiriyor

LLM’lerin güçlendirdiği mevcut yazılım mühendisliği pratikleri

• Otomatik testler: Güçlü, kapsamlı ve istikrarlı bir test paketi varsa ajan tabanlı kodlama araçları hızlı çalışabilir; testler yoksa ajan gerçekte test etmeden çalıştığını iddia edebilir ya da yeni değişiklikler alakasız özellikleri bozabilir
  • Önce test geliştirme, döngü içinde çalışan ajanlar için özellikle etkilidir
• Önceden planlama: Bir şeyi birlikte hızlıca ortaya çıkarmak için oturulduğunda üst düzey bir planla başlamak işleri çok daha iyi götürür; ajanlarla çalışırken bu daha da önem kazanır
  • Önce planı yineleyip sonra kodu yazması için bunu ajana devredebilirsiniz
• Kapsamlı dokümantasyon: İnsan programcılar gibi LLM’ler de aynı anda kod tabanının yalnızca bir bölümünü bağlam içinde tutabilir; ilgili belgeler sağlanırsa başka alanlardaki API’leri önce kodu okumadan da kullanabilirler
  • Önce iyi doküman yazılırsa model yalnızca bu girdiden yola çıkarak buna uyan bir implementasyon oluşturabilir
• İyi sürüm kontrol alışkanlıkları: Bir kodlama ajanı değişiklik yapmış olabileceğinde hataları geri almak ve bir şeyin ne zaman, nasıl değiştiğini anlamak daha da önemli hale gelir
  • LLM’ler Git konusunda oldukça iyidir; hatanın kökenini izlemek için geçmişi doğrudan araştırabilir ve çoğu geliştiriciden daha iyi git bisect kullanabilir
• Etkili otomasyon: Sürekli entegrasyon, otomatik biçimlendirme ve linting, önizleme ortamlarına sürekli dağıtım gibi uygulamalar ajan tabanlı kodlama araçlarına da yardımcı olur
  • LLM’ler hızlı otomasyon script’leri yazmayı kolaylaştırarak bir işin bir sonraki sefer doğru ve tutarlı biçimde tekrarlanmasını sağlar
• Kod inceleme kültürü: Kod incelemesinde hızlı ve verimliyseniz LLM’lerle çalışırken çok daha iyi bir deneyim yaşarsınız
  • Başkasının (veya başka bir şeyin) yazdığı şeyi gözden geçirmek yerine kodu kendiniz yazmak istiyorsanız bu size zor gelecektir
• Oldukça tuhaf bir yönetim tekniği biçimi: Kodlama ajanlarından iyi sonuç almak, insan işbirlikçilerden iyi sonuç almaya rahatsız edici ölçüde benzer
  • Net talimatlar vermeli, gerekli bağlamı sağlamalı ve ortaya çıkan iş için uygulanabilir geri bildirim sunmalısınız
  • Bunun gerçek insanlarla çalışmaktan çok daha kolay olmasının nedeni, onları kırma ya da heveslerini kaçırma endişesi taşımamanızdır; yine de mevcut yöneticilik deneyimi şaşırtıcı derecede işe yarar
• Gerçekten iyi manuel QA (kalite güvencesi): Otomatik testlerin yanında, uç durumları öngörüp derinlemesine kurcalamayı da içerecek şekilde yazılımı elle test etmede gerçekten iyi olmak gerekir
• Güçlü araştırma becerileri: Verilen bir kodlama problemini çözmenin onlarca yolu olabilir; en iyi seçeneği belirlemek ve yaklaşımı doğrulamak her zaman önemliydi, ajanı bırakıp gerçek kodu yazdırmadan önce de hâlâ bir engel olarak duruyor
• Önizleme ortamına dağıtım yapabilme yeteneği: Ajan bir özellik geliştirdiğinde, bunu güvenli biçimde önizleyebileceğiniz bir yönteminiz varsa (doğrudan prodüksiyona çıkmadan) inceleme çok daha verimli olur ve bozuk bir şeyi gönderme riski ciddi biçimde azalır
• Yapay zekaya outsource edilebilecek şeylerle elle yapılması gerekenleri ayırt etme içgüdüsü: Modeller ve araçlar daha etkili hale geldikçe bu da gelişmeye devam ediyor
  • LLM’lerle etkili çalışmanın büyük bir kısmı, bunların en iyi ne zaman kullanılabileceğine dair güçlü bir sezgiyi korumaktır
• Güncellenmiş tahmin duygusu: Bir projenin ne kadar süreceğini tahmin etmek, her zaman kıdemli mühendis olmanın en zor ama en önemli yönlerinden biriydi; özellikle bütçe ve strateji kararlarının bu tahminlere dayandığı organizasyonlarda
  • Yapay zeka destekli kodlama bunu daha da zorlaştırıyor; eskiden çok uzun süren şeyler artık çok daha hızlı olabiliyor, ancak tahminler artık hepimizin hâlâ anlamaya çalıştığı yeni etkenlere bağlı

Vibe mühendisliğinin özü ve önemi

• Bu yeni araçların yeteneklerinden gerçekten yararlanmak için oyunun en üst seviyesinde çalışmak gerekir ve buna şunlar dahildir:
  • yalnızca kod yazmaktan sorumlu olmak değil,
  • yaklaşım araştırması,
  • üst düzey mimari kararlar,
  • spesifikasyon yazımı,
  • başarı kriterlerinin tanımlanması,
  • ajan döngülerinin tasarlanması,
  • QA planlaması,
  • fırsat bulduğunda sizi kandırmaya çalışan tuhaf dijital stajyerlerden oluşan giderek büyüyen bir ekibi yönetmek,
  • ve kod incelemeye ciddi zaman ayırmak
• Bunların neredeyse tamamı, zaten kıdemli yazılım mühendisinin ayırt edici özellikleridir
• Yapay zeka araçları mevcut uzmanlığı büyütür; yazılım mühendisi olarak ne kadar fazla beceri ve deneyime sahipseniz, LLM’ler ve kodlama ajanlarıyla çalışarak o kadar hızlı ve iyi sonuç alabilirsiniz

“Vibe engineering”, gerçekten mi?: terim seçimi üzerine

• "Vibe mühendisliği" adının aptalca olup olmadığı sorusuna: Muhtemelen öyle; yapay zekada "vibe" kavramı bu noktada biraz yıpranmış görünüyor ve "vibe coding" de birçok geliştirici tarafından küçümseyici bir ifadeyle kullanılıyor
  • Ama ben, daha yapıcı bir şey için vibe’ı geri kazanmaya hazırım
• "Coder" ile "engineer" arasındaki yapay ayrıma hiçbir zaman sıcak bakmadım; bu bana hep biraz giriş engeli gibi geldi, ama bu durumda tam da ihtiyaç duyulan şey biraz giriş engeli
  • Vibe mühendisliği, vibe coding ile net bir ayrım kuruyor ve bunun prodüksiyon yazılımı geliştirmek için yapay zeka araçlarıyla çalışmanın farklı, daha zor ve daha rafine bir yolu olduğunu işaret ediyor
• Bunun biraz küstah ve tartışmalı olma ihtimalini seviyorum; bu alanın tamamı zaten hâlâ çeşitli açılardan absürt
  • Bu yeni araçları en verimli şekilde nasıl uygulayacağımızı çözmeye çalışırken kendimizi fazla ciddiye almamamız gerekir
• Geçmişte AI-assisted programming gibi terimleri yerleştirmeye çalıştım ama başarı neredeyse sıfır oldu; bu kez de vibe’ı biraz kurcalayıp ne olacağını görmek fena değil
• "Vibe" ile "engineering" arasındaki belirgin uyumsuzluğu gerçekten seviyorum; bu, birleşik ifadeyi oyuncu ve (umarım) akılda kalıcı bir şekilde kendi içinde çelişkili kılıyor

[m00nlygreat]

Kısa süre önce de buna "hangi kodlama?" gibi bir ad verip başarısız olunduğunu biliyorum; en uygun ifade sanırım yapay zeka ile pair programming.

"Bu adı ben buldum." diye iddia etmek için isim uydurma

[m00nlygreat]

Birileri buna artırılmış kodlama (Augmented Coding) demişti ama hızla ortadan kayboldu.

[GN⁺]

Hacker News görüşü

• Son zamanlarda bu tür konuları okuyunca nedense moralim bozuluyor; eskiden bulunması zor, talebi yüksek ve iyi maaş getiren programlama becerilerine sahip olduğumu hissediyordum, diller ve framework'ler hızla değişse de yeterince zeki olduğum için ayak uydurabileceğimi düşünüyordum. Ama Simon Willison gibi insanların bu yeni ajan tabanlı kodlama biçiminin ve eşzamanlı çoklu iş akışlarının gelecek olduğunu söylediğini görünce, bunun muazzam bir çaba gerektirecek olması insanı yoruyor. Kodlama ajanlarını denedim ama aksine bekleme süresi arttı ve birden fazla işi yönetmek akışı yakalamayı zorlaştırdığı için daha az keyif veriyor. Bu yüzden satış gibi tamamen farklı bir alana geçmeyi bile düşünüyorum.
  • Ben de bu hissi içtenlikle paylaşıyorum. Aslında hedeflerimden biri, "programlama becerileri değersizleşecek ve herkes LLM ile kod yazabilecek" düşüncesine itiraz etmekti. Gerçekte, mevcut geliştirme deneyimi olan biri için kodlama ajanları ya da LLM'lerle çalışmak çok daha fazla değer yaratıyor. Şimdiye kadar öğrendiklerinizi kullanıp yeni araçlarla daha büyük etki oluşturabilirsiniz. Yazıda da dendiği gibi AI araçları mevcut uzmanların kapasitesini büyüten araçlar. Yeni başlayan biri ChatGPT ile havalı bir UI yapabilir belki ama mimari tasarım, otomatik testler ya da CI/CD, Kubernetes dağıtımı, birden fazla ajanı aynı anda işletme gibi konuları yapamaz; bu yüzden deneyimli mühendisin rolü çok daha önemli hale geliyor.
  • Ben de "birden fazla büyük ölçekli paralel ajanı yönetme" fikrini yük gibi görüyorum. Dışarıdan çok güçlü göründüğü için birçok geliştiricinin ilgisini çekiyor olabilir ama aslında ciddi stres ve yönetsel iş gibi hissettiriyor. Geliştirmeye ilk tutulduğum dönemde kod yazmanın kendisi eğlenceliydi; gün boyu kod yazıp çok şey öğrenirdim. Şimdi ise 10 yılı aşkın deneyimden sonra düşüncem "başta neden kod yazıyoruz ki?" noktasına, yani daha iş odaklı bir bakışa kaydı. Toplantılarda diğer ekipler "bunu yapabiliyor muyuz?" diye sorduğunda cevap neredeyse her zaman "EVET" oluyor. Teknik olarak çoğu şey mümkün. Ama asıl önemli soru "ne kadar zor?" ya da "bunu neden yapıyoruz?". Hâlâ önemli olanın tekrar sayısı ya da sürekli bir şeyler çıkarmak değil, özünü görmek olduğunu düşünüyorum.
  • Hissettiklerimi tam anlatmışsın. Ben de AI'ı gözleyip yöneten işi hiç sevmiyorum. Üstelik bu AI tabanlı kodlama yaklaşımının, doğrulanmamış ve ne olduğu belirsiz büyük şirket hesapları olmadan çalışamayan bir düzeni normalleştirmesi de korkutucu.
  • Endişelenmeye gerek yok. Ben de ekibimizdeki genç bir mühendise mentorluk yapıyorum. Bu arkadaşın kodu iyileştirmesi çok zor, çünkü bir kez çalışınca onunla yetiniyor. Yapı zayıf, küçük sorunlar ve güvenlik açıkları her köşeye gizlenmiş durumda. Sadece 3 Python dosyasında bile bunlar olabiliyor. Ekibimizde 10 geliştirici var ve LLM kullandığımızda deneyim farkına göre kod kalitesi farkı daha da büyüyor. LLM'leri resmen kullanmaya başlamadan önceki 6 ayda edindiğim izlenim, junior ile senior ve deneyimli insanlar arasındaki farkın pratikte daha da açıldığı yönünde. Simon'un görüşüne yakınım.
  • Esasen, bilgisi olan kişi araçlardan daha fazla güç alır; tersi değil. Sadece bunu hatırlamak yeterli.
• GPT-4'ün çıktığı dönemde, yani 2023 başlarında, çeviri sektöründe de benzer bir değişim yaşandı. İngilizce-Japonca çeviride (benim çalıştığım alan) ilk kez makine çevirisi insan seviyesine yaklaştı. O dönemde birçok profesyonel çevirmenle bu konuda tartıştım; burada olduğu gibi, çoğu kişi zor çeviri becerilerinin anlamsızlaşacağından ötürü hayal kırıklığı yaşıyordu. LLM'leri yardımcı olarak kullanınca sürecin zorlayıcı eğlencesinin bile ortadan kalktığını söyleyenler çoktu. Tanıdığım çevirmenlerin çoğu freelancer'dı ve cümle cümle dikkatle çeviri yapan tiplerdi. Büyük ölçekli çeviri projelerinin yöneticisi olmak onlara hiç cazip gelmiyordu; yüksek düzey kültürel/bağlamsal iletişim becerilerini kullanabilseler bile motivasyonları düşüktü. Şu anda çok yoğun çeviri yapmıyorum ama AI gelişimini düzenli olarak takip ediyor, ara sıra çeviri işleriyle modelleri karşılaştırmalı test ediyorum. Bu aralar birden fazla LLM'i üst üste çalıştıran (birbirlerinin çevirisini çapraz kontrol edip iyileştiren) çoklu LLM tabanlı bir çeviri sistemi denedim. Bazı belgelerde gerçekten üst düzey insan çevirisine çok yakın sonuçlar çıkıyor. API ücretleri ucuz değildi ama önemli çeviriler için kesinlikle değiyordu. Böyle bir "vibe translation" sistemi tasarlarken çevirmenlik deneyimim açıkça işe yaradı. Simon'un sözünü ettiği vibe engineering'e benziyor. Benim şu anki yaşımda (68) bu benim için kabul edilebilir ama eğer LLM'ler kariyerimin başında, 5-10. yıllarımda ortaya çıksaydı muhtemelen çevirmenliği bırakırdım.
  • Çeviri konusu LLM tartışmaları için gerçekten çok iyi bir örnek, deneyimini paylaştığın için teşekkürler. Öte yandan insanların çoğu çevirmenlere derin bir değer atfetmiyor. Mesela bir kitabı kimin çevirdiğini neredeyse kimse hatırlamaz. İnsanlar bugünlerde eskisi kadar kitap da okumuyor, bu da etkili olabilir. Ayrıca bu yüzden çeviri geleneksel olarak hep kelime ya da satır sayısına göre sözleşmeye bağlanıp ücretlendirildi; tıpkı yazılım güvenliği gibi son kontrol işi olarak görüldü. Gelecekte gerçekten rekabet avantajı taşıyabilecek çeviri alanları muhtemelen hukuk (çünkü bir insanın dava ya da sorumluluk üstlenmesi gerekir) veya simultane/saha tercümanlığıdır (çünkü yüz yüze, gerçek karşılaşmalar gerekir).
• Bugünlerde teknoloji topluluğunda "kodlama hızlanıyor ve verimlilik artıyor" söyleminin gereğinden fazla itildiğini düşünüyorum; biraz saçma geliyor. Ortamda sanki yalnızca hızlı sonuç almak önemliymiş gibi bir hava var. Benim deneyimimde LLM'ler çoğu zaman dağınık, gereksiz laf kalabalığı taşıyan kod üretiyor. Elbette benden hızlı olabilir ama benim yavaş yavaş yazdığım kodun çok daha iyi olduğunu hissediyorum. Her şeyi hızla chat'leyip çabucak sonuç almak, hemen production'a çıkmak yönündeki bu iklim geçmişte de özensiz web ürünlerinin çoğalmasının nedeniydi. Vibe coding/engineering gibi havalı terim oyunları yerine, neden düşük kalite pahasına bile bu hızın gerekli görüldüğünü ve neden otomasyonun/sürecin kendisinin daha iyi hale getirilemediğini ciddi biçimde konuşmalıyız. Örneğin birim testleri çok hızlı yazabiliyoruz ama önce neden bu kadar çok birim testine ihtiyaç duyduğumuzu sormalıyız. Elbette ihtiyaç var ama sanki soyutlama düzeyi gelişirken alt seviye araçlar aynı hızda gelişmiyor.
  • Yazılım mühendisliği tartışmalarındaki temel sorun şu: araçlar ve diller aynı gibi görünse de, gerçekte tolerans, güvenlik, uyumluluk ve bakım standartları arasında devasa farklar var. Kimi yalnızca basit bir prototipi hızla yapıyor, kimi ise 10 yıllık uzun vadeli bir roadmap ya da hassas verilerle uğraşıyor. Bu iki bakış birbirine karışınca, hızlı üretmenin yetenek olduğu görüşüyle bunun felakete yol açacağı endişesi aynı anda var oluyor. İki taraf da tamamen haksız değil ama gerçek iş bağlamı ve risk düzeyi her seferinde yok sayılıyor gibi.
  • Gerçekçi olmak gerekirse LLM'lerin geliştirme hızına muazzam katkı verdiği de bir gerçek. 5. sınıftan beri, yani 20 yılı aşkın süredir kod yazıyorum ve çevrem de hızımı kabul eder; ama LLM'den sonra ölçeğim inanılmaz büyüdü. Oyun çoktan değişti, mesele artık buna uyum sağlayıp sağlayamamak. Geleceğin belirsizliğinden ben de memnun değilim ama benzer durumdaki bir mühendissen bunu fazlasıyla anlayabilirim.
  • Yazılım geliştirmede hızın neden bu kadar önemli olduğuna dair bir argüman kurmaya çalışayım. Mutlaka haklı olduğumu ya da elimde gerçek veri olduğunu iddia etmiyorum; terim tanımlarım da muğlak olabilir. Önce "önemsiz (trivial) yazılım"ı, herkesin değerini ve çözümünü açıkça bildiği, otomatik doğrulamanın mümkün olduğu ya da yalnızca tek bir uygulama yolunun bulunduğu yazılım olarak düşünelim. Ama gerçek dünyadaki yazılımların çoğu trivial değil. Buralarda her zaman bug'lar, eksik gereksinimler, sızdıran soyutlamalar, işe yaramayan özellikler, entegrasyon sorunları, performans problemleri, güvenlik sorunları, karmaşıklık ve bakım dertleri ortaya çıkar. Ne kadar iyi geliştirici olursa olsun, ne kadar iyi kod yazılırsa yazılsın bunlar kaçınılmazdır. Bu sorunlar ancak tekrarlanan geri bildirim, gerçek kullanım, bakım ve sayısız deney sırasında görünür hale gelir ve yavaş yavaş düzeltilir. Yani kodu tek seferde kusursuz yapmak mümkün değildir; kalite çoklu iterasyonlarla yükselir. Yazılımın genel kalitesi bu "feedback loop" miktarı tarafından belirlenir. Bir döngüyü tamamlamanın ne kadar sürdüğü, toplam iterasyon sayısını da sınırlar. Sonuçta üretim ne kadar hızlıysa o kadar fazla feedback loop yaşayabilirsiniz ve yazılım da o kadar iyi hale gelir. Yavaş ama yüksek kaliteli kod bile yalnızca bir kez döngüye giriyorsa sınırına çarpar; buna karşılık düşük kaliteli olsa bile sonsuz sayıda iterasyon daha iyi bir sonuca ulaşabilir.
  • 5 yıl içinde bunun dünyanın en iyi batık maliyet safsatası örneklerinden biri olacağını düşünüyorum.
• "vibe coding" yerine "agentic coding" ya da "agentic software engineering" gibi bir adın daha uygun olduğunu düşünüyorum. Benim geliştirme akışım Claude'un kod planıyla başlıyor ve ilk adım olarak her zaman net bir spec oluşturuyorum. TDD kullanıyorum ve kendim belirlediğim gizli kod kalite kurallarını da otomasyon araçlarıyla zorunlu kılıyorum. Örneğin tasarım sistemine uymuyorsa kod commit edilemiyor; HTTP handler'ın mutlaka service layer'dan geçmesini sağlayan katman ayrımı kontrolleri de otomatik. Modele TDD'ye iyi uymasını düzenli olarak hatırlatıyorum; Claude 4.5 bunu 4.1'e göre çok daha iyi aklında tutuyor. TDD temelli olduğu için PR kod incelemesi de inanılmaz kolay. PR'ı ve spec'i Gemini'ye verip tutarsızlıkları, eksikleri ve hataları otomatik işaretleyen basit bir araç da yaptım. Güzel bir yedek araç. Ama en nihayetinde önemli olan, benim hangi sonucu istediğimi ve ajanın nerede raydan çıktığını kendim ayırt edebilmem. Sonuçta "düşük kaliteli girdi, düşük kaliteli çıktı; yüksek kaliteli girdi, yüksek kaliteli çıktı".
  • Modele TDD'yi hatırlattığını söyledin; peki vibe coding'de ajan gerçekten TDD'nin red-green-refactor döngüsünü tekrar tekrar çalıştırıyor mu? Yoksa tek seferde bütün sonucu mu çıkarıyor, onu merak ettim.
  • "vibe based" yerine "slop-coding" daha uygun bir ad gibi geliyor.
• "vibe engineering" adının gerçekten doğru olup olmadığından emin değilim. Gerçekte yapılan şey, ajana otomatik testler, ön planlama, ayrıntılı dokümantasyon, code formatting/lint, manuel QA gibi her tür kısıtı koymak. Ben de Karpathy'nin yazısını okuyup vibe coding'e başlamıştım; kod dursa bile birkaç kez yeniden çalıştırıp tüm sürece güvenme deneyimini yaşadım. Ama deneyim kazandıkça sonunda modeli kontrol etmeniz gerektiğini fark ediyorsunuz. Ajan işletmek biraz kart yarışına benziyor; pistin etrafındaki lastikler gibi çeşitli kısıtlar koymak gerekiyor. Asıl kritik olan Constraint Harness, kodun kendisi ise üretmesi ve yeniden üretmesi kolaylaşıyor. Gelecekte önemli olan, AI çıktıları için testleri ve kısıtları iyi bir şekilde biriktirmek olacak.
  • "vibe engineering" adı fazla hafif ve ciddiyetsiz geliyor. Daha nötr ve gerçekten ne yaptığını anlatan "LLM-assisted programming" gibi bir terim daha iyi olmaz mı? Tabii etkisi daha az olur.
• "Ön planlama"ya spec-driven development da denebilir. Aslında tüm geliştirme bir anlamda önceden tanımlanmış şartlara dayanıyor olabilir. Ama asıl öz, "çok tuhaf bir yönetim biçimi" yani açık talimat verme, yeterli bağlam sağlama ve uygulanabilir geri bildirim sunma tarafı. Metin olarak bakınca agile'dan çok waterfall'a daha yakın duruyor.
• Artık vibe-coding teriminin anlamı genişleyip AI tabanlı kodlamanın tamamını kapsar hale gelmiş gibi. Ben de AI ile çalışırken bunu daha çok pair programming hissine benzetiyorum ve "gerçekten vibe alıyoruz" diye düşünüyorum. Yine de "Take the wheel, LLama of God" tarzı, her şeyi gözü kapalı teslim eden o asıl vibe-coding yaklaşımı hâlâ sık kullanılacak bir olgu olduğu için buna ayrı bir yeni kelime gerektiğini düşünüyorum. Ben "Yolo-Coding" önerirdim; no-code, low-code, yolo-code çizgisine de iyi oturuyor.
  • Bence vibe coder ifadesinin no-code'a benzer olumsuz çağrışımını koruması daha iyi. Vibe engineer lafını sevmiyorum ama yine de gelecekte engineer/developer denince zaten varsayılan olarak ajan kullanan kişi anlaşılacak ve "el işi" geliştirenler istisna haline gelebilir.
  • $enterprise tarafında "responsible vibing" ile "YOLO vibe coding"i ayıracak yeni bir isim ararken sonunda "agent assisted coding" terimine vardık. Sonuçta üç harfli bir kısaltma şart.
  • "vibe coding"in asıl anlamı, Ilya Sutskever'in Twitter'da yazdığı gibi, sadece prompt girip çıkan sonucu incelemeden kopyala-yapıştır yapıp çalıştırmak; yani analiz ya da doğrulama olmadan.
  • Kişisel olarak AI-assisted coding'i otomatik tamamlama ya da kötü dokümantasyonu okumaya yardımcı olma düzeyinde görüyorum. Vibe coding ise
  • geliştiricinin LLM'in yazdığı kodu hiç anlamaması
  • kod incelemesi yapılmadan anında teknik borç üretmesi
  • hukuken telif koruması meselesi yüzünden AB/ABD'de tamamen kırılgan olması demek gibi geliyor. Vibe coding'in en ölümcül yanı, LLM'in ürettiği kodun özünde korunamaz/telif kaydına uygun olmayan bir şey olması. Birleşik Krallık gibi bazı istisnalar var ama çoğu ülkede durum umutsuz.
  • Ben de claude'a /yolo gibi bir slash komutu ekleyip pek rehberlik etmeden doğrudan çalıştırdığım oluyor.
• Güvercinlerin rastgele yem veren bir düzenekle etkileşime girdiğinde, sanki ödülü kendi davranışları sayesinde alıyormuş gibi düşünüp türlü komik danslar ve hareketleri tekrar ettiği bir deney var.
  • O komik danslar aslında "test yazma" ya da "plan yapma" ile benzer şeyler olabilir.
  • Buna dayanak oluşturan bir makale falan var mı? "güvercin numarası" diye aratınca sadece sosyal medya videoları çıkıyor, bulmak zor.
• "Augmented Engineering" (AE) adı daha iyi. AI'ın gücüyle kapasitenizi genişletip en iyi sonuçları alabiliyorsunuz; yani bu gerçekten "artırılmış mühendislik". AE aynı zamanda "Advanced Engineering" diye de okunabilir. AI en yeni teknik bilgiye anında erişim sağladığı için bu doğal olarak daha gelişmiş bir mühendislik oluyor. Vibe ise pek iyi değil.
  • Bence terminolojiye bu kadar takılmaya gerek yok; ayrı bir isim vermek, AI ile kodlamayı sanki yalnızca bazı geliştiricilere özgü bir şeymiş gibi hissettirebilir. Gelecekte geleneksel kodlama istisna olacak ve bugünkü vibe lafı da yakında kaybolacak.
  • Son cümleye itirazım var. AI yalnızca güncel mühendislik bilgisini anında anlamanıza yardımcı olmuyor; son 1-10 yılda tekrarlanmış hataları, yanlışları, yanlış anlamaları ve tasarım kusurlarını da "anında" içeri alabiliyor. Yani AI'ın verdiği bilgiyi asla eleştirmeden kabul etmemek, kaynakları mutlaka kontrol etmek ve o kaynakların bile AI üretimi olmadığını doğrulamak gerekiyor. Veri setleri giderek kirlendiği için daha da dikkatli olunmalı.
  • "Augmented Engineering"in gerçekten ayrı bir isim olması gerekip gerekmediğini sormak isterim. Sonuçta bu sadece "mühendislik"; nasıl kitap kullanınca buna "book-assisted engineering" demiyorsak, vibe da aynı. Hatta isterseniz buna "Yolo engineering" ya da "Machine Outsourced Irresponsible LMAO Engineering" bile diyebilirsiniz. Sonundaki "Advanced Engineering" kısmı da bana biraz abartılı geliyor.
• Simon her zaman tam olarak meselenin özünü yakalıyor. Ama asıl sorun bence "coding" değil, "vibe" kelimesi. Buna vibe engineering deseniz bile, hâlâ "ne yaptığını tam bilmeden öylece ilerlemek" gibi bir anlam taşıyor. En azından "AI-assisted software engineering" gibi bir terim iki ucu daha net ayırabildiği için daha iyi görünüyor.

[kimjoin2]

Anlamsız adlandırmalar uydurmak;