Vibe Coding’de Feature Flag: AI Kodunu Kademeli Yayınlama Rehberi

Vibe coding ile yeni bir özelliği çalışır hâle getirmek, onu bütün kullanıcılara aynı anda açmanız gerektiği anlamına gelmez. Yapay zekâ tarafından üretilen kod; hızlı prototip, beklenmeyen bir sınır durumu veya performans sorunu taşıyabilir. Vibe coding feature flag yaklaşımı, özelliğin kodda bulunması ile kullanıcıya görünmesi arasına kontrollü bir kapı koyar.

Bu kapı sayesinde yeni akışı önce geliştirici hesabında, sonra küçük bir kullanıcı grubunda, en son da herkeste açabilirsiniz. Sorun çıktığında eski sürümü yeniden derlemeden özelliği kapatabilirsiniz. Bu rehberde feature flag’in ne olduğunu, AI kodlama akışında nasıl tasarlanacağını ve unutulmuş bayrakların nasıl temizleneceğini adım adım ele alıyorum.

Feature flag nedir?

Feature flag, bir özelliğin çalışıp çalışmayacağını belirleyen çalışma zamanı kararıdır. Basit bir koşul gibi görünse de iyi tasarlandığında yayın stratejisini koddan ayırır. Aynı uygulama paketi, farklı kullanıcılar için farklı özellik durumları gösterebilir.

if (flags.newSearchExperience) {
  showNewSearch();
} else {
  showClassicSearch();
}

Buradaki örneğin değeri koşulun kendisinde değil, newSearchExperience kararının merkezi ve izlenebilir olmasındadır. Flag değeri uzaktan, yapılandırmadan veya güvenilir bir kullanıcı kuralından gelebilir. Kaynak ne olursa olsun, uygulama güvenli varsayılan davranışı korumalıdır.

Vibe coding projelerinde neden gereklidir?

AI ile kod üretirken küçük bir istek, birden fazla dosyada değişiklik oluşturabilir. Özellik derleniyor olsa bile gerçek cihaz, zayıf ağ, izin reddi veya eski veri gibi koşullar yeterince görülmemiş olabilir. Feature flag şu dört riski sınırlar:

• Yayın riski: Özelliği herkese açmadan gerçek kullanıcı davranışını gözlemleyebilirsiniz.
• Geri alma riski: Acil durumda kodu geri göndermeden akışı kapatabilirsiniz.
• Deney riski: Yeni davranışı belirli bir grup üzerinde sınayabilirsiniz.
• Bağlam riski: Ajanın yaptığı geniş değişiklikleri tek bir görünür kontrol noktasında tutabilirsiniz.

Feature flag, testlerin yerine geçmez. Özellikle eval-driven development yaklaşımındaki kabul testleri yine çalışmalıdır. Flag, doğrulanmış davranışı güvenli bir yayın planına bağlar.

Flag türlerini birbirine karıştırmayın

Her bayrağın amacı farklıdır. Tüm bayrakları “özellik açık mı?” şeklinde adlandırmak, birkaç hafta sonra yönetimi zorlaştırır.

Flag türü	Kullanım amacı	Yaşam süresi
Release flag	Tamamlanmamış özelliği kontrollü açmak	Kısa
Experiment flag	İki davranışı veya tasarımı karşılaştırmak	Deney boyunca
Permission flag	Plan, rol veya cihaz yeteneğine göre erişim vermek	Uzun olabilir
Kill switch	Riskli akışı acil olarak devre dışı bırakmak	Kalıcı kontrol

Özellik tamamen kararlı hâle geldiğinde release flag kaldırılmalıdır. Sadece gerçekten operasyonel bir kontrol olarak kalması gereken bayraklar uzun süre yaşamalıdır.

İyi bir flag sözleşmesi yazın

AI ajanına “bu özelliği flag ile sar” demek yeterli değildir. Flag’in sahibi, varsayılanı, kapanınca görülecek davranış ve silinme koşulu baştan yazılmalıdır.

Flag: profile_v2
Tür: release
Sahip: profil akışı
Güvenli varsayılan: mevcut profil ekranı
Açılma kuralı: yalnızca iç test kullanıcıları
İzlenecek sinyal: profil kaydetme hatası ve ilk ekran süresi
Kill switch: evet
Temizleme koşulu: tüm kullanıcılar 7 gün sorunsuz kullandığında flag koddan silinir

Bu sözleşme, kod incelemesi yapılmadan önce bile kararın sınırlarını görünür kılar. Ayrıca yeni bir sohbet açıldığında ajanın eski varsayımları uydurmasını engeller.

Güvenli varsayılan davranış tasarlayın

Bir flag servisine ulaşılamadığında, değer bozuk geldiğinde veya kullanıcı henüz değerlendirilmediğinde uygulamanın ne yapacağı açık olmalıdır. Güvenli varsayılan çoğu zaman mevcut ve daha iyi test edilmiş akıştır.

• Flag okunamazsa yeni özellik yerine eski akışı gösterin.
• Yeni ekranın verisi eksikse kullanıcıyı boş bir duruma bırakmayın.
• Flag kapandığında yarım kalmış yerel veriyi kaybetmeyin.
• Yeni ve eski akış aynı veri sözleşmesini kullanmıyorsa geçişi açıkça yönetin.

“Yeni özellik açılmazsa uygulama çalışmaz” şeklinde tasarlanan bir flag, güvenlik kapısı değil tek hata noktasıdır.

Kademeli yayın basamakları

Kademeli yayın, yüzdeleri mekanik biçimde artırmak değildir. Her basamakta bir soru sorup yanıtını kaydetmelisiniz. Kullanıcı sayısı kadar gözlemin niteliği de önemlidir.

1. Kapalı: Kod ve test hazırdır, gerçek kullanıcıya görünmez.
2. İç ekip: Geliştirici ve test hesapları uçtan uca akışı dener.
3. İzlenen küçük grup: Hata, performans ve temel iş metriği izlenir.
4. Genişletilmiş grup: Farklı cihaz, ağ ve kullanım alışkanlıkları görülür.
5. Genel yayın: Flag açık varsayılan hâle gelir ve temizleme tarihi başlatılır.

Basamak	Kontrol sorusu	Geri alma işareti
İç ekip	Akış kritik senaryolarda tamamlanıyor mu?	Veri kaybı veya kilitlenme
Küçük grup	Gerçek cihazlarda hata oranı kabul edilebilir mi?	Hata ve destek talebi artışı
Geniş grup	İlk değer ve performans eski akışla uyumlu mu?	İlk oturum terkinde sıçrama
Genel	Eski akış artık gerekli mi?	Flag’i kaldırmadan önce kritik veri kontrolü

Flag değerlendirmesini ölçülebilir yapın

Bir özelliği açmak yalnızca “açıldı” olayıyla izlenmemelidir. Flag’in hangi kullanıcıya, hangi sürümde ve hangi sonucu ürettiği kaydedilmelidir. Uygulamanızın gizlilik politikasına uygun, gerekli minimum veriyi tutun.

flag_evaluated {
  flag: "profile_v2",
  state: "on",
  source: "internal_group",
  app_version: "1.8.0",
  fallback_used: false
}

feature_outcome {
  event: "profile_saved",
  duration_ms: 820,
  success: true
}

Bu iki olay arasındaki ilişkiyi kurduğunuzda, yeni özelliğin yalnızca açıldığını değil, kullanıcıya değer üretip üretmediğini görebilirsiniz. Kişisel veri toplamadan da sürüm, flag durumu ve teknik sonuç çoğu karar için yeterlidir.

AI’a flag ekletirken sınırları belirtin

Vibe coding akışında ajanın mevcut kodu tamamen yeniden yazmasını önlemek için prompt’a değişmeyecek parçaları ekleyin. Ajanın kendi başına flag isimleri üretmesi, aynı özelliğin farklı yerlerde farklı kararlarla açılmasına yol açabilir.

İstek: profil akışını profile_v2 release flag’i ile sar.
Kurallar:
- Mevcut profil akışı güvenli varsayılan olarak kalacak.
- Flag değerlendirmesi tek bir provider üzerinden yapılacak.
- UI bileşenleri içinde yeni flag adı türetilmeyecek.
- Flag kapalıyken mevcut analytics olayları korunacak.
- Flag okuma hatasında eski akış açılacak.
- Testler açık, kapalı ve provider hatası durumlarını kapsayacak.
- Kod değişikliğinin sonunda flag sahibi ve temizleme tarihi dokümante edilecek.

Bu talimat, ajanın yalnızca “çalışan” kod üretmesini değil, geri alınabilir ve denetlenebilir bir değişiklik yapmasını hedefler.

Flag borcu nasıl oluşur?

Feature flag’in en yaygın yan etkisi, geçici bir kontrolün kalıcı karmaşıklığa dönüşmesidir. Bir flag uzun süre kaldığında her koşul iki ayrı kod yolu, iki ayrı test seti ve iki ayrı veri varsayımı üretir.

Her flag için şu dört alanı takip edin:

• Sahip: Kararı kim verecek?
• Oluşturulma tarihi: Ne kadar süredir yaşıyor?
• Sonraki karar: Hangi sinyalden sonra açılacak veya kapanacak?
• Silinme görevi: Kod ve test dalları ne zaman sadeleşecek?

Haftalık küçük bir flag listesi incelemesi, teknik borcun büyümesini önler. Özellikle vibe coding teknik borcu yazısındaki sürdürülebilirlik ilkeleriyle birlikte düşünülmelidir.

Kill switch ile acil geri alma planı

Kill switch, yeni özelliği kapatabilen bir kontrol olsa da tek başına acil durum planı değildir. Kapatma işleminin etkisini, eski akışa dönüşü ve yarım kalmış veriyi önceden test etmelisiniz.

1. Flag’i kapatınca kullanıcı hangi ekrana düşecek?
2. Yeni akışta oluşan veri eski akış tarafından okunabilecek mi?
3. Destek ekibi hangi sürüm ve flag durumunu görecek?
4. Kapattıktan sonra doğrulama ve duyuru kimin sorumluluğunda?

Bu sorulara yanıt yoksa kill switch yalnızca sahte bir güven hissi verir.

Feature flag’i ne zaman kaldırmalı?

Genel yayın tamamlandıktan sonra kodu sadeleştirmek için net bir kapanış koşulu kullanın. Örneğin yeni akış belirli bir süre boyunca hata sınırında kaldı, kritik metrikte gerileme göstermedi ve geri alma gerektirmediyse flag’i kalıcılaştırabilirsiniz.

Kaldırma işi üç parçadan oluşur:

1. Koşullu dalları tek bir kalıcı akışa indirin.
2. Artık gerekmeyen flag yapılandırmasını ve analytics olaylarını temizleyin.
3. Eski akışa ait testleri, dokümantasyonu ve ekran görüntülerini güncelleyin.

Flag’i kaldırmak, yalnızca bir satırı silmek değildir; iki olası ürün davranışı arasındaki belirsizliği sonlandırmaktır.

Vibe coding akışına yerleştirin

Vibe coding fikirleri hızlıca çalışan prototiplere dönüştürür. Feature flag, bu hızı güvenli yayın adımlarıyla birleştirir. İstek önce flag sözleşmesine, sonra kod ve test değişikliğine, ardından küçük grup ölçümüne dönüşür.

Akışın özeti şöyledir: özelliği tanımla, güvenli varsayılanı koru, flag’i tek noktadan değerlendir, küçük grupta izle, gerekirse kapat, kararlıysa kalıcılaştır ve flag borcunu temizle. Bu yaklaşım, AI tarafından üretilen kodun hızını korurken geri dönüş yolunu açık tutar.

30 dakikalık başlangıç planı

1. İlk 5 dakika: Açmak istediğiniz özelliği ve eski akışı yazın.
2. Sonraki 5 dakika: Flag türü, sahibi, güvenli varsayılanı ve kill switch kararını belirleyin.
3. 10 dakika: Ajan için flag sözleşmesi, kabul ölçütleri ve hata durumlarını yazın.
4. 5 dakika: Kademeli yayın basamaklarını ve izlenecek iki metriği seçin.
5. Son 5 dakika: Flag’in temizleme koşulunu ve sorumlusunu kaydedin.

Sonuç

Vibe coding feature flag yaklaşımı, AI kodunu yavaşlatmak için değil, değişikliğin etkisini sınırlamak için kullanılır. Özelliği küçük bir grupta görür, ölçer, kapatabilir ve kararlı hâle geldiğinde kodu sadeleştirebilirsiniz.

En iyi sonuç; merkezi flag değerlendirmesi, güvenli varsayılan, ölçülebilir yayın basamakları ve net bir temizleme tarihi birlikte uygulandığında alınır. Böylece hızlı üretilen kod, kontrolsüz bir sıçrama yerine geri dönüşü olan bir ürün adımına dönüşür.