Her Şeyi Vibe Coding Olarak Adlandırmayı Bırakmalıyız

Uzun bir aradan sonra kodlamaya geri döndüm ve Lovable, tekrar başladığım yerdi. Uygulamalar harika görünüyordu, ilk bakışta çalışıyordu ve birkaç saat içinde bir araya geliyordu. Başlangıçta bu olağanüstü bir his verdi. Ancak kodun ne yaptığını ve neden yaptığını öğrenmek istediğim anda bu yeterli olmaktan çıktı. İşte o anda yaklaşımım değişmeye başladı.

Fark aracın kendisi ya da AI’nin sizin için yazdığı kod miktarıyla ilgili değildir. Önemli olan çıktınızla kabul ettiğiniz sözleşmedir: dünyaya yeni yayımladığınız şeyi açıklayabilir misiniz, yoksa açıklayamaz mısınız.

Vibe coding, orijinal anlamıyla, AI tarafından üretilen yazılımı altında ne olduğunu düzgün bir şekilde incelemeden ya da anlamadan kabul etmek demektir. AI‑destekli geliştirme ise farklıdır. Model hâlâ kodun büyük bir kısmını yazabilir, ancak sistemi inşa eden kişi davranışını anlamak, varsayımlarını test etmek ve yayına hazır olup olmadığını karar vermekle sorumludur.

Kendi makinenizden hiç çıkmayan tek kullanımlık bir deney için bu ayrımın çok az etkisi olabilir. Yazılım dağıtıldıktan, başkaları tarafından kullanıldıktan ya da gerçek verilerle bağlandıktan sonra ise önemi çok büyük olur.

How “Vibe Coding” Lost Its Meaning

“Vibe coding” terimi, OpenAI’nin kurucu ortağı Andrej Karpathy tarafından Şubat 2025’te ortaya atıldı. Örneği kasıtlı olarak rahat bir yaklaşımı yansıtıyordu: “Kabul Et Hepsini” düğmesine otomatik olarak tıklanarak, farklar göz ardı edilerek ve kodun yazarının anlayışının ötesine büyümesine izin verilen bir “haftasonu atıl proje”.

Haftalar sonra, geliştirici ve araç üreticisi Simon Willison, terimin çok farklı bir şekilde kullanıldığını fark etti: her türlü AI‑destekli programlamanın yerine geçen bir terim olarak. Bu durumun terimi sulandırdığını ve sorumlu AI‑destekli geliştirmenin neler başarabileceği konusunda yanlış bir izlenim yarattığını savundu.

İlginç olan, Karpathy’nin sonunda bu görüşe katılmasıdır. Bir yıl sonra, daha disiplinli bir kodlama ajanları çalışması için farklı bir terim tanıttı. “Agentic engineering”i, geliştiricilerin ajanları yönlendirdiği ve denetlediği, sadece ürettiklerini kabul etmedikleri bir iş akışı olarak tanımladı. Ayrım önemlidir: profesyonel AI‑destekli geliştirme, rahat vibe coding’in sunmadığı planlama, inceleme ve hesap verebilirlik gerektirir.

The Line Is Responsibility

Willison’ın kuralı basittir ve herkes için bir test olarak işe yarar: başkalarına açıklayamadığınız kodu commit etmeyin. Bu, her satırı okumak anlamına gelmez: ajanların bir anda yüzlerce satır üretmesiyle, deneyimli geliştiriciler bile artık bunu yapmaz. Önemli olan temel mantığı anlamak ve kodun tam olarak neden bu şekilde davrandığını gerekçelendirebilmektir. Bunu yapabiliyorsanız, modelin mi yoksa sizin mi yazdığı önemli değildir: bu vibe coding değildir, bir aracı kullanarak yazılım inşa etmektir.

Aralık 2025’te yayınlanan araştırma bu ayrımı destekliyor. Alan gözlemleri ve profesyonel geliştiriciler üzerine yapılan nitel bir anketle, deneyimli uygulayıcıların tüm süreci AI’ye devretmek yerine yazılım tasarımı ve uygulaması üzerinde kontrolü ellerinde tuttuğu bulundu. Ajanları iş birliği olarak gördüler, çalışmalarını dikkatle planladılar ve denetimde aktif kaldılar.

Dolayısıyla sadece deneyim bu durumu açıklamaz. Önemli olan, AI’nin ürettiği şeyin sorumluluğunu üstlenmeye istekli olup olmadığınızdır. Bu, her geliştiricinin her proje için tekrar tekrar vermesi gereken bir karardır.

What Happens When Control Is Missing

Yazılımı güvenliğini anlamadan ya da doğrulamadan yayımlamanın sonuçları soyut değildir. Kadınların randevu sırasında güvende kalmalarına yardımcı olması amaçlanan bir uygulama olan Tea, iki güvenlik olayında on binlerce kimlik fotoğrafı ve bir milyondan fazla özel mesajı açığa çıkardı. Hatalar arasında güvensiz bir depolama kovası ve kimlik doğrulama gerektirmeyen ayrı bir veritabanı bulunuyordu.

Aynı temel sorun – yazılım çalışıyor gibi görünürken yetkilendirme mantığının tehlikeli derecede yanlış olması – Lovable platformu üzerinde inşa edilen bir uygulamada da ortaya çıktı: güvenlik araştırması yetkilendirme mantığının ters çevrildiğini buldu, oturum açmış kullanıcıları dışarıda bırakarak kimlik doğrulaması yapılmamış saldırganların serbestçe girmesine izin verdi, 18 000’den fazla kullanıcı, özellikle öğrenciler etkilendi.

Bunlar sadece “kötü” projelerde ortaya çıkan izole vakalar değildir. Google’ın 2025 DORA raporuna göre, geliştiricilerin %90’ı artık işte AI kullanıyor, ancak yaklaşık üçte biri ürettiği şeylere çok az ya da hiç güvenmediğini belirtiyor.

AI kullanımı artık yaygın, ancak güven hâlâ sınırlı. Bu da, üretilen kod kimlik doğrulama, izinler ya da hassas verilerle ilgilendiğinde titiz bir incelemenin özellikle önemli olmasını sağlıyor.

Control Is Built in Layers, Not All at Once

Benim durumumda, resmi bir güvenlik denetimiyle başlamadım. Bir şeyin neden o şekilde davrandığını açıklayamadığım her an ilerlemeyi reddettim – bir analist olarak işime getirdiğim doğal bir içgüdü. Sözdiziminden ziyade sonucun ilk ihtiyaçlarımızla eşleşip eşleşmediği beni ilgilendiriyor. Eşleşmediğinde derinlemesine araştırmaya devam ediyorum.

Projeler daha ciddi hale geldikçe iş akışım daha yapılandırılmış bir hâl alıyor. Sadece istemlere dayanmak yerine, bir şey üretmeden önce gereksinimleri hazırlamaya başladım. İş gereksinimlerini, teknoloji yığını ve entegrasyonları belgeledim. Ardından ana kullanıcı yolculukları için birim testleri ve Playwright testleri ekledim.

Güvenlik kontrolleri de aynı şekilde eklendi. AI’nin seçtiği kütüphaneleri inceledim ve yüklenen dosyalar için kötü amaçlı yazılım taraması başlattım. Her kontrol, baştan hazırladığım bir kontrol listesine uymaktan ziyade, “Sırada ne yanlış gidebilir?” sorusundan kaynaklandı.

Bu alışkanlık bir projede bir sorunu yakaladı. AI, kullandığım framework sürümüyle uyumsuz bir kütüphane ekledi. Uygulama tamamen çökmediği için uyumsuzluk fark edilmeden kalabilirdi. Daha sonra bulmak, nedeni tespit etmeyi çok daha zorlaştıracaktı.

Tea ve Lovable vakalarıyla karşılaştırıldığında bu sıradan bir problemdi. Erken buldum, düzelttim ve devam ettim. İnceleme genellikle pratikte böyle görünür. Çoğu zaman, küçük sorunların büyüyüp daha büyük problemlere dönüşmesini önler.

AI’nin kod üretmesi nedeniyle koddan şüphe duymuyorum. Uygulama çalışıyor diye de güvenmiyorum. Testler ve inceleme, kodun amaçlandığı gibi davranıp davranmadığını belirlemenin yoludur.

From Vibe Coding to Agentic Engineering

Karpathy’nin “vibe coding”den “agentic engineering”e geçişi sadece bir kelime değişikliği değildir. “Agentic engineering”, profesyonel gelişimin yöneldiği yolu daha faydalı bir isimle tanımlıyor. Geliştiriciler daha az satır yazabilir, ancak bu sorumluluklarını azaltmaz. Çalışmaları, sistemin ne yapması gerektiğini belirlemeye, ajanları yönlendirmeye, çıktıyı test etmeye ve neyin güvenli bir şekilde yayımlanabileceğine karar vermeye kayar.

Tehlike, AI’nin kodu hızlı üretmesi değil. Üretimin, anlayıştan daha hızlı ilerleyebilmesidir. Bu gerçekleştiğinde, görünürdeki verimlilik, kimsenin doğru bir şekilde incelemediği riskleri gizler.

A Rule Worth Keeping

“Vibe coding”i her türlü AI‑destekli geliştirme için bir etiket olarak kullanmayı bırakın – bu terimi sulandırır ve önemli bir kontrol ayrımını ortadan kaldırır. Basit bir kural koyun: açıklayamadığınız şeyi yayına çıkarmayın. Ve proje büyüdükçe, katman katman kontrol ekleyin, ortaya çıkan risklerle uyumlu denetimler ekleyin.

AI kodun çoğunu yazabilir. Ancak onu yayına çıkarmanın sorumluluğunu üstlenemez. Bu sorumluluk hâlâ bize aittir.