Vibe coding sorun değil. Vibe architecture sorun.

Vibe coding hakkında konuşurken iki ayrı şeyi birbirine karıştırıyoruz. Birincisi, doğal dille bir fikri tarif edip AI'ın hızla çalışan kod üretmesini sağlamak. İkincisi ise AI'ın ürettiği her teknik kararı sorgulamadan ürün mimarisine kabul etmek. Ben birincisini problem olarak görmüyorum. İkincisini görüyorum.

Vibe coding hız yöntemidir. Vibe architecture ise karar verme sorumluluğunun ortadan kaybolmasıdır.

Bir landing page, küçük bir iç araç veya fikri doğrulamak için hazırlanan prototipte hız çoğu zaman doğru optimizasyondur. Sorun prototipin bir gün fark edilmeden production sistemine dönüşmesiyle başlıyor. O anda dün geçici olan tablo, auth kuralı, cache yaklaşımı veya component sınırı bugün bütün ürünün taşıyıcı kolonuna dönüşebiliyor.

Kod kalitesinden önce karar sahipliğine bakıyorum

AI'ın yazdığı kod sentaktik olarak temiz olabilir. TypeScript geçebilir. Lint hatası olmayabilir. Yine de sistem yanlış olabilir. Çünkü mimari kalite tek tek dosyaların ne kadar temiz olduğundan değil, kararların birbiriyle ne kadar tutarlı olduğundan çıkar.

1type ArchitectureDecision = {2  owner: 'human';3  reason: string;4  constraints: string[];5  sourceOfTruth: string;6  reversible: boolean;7};

Bir agent'ın neden ikinci bir state store kurduğunu, neden doğrudan Supabase tablosuna bağlandığını veya neden yeni bir route yarattığını açıklayamıyorsanız problem kod stilinden daha büyük. Sistem karar üretmiş ama bu kararın sahibi yok.

Vibe architecture'ın ilk belirtisi: aynı şey için birden fazla gerçek

En sık gördüğüm sinyal çift kaynak doğrusu. Aynı görev bir component state'inde, bir context'te, localStorage'da ve cloud tablosunda farklı biçimlerde tutulmaya başlıyor. Her katman kendi başına mantıklı görünüyor. Birlikte ise senkronizasyon problemi yaratıyor.

1const taskSources = [2  'componentState',3  'context',4  'localStorage',5  'supabase',6];7
8// Soru: canonical state hangisi?

Bu sorunun tek ve açık cevabı yoksa agent'a daha iyi prompt yazmak yetmez. Önce sistemin gerçekliğini belirlemek gerekir.

İkinci belirti: her bug yeni abstraction doğuruyor

AI araçları abstraction üretmekte çok iyi. Bir modal sorunu için yeni provider, wrapper, hook ve coordinator birkaç dakika içinde yazılabilir. Fakat hızlı üretilebilmesi gerekli olduğu anlamına gelmiyor.

1const fixRule = {2  first: 'smallest durable fix',3  second: 'reuse existing architecture',4  onlyThen: 'introduce abstraction',5};

Benim kuralım basit: yeni abstraction ancak en az iki gerçek kullanım noktası varsa ve mevcut model problemi ifade edemiyorsa ortaya çıkmalı. Aksi halde abstraction teknik borcu saklayan dekorasyona dönüşebiliyor.

Üçüncü belirti: component'ler doğrudan altyapı kararı veriyor

UI component'i kendi başına hangi tablodan ne zaman veri çekeceğine, ne kadar cache kullanacağına ve başarısızlıkta nasıl retry edeceğine karar veriyorsa ürün büyüdükçe ağ davranışı dağılır. Bu yalnızca performans problemi değil; maliyet ve tutarlılık problemidir.

1// Kötü sınır2function Widget() {3  return supabase.from('tasks').select('*');4}5
6// Daha iyi zihinsel model7function Widget() {8  const tasks = useTasksDomain();9  return render(tasks);10}

Component veri kullanmalı. Veri stratejisini icat etmemeli.

Dördüncü belirti: agent başarıyı kendi tanımlıyor

Bir agent'ın 'done' demesi acceptance değildir. Eğer görevin başarı ölçütünü önceden siz tanımlamadıysanız agent doğal olarak ulaşabildiği en yakın başarı sinyalini kullanır: dosya yazıldı, typecheck geçti veya build oluştu.

Ben vibe coding'i nasıl sınırlandırıyorum?

Hızdan vazgeçmiyorum. Hızı mimari sınırların içine alıyorum. Agent'a yalnızca yapılacak işi değil korunacak gerçekliği de veriyorum.

1const agentContract = {2  goal: 'specific outcome',3  preserve: ['current design', 'canonical data flow', 'existing routes'],4  forbidden: ['parallel architecture', 'new dependency without need'],5  acceptance: ['typecheck', 'build', 'runtime verification'],6};

• Repository ve branch görevin başında doğrulanır.
• Kaynak doğrusu açıkça belirtilir.
• Yeni sistem kurmak yerine mevcut sistem incelenir.
• Değişiklik kapsamı dosya veya domain düzeyinde sınırlanır.
• Agent'ın doğrulayamadığı şey 'tamamlandı' kabul edilmez.
• Production'a giden yol ile prototip yolu birbirinden ayrılır.

Asıl beceri artık daha çok kod yazmak değil

AI çağında kod miktarı giderek daha kötü bir yetkinlik metriği oluyor. Beş dakikada bin satır kod üretebiliyorsak değer, o bin satırdan hangisinin hiç yazılmaması gerektiğini anlayabilmekte.

AI ile iyi ürün geliştirmek, modele sınırsız güç vermek değil; doğru sınırlar içinde yüksek kaldıraç vermektir.

Bu yüzden vibe coding'i bırakmayı değil, vibe architecture'a izin vermemeyi öneriyorum. Kod hızlı olabilir. Mimari rastgele olmamalı.