Kusurlarla Dolu Kule, Vibe Bulantısı ve Vibe Kızağı

• LLM tarafından üretilen kodu insanlar anlamasa bile yeniden LLM’e yorumlatıp geliştirmeye devam etme yaklaşımı yaygınlaştıkça, bir zamanlar ayrı görülen agentic engineering ile vibe coding arasındaki sınırlar hızla bulanıklaşıyor
• Vibe kızağı, otomatik tamamlamadan kod üretimine, incelemeden vazgeçmeye ve prompt yazmaktan vazgeçmeye uzanan önceden belirlenmiş yolu ifade ediyor; üretim hızından ne kadar yararlanılırsa programcının temel rolleri olan teori kurma ve incelemeden o kadar uzaklaşılıyor
• Pvote deneyinde güvenlik uzmanları, konumu önceden bilip 100 satır kodu yaklaşık 20 saat incelemelerine rağmen üç hatadan zor olanı bulamadı; bu da insanların büyük miktardaki LLM çıktısını eksiksiz inceleyebileceği varsayımının gerçekçi olmadığını gösteriyor
• Anlaşılmamış kod ve üretimler restoran posterlerine, müşteri destek sohbet botlarına, yaş doğrulama koduna, açık kaynak issue ve PR’larına kadar sızan bir vibe bulantısı yayıyor; bu araçları kullanmayanlar bile başkalarının üretimlerini incelemek zorunda kaldığı için etkileniyor
• Üretken yapay zeka sorun bulmada yararlı olabilir, ancak üretim tarafında özellikle zayıf; anlaşılmaz sistemlerin dünyanın yerini aldığı bu akış içinde bile insanların daha iyi bir ortamı doğrudan kurma becerisinden vazgeçmemesi gerekiyor

---

Anlaşılmaz Kodun Kulesi

• The Tower Keeps Rising, geçmişte ekip üyelerinin konuşarak çözmesi gerekecek durumlarda bile agent kullanarak ilerlemeye devam edilebildiği bir durumu gözlemliyor
  • Armin bunu iyi ya da kötü bir şey olarak değerlendirmedi; sürdürülebilir bir durum olduğunu da savunmadı
  • Ancak bir vibe coding şirketi yöneterek bu akışı ilerleten bir konumda bulunuyor
• Vibe coding sistemleri kod ve soyutlamaları üst üste yığmaya devam edip sonunda hiçbir insanın kod tabanını anlamadığı bir duruma ulaşabilir
  • İnsanların anlayamadığı kısımları da LLM yeniden yorumlayabildiği için geliştirmeye devam edilebilen yeni bir işletim biçimi ortaya çıkıyor
• Bunu savunan tarafta bile insanların sistemi anlamadığı nihai nokta kabul ediliyor ve bu durumu geleceğin geliştirme yöntemi olarak benimseyen bir değişim görülüyor

Agentic Engineering ile Vibe Coding Arasındaki Sınırın Çöküşü

• Simon Willison başlangıçta agentic engineering kavramını vibe coding’den açıkça ayırmıştı
  • Mart 2025 tarihli yazısında, production kalitesinde yapay zeka destekli programlama söz konusuysa depoya commit edilen her kodun okunabilmesi ve başka birine doğru biçimde açıklanabilmesi gerektiği ilkesini ortaya koydu
  • LLM tarafından yazılmış olsa bile kod insan tarafından inceleniyor, kapsamlı şekilde test ediliyor ve çalışma biçimi açıklanabiliyorsa bunun vibe coding değil yazılım geliştirme olduğunu ayırdı
• Yaklaşık bir yıl sonra Vibe coding and agentic engineering are getting closer than I’d like yazısında ise coding agent’ların güvenilirliği arttıkça production kodunda bile her satırı incelemez hale geldiğini belirtti
  • Claude Code’un SQL sorgusu çalıştırıp JSON döndüren bir API endpoint’ini doğru biçimde oluşturacağına, testleri ve dokümantasyonu da ekleyeceğine güveniyor
  • Aynı zamanda incelenmemiş kodu production’da kullanmanın sorumlu bir davranış olup olmadığı konusunda suçluluk ve şüphe duyuyor
• İki tutum arasındaki mesafe bir yıldan biraz fazla
• Agentic engineering’in doğru kullanım biçimi olduğu algısı yaygınlaşmış olsa da gerçek kullanıcılar, Simon’ın kendisi dahil, vibe coding tarafına çekilme eğilimi gösteriyor

Vibe Kızağı

• Kızak, buz pistinde hızla aşağı inilen ancak gidilecek yönün fiilen tek olduğu bir spor
  • Sporcular becerilerini yarıştırabilir ve heyecan yaşayabilir, ancak yolculuğun kendisini seçme alanları çok geniş değildir
• Vibe kızağında LLM araçtır, kullanıcı ise yolcudur
  • Kullanıcının hissettiğinden çok daha az gerçek kontrolü vardır; bu basitçe kaygan bir eğimden çok, önceden hazırlanmış bir yolculuğa yakındır
• Geliştirici şu aşamalardan geçerek kod üretim sürecinden kendisini çıkarır
  • Başta bunu yalnızca gelişmiş otomatik tamamlama olarak kullandığını düşünür
  • Sonra fikir keşfi için agent çalıştırır ama kodu kendisinin yazacağını söyler
  • Ardından agent kod üretir, fakat tüm sonuçları inceleyeceğine söz verir
  • Kısa süre sonra kodu neredeyse hiç incelemeden agent’ın kendisinden daha iyi bir geliştirici olabileceğine inanmaya başlar
  • Son aşamada “artık kod yazmıyorum”un ötesine geçip “artık prompt da yazmıyorum” noktasına yönelebilir
• Her aşama, LLM’in kendi işini anladığına ve iyi yaptığına dayanan güven temelli kod üretimine doğru ilerleme sürecidir

Üretim Hızı ile İncelemenin Çatışması

• Kodlamada yavaş olan kısım üretim değil, teori kurma ve incelemedir; makul görünen ama hatalı sonuçları debug etmek ve anlamak çok zordur
• LLM’in en güçlü özelliği üretim hızı olduğundan, insan tüm sonuçları incelerse bu hızdan yeterince yararlanmak zorlaşır
• Buna karşılık teori kurma ve inceleme programcının en önemli rolüdür; bu yüzden LLM’in avantajı en üst düzeye çıkarıldıkça temel rolden uzaklaşma çatışması doğar
• Ka-Ping Yee’nin Building Reliable Voting Machine Software makalesi, yazılım doğrulamayı zorlaştıran etkenler olarak şu dört unsuru sayar
  • Bileşen sayısı
  • Karmaşık etkileşimler
  • Geniş kapsamlı etkiler
  • Doğrusal olmama
• Bu dört sorun, LLM’in kod üretme biçimiyle daha da ağırlaşabilir

Pvote Hata İnceleme Deneyi

• Ka-Ping Yee ve David Wagner, model oylama makinesi Pvote’a seçim sonucunu değiştirmek için kötüye kullanılabilecek kolay, orta ve zor olmak üzere birer hata ekledi
• Üç hata da Navigator.py dosyasının 11–109. satırlarına denk gelen 100 satırlık alana yerleştirildi
  • Program mantığı açısından ilginç bir bölüm olması ve inceleyicilerin sınırlı zamanı düşünülerek yapılan bir seçimdi
  • İnceleyicilere bakmaları gereken alan söylendi, ancak kaç hata olduğu söylenmedi
• Üçüncü günün inceleme sonuçları şöyleydi
  • Python’a çok hâkim olan Dan Sandler, yaklaşık 70 dakika içinde kolay ve orta hatayı buldu
  • Yoshi Kohno ve Mark Miller, yaklaşık 4 saat sonra kolay hatayı keşfetti
  • Zor hatayı kimse bulamadı
• Dördüncü gün Ian Goldberg yaklaşık 2 saat içinde kolay hatayı buldu, ancak diğer hataları tespit edemedi
• Deneyimli güvenlik uzmanları konumu bile biliyordu, ancak toplamda yaklaşık 20 inceleyici-saat harcamalarına rağmen üç hatanın tamamını bulamadı
• Mark S. Miller daha sonra hataları gördüğünde, hepsinin bariz hatalar olduğu ve kendilerinin bunları bulmuş olması gerektiği konusunda herkesin hemfikir olmasına şaşırdı
• En üst düzey programcılar bile 100 satır içinde mutlaka bulunan hataları kaçırıyorsa, insanların LLM’in devasa çıktısını incelemesine dayanan yöntem başa çıkılması zor bir hale gelir
  • Sonunda kullanıcı incelemeden vazgeçer ve kod üretim sürecinden kendisini aşamalı olarak çıkarır

AI Psikozu ve Vibe Bulantısı

• “AI psychosis” ifadesi, üretken yapay zekadan kaynaklanan kötü davranış veya sonuçların geneli için geniş biçimde kullanılıyor; ancak aslen kullanıcıyı aşırı onaylayan sohbet botlarıyla etkileşim sırasında gerçek psikoz ve sanrılı gerçeklikten kopuş yaşanan duruma daha yakındı
• Klinik psikoz olmayan, üretken yapay zekanın yol açtığı geniş çaplı rahatsızlık için vibe bulantısı (vibe sickness) daha uygun
• Glyph’in PyCon US 2026 değerlendirmesinde şu durumlar aynı anda görülüyor
  • Yaygın vibe bulantısı
  • Açık kaynakta büyük ölçekli sürdürülebilirlik krizi
  • Düşük kaliteli güvenlik PR’larının akını
  • Karşılıklı anlayış için umut, enerji ve çaba ile yapılan işe duyulan takdir

Günlük Hayata ve Açık Kaynağa Yayılan Üretimler

• İnsanlar düşük kaliteli üretimler olan slop’tan şikâyet ediyor, ancak üretken yapay zeka kullanıcıları kendi çıktılarına slop demiyor
• İnandırıcı görünen ama anlaşılmaz üretimler günlük hayatın her yerinde ortaya çıkıyor
  • Anlaşılması zor tasarımlara sahip yerel restoran posterleri
  • Kullanıcıları bezdiren müşteri destek sohbet botları
  • Yaş doğrulama kodu
  • Açık kaynak projelere gönderilen düşük kaliteli issue ve PR’lar
• Bu araçlar bazı işler için yararlı ve sorun bulma açısından farklı değerlendirilebilir
• Ancak “genAI” adının vurguladığı üretim, aslında aracın en zayıf olduğu taraf
  • Yalnızca üretimlerin kalitesi değil, sistemlerin nasıl kurulduğu, yapılandırıldığı ve sürdürüldüğünün kimse tarafından anlaşılmaması sorunu da ortaya çıkıyor

Üretken Yapay Zekadan Kaçmanın Mümkün Olmadığı Ortam

• Üretken yapay zekayı doğrudan kullanmasanız bile iş arkadaşları veya açık kaynak katkıcıları, kendilerinin de anlamadığı üretimleri “katkı” olarak gönderebilir
  • İnceleyen kişi, bunun LLM üretimi olup olmadığını sormanın kaba olup olmadığını düşünmek zorunda kalır
  • Issue veya PR’lara yanıt verirken agent ile dolaylı olarak etkileşime girer ve istemeden vibe coding iş akışına katılmış olur
• Glyph, LLM içeren tüm yazılımları reddetmeyi; otomobillerde esnek yakıt kullanımına itiraz etmek için herkes kullanmayı bırakana kadar nefesini tutmaya benzetiyor
  • Gerçekçi olarak bir ölçüde kabul etmek zorunda kalındığından, kişisel bir etik çizgi belirlense bile bu üretken yapay zeka ortamına yönelik beklenti veya heyecan anlamına gelmez
• Uncanny valley gerçek dünyayı işgal ederken, kimsenin anlamadığı sistemler mevcut dünyanın yerini alıyor
• Bu durumdan toparlanırken ödenecek bedel henüz bilinmiyor; mevcut üretken yapay zekaya katılmamayı seçen projeler saygıyı hak ediyor

Daha İyi Bir Zemin Yaratma Seçimi

• İş veya ortam nedeniyle üretken yapay zeka sorunlarına katkıda bulunmayı tamamen reddedemeyebilirsiniz
• Otomobil sürücüleri yoldaki bisikletlilere kızsa da bisiklet altyapısı yetersizse kullanıcılar park halindeki araç kapıları veya sabırsız sürücüler yüzünden tehlikeye girer
• Araç kullanırken önünüzde bir bisiklet varsa onun varlığı için minnet duyabilir, bisikletlerin daha güvenli katılabilmesi için zemini ve altyapıyı değiştirmenin yollarını düşünebilirsiniz
  • Böyle bir değişim otomobil kullanmayı kolaylaştırır ve duruma göre bisikleti seçmeyi de kolaylaştırır
• Teknolojinin belirlediği rotaya kendinizi bırakmak yerine, insanların doğrudan katılıp daha iyi bir dünya kurabileceği inancından vazgeçmemek gerekir

[GN⁺]

Lobste.rs görüşleri

• Son dönemde kaygıyla izlediğim yazılım mühendisliği sektöründeki değişimi ele alan yazılar arasında açık ara en iyi yazılmış olanlardan biri

• Daha bir yıl önce ajan tabanlı mühendislik arzu edilen yön gibi görünüyordu, ama pratikte araçları kullananların çoğu bunu kabul etmeye çekinse de vibe coding tarafına kayıyor gibi. LLM’lerin benim becerilerimi ve tutkumu değersiz kılabileceği korkusu, iki ilke belirledikten sonra büyük ölçüde azaldı
  Birincisi, boş zamanlarımda LLM ya da kodlama ajanı kullanmıyorum ve aramanın AI özelliklerini de reddediyorum. Yalnızca kendi başıma çözemeyecek kadar sıkışırsam, halüsinasyon riskini göze alıp kullanıyorum. Teknolojiyi görmezden gelmek dünyayı çözmüyor ama bireysel geliştiricilere saldırmanın ya da büyük şirketleri değiştirmenin mümkün olmadığı bir durumda, en azından boş zamanımı buna dahil etmemek gerçekçi bir tercih
  İkincisi, AI kullanımının güçlü biçimde teşvik edildiği iş yerimde bile onu yalnızca kod inceleme ve angarya işler için kullanıyorum. Kod tabanında doğrudan bulunabilecek ama arayıp çıkarması zahmetli şeyleri sormak gibi; kodun tamamını ise kendim yazıyorum. Ancak böylece nasıl çalıştığını sezgisel olarak anlayabiliyor ve hem kendimin hem ekip arkadaşlarımın beklediği seviyede çalışabiliyorum
  LLM’ler, deterministik bir linter’ın bulamadığı örüntü temelli hataları yakalayan yardımcı araçlar olarak fena değil. Saçma cevaplar da veriyorlar ama kodu kendim yazıp anladığım için körü körüne güvenmiyorum. İnsan incelemesinden önce bariz mantık hatalarını ve yanlış varsayımları ayıklarsa, ekip arkadaşlarım daha karmaşık kısımlara odaklanabiliyor ve kamusal kanallarda insanlar yerine makineleri birbirleriyle konuşturmanın kabalığından da kaçınılmış oluyor
  Şirketim yakın zamanda token kullanımına sıkı sınırlar koydu ama günlük maliyeti 1-2 avro olan bir iş akışım olduğu için endişelenmiyorum. Tamamen sezgiye yaslananlar yeniden insan muhakemesi kullanmak zorunda olmaktan kaygı duyabilir ama geri kalanımız bunu ekip arkadaşlarımızla doğrudan yapabilir

  • “Kafanı kuma gömmekle bir şey çözülür mü” eleştirisi, gerçek bir üçüncü kişiden çok hayalî bir eleştirmen adına kişinin kendi kendine söylediği bir söz gibi. Böyle eleştirileri fazla dikkate alarak seçim yaptıkça hayat kötüleşiyor; ben de buna karşı dikkatli olmaya çalışıyorum
    Bunun altında, ne kadar acı verirse versin gerçeğe bakmak gerektiğini savunan kendine eziyet eden bir epistemoloji de var. Rahatsız edici bilgiden kaçınırsan erdemsizmişsin gibi gelebilir ama dikkat sınırlı bir kaynak; onu daha mutlu ve dolu hissettirip yarın da devam etme gücü veren şeylere harcamak daha iyi
  • Bu, kafayı kuma gömmekten çok “ofis çalışmasından hoşlanmadığım için boş zamanımda ofisten uzak duruyorum” demeye daha yakın. Keyif vermeyen bir şeyi kaçınabiliyorsan kaçınmak mantıklı
    Hayattaki her şeyi optimize edilmesi ve en iyisi olunması gereken bir iş gibi görenler aslında daha çok kaybediyor. Kod yazmayı seviyorsan boş zamanında da yaparsın; sevmiyorsan bunu yalnızca meslek olarak bırakabilirsin. Boş zamanda bazen verimsiz olmakta sorun yoktur; aksi halde serbest zaman ikinci bir işe dönüşür ve insan hiç dinlenemez

• Burada Fawlty kelimesinin yanlış yazılmış olması gereğinden fazla rahatsız edici

  • “Sorun çıkaran” Babil Kulesi şeklinde bir kelime oyunu olduğu için bilerek öyle yazılmış gibi görünüyor

• Yazı her zamanki gibi harika ama bunun LLM üretimi olup olmadığını sormanın kaba olup olmayacağını düşünmeye gerek yok gibi. Üretim sürecinde LLM kullanılmış olsun ya da olmasın, ortaya kötü bir sonuç çıktıysa kalitesinin düşük olduğunu ve hoşuna gitmediğini söyleyebilirsin

  • Tanımadığın yeni bir katkıcıysa, PR’daki kalite sorunlarını işaret edip düzeltme sorumluluğunu ona geri vermek mantıklı. Ama Zig projesinin, yeni katkıcıları uzun vadeli katkıcılara dönüştürmek için LLM yerine doğrudan insan rehberliği vermek amacıyla AI karşıtı bir politika benimsediğini hatırlıyorum
    Öte yandan, iş arkadaşın ya da internette uzun süredir görüştüğün biriyle ilişkinin sürmesi için mümkün olduğunca kaba olmaktan kaçınmak isteyebilirsin. Katkının nasıl üretildiğini bilmek, konu hakkında sağlıklı konuşabilmek için gerekli olabilir ve bunun sonucu ilişki üzerinde bilinçli olarak büyük etki yaratabilir. Kabalık riskini göze alıp almamak ya da varsayılan olarak çatışmadan kaçınıp ilişkiyi korumak, mizaca bağlı bir seçim
    Ben zaten çatışmadan kaçınan biriyim; o yüzden bu cümlenin çıktığı bağlamı anlıyorum ve asıl iddiaya da büyük ölçüde karşı değilim

• Bobsled benzetmesini sevdim. LLM kullanıcılarının mutlaka sonuna kadar aşağı ineceği iddiasına katılmıyorum ama sektörde gözlenen davranışı şimdiye kadar gördüğüm tüm benzetmelerden daha iyi anlatıyor

• “Bobsled benzetmesi”, mantık hatası olan kaygan zemin diye daha iyi biliniyor. Bir yıl önce vibe coding oranı %0’dı ve Simon Willison, kodlama ajanlarını temkinli biçimde devreye alıp zamanla güvenini artırma sürecini birçok yazıda paylaştı
  Buna rağmen buradan “gidilecek tek yer var” sonucunu çıkarıyor. Willison’ın ve diğer kullanıcıların da tercihleri ve muhakemesi olduğunu varsaymak daha makul