AI ile oluşturulan uygulamalar için özellik bayrakları: riskli değişiklikleri güvenle yayınlayın

AI ile hızlı inşa ederken özellik bayrakları neden önemlidir

Özellik bayrağı, uygulamanızdaki basit bir anahtardır. Açık olduğunda kullanıcılar yeni davranışı görür; kapalıyken görmezler. Kodu anahtar yerinde gönderebilir, sonra ne zaman (ve kim için) açılacağına karar verebilirsiniz.

Bu ayrım, AI ile hızlı çalışırken daha da önem kazanır. Yapay zekâ destekli geliştirme dakikalar içinde büyük değişiklikler üretebilir: yeni bir ekran, farklı bir API çağrısı, yeniden yazılmış bir prompt veya model değişikliği. Hız harika ama aynı zamanda “çoğunlukla doğru” bir şeyi gönderip yine de gerçek kullanıcılar için temel bir akışı bozmayı kolaylaştırır.

Özellik bayrakları genellikle karışan iki eylemi ayırır:

• Kodu yayınlamak: yeni bir sürümü dağıtmak.
• Özelliği etkinleştirmek: kullanıcıların dağıttığınızı gerçekten kullanmasına izin vermek.

Bu ikisi arasındaki boşluk güvenlik yastığınız olur. Bir şey ters giderse, bayrağı kapatırsınız (acil kapatma) ve tam bir sürümü geri almak için telaşa girmezsiniz.

Bayraklar yeni kullanıcı akışları (kaydolma, onboarding, ödeme), fiyat ve plan değişiklikleri, prompt ve model güncellemeleri ile önbellekleme veya arka plan işleri gibi performans çalışmalarında zaman ve stres kazandırır. Asıl kazanç kontrollü maruziyettir: bir değişikliği önce küçük bir grupla test edin, sonuçları karşılaştırın ve metrikler iyi göründüğünde genişletin.

Koder.ai gibi vibe-coding tarzı bir platform üzerinde inşa ediyorsanız, her “hızlı değişiklik” için bir kapatma düğmesi ve kimlerin önce göreceğine dair net bir plan olduğunda hızınız daha güvenli hale gelir.

Gerçekçi ve sürdürülebilir bir bayrak modeli

Bir bayrak çalışma zamanı anahtarıdır. Yeni davranışı zorunlu kılmadan davranışı değiştirir ve bir şey ters giderse hızlıca geri dönmenizi sağlar.

Bakımı kolaylaştırmanın en basit kuralı: bayrak kontrollerini her yere yaymayın. Özellik başına bir karar noktası seçin (genellikle yönlendirme, bir servis sınırı veya tek bir UI girişi yakınında) ve geri kalan kodu temiz tutun. Aynı bayrak beş dosyada görünüyorsa, genellikle özellik sınırı net değildir.

Ayrıca ayırmak yardımcı olur:

• Etkinleştirilebilir (uygunluk): plan, bölge, cihaz türü, hesap yaşı, dahili test kullanıcıları.
• Etkinleştirilmeli mi (rampalar ve güvenlik): %0, %10, %50, %100, ayrıca duraklatma veya anında kapatma kontrolleri.

Bayrakları küçük ve odaklı tutun: her bayrak bir davranış içins olsun. Birden fazla değişiklik gerekiyorsa, ya net isimlendirilmiş birden çok bayrak kullanın ya da hepsini tek bir sürüm bayrağı (örneğin onboarding_v2) arkasında gruplayın ve tam yolu seçin.

Sahiplik çoğu ekipin beklediğinden daha önemlidir. Kim neyi, ne zaman çevirebilir önceden kararlaştırın. Ürün rollout hedefleri ve zamanlamadan sorumlu olmalı, mühendislik varsayılanlar ve güvenli geri dönüşlerden sorumlu olmalı, destek ise müşteri etkilenen sorunlar için gerçek bir acil kapatma düğmesine erişebilmelidir. Eski bayrakları temizlemekten bir kişiyi sorumlu atayın.

Bu yaklaşım Koder.ai ile hızlı inşa ederken iyi çalışır: değişiklikleri hazır olur olmaz gönderebilirsiniz, fakat yine de kimlerin göreceğini kontrol eder ve uygulamanın yarısını yeniden yazmadan hızlıca geri alabilirsiniz.

En sık kullanacağınız bayrak türleri

Çoğu ekip sadece birkaç desene ihtiyaç duyar.

Boolean (iki durumlu) bayraklar varsayılandır: açık veya kapalı. Yeni şeyi göstermek veya yeni endpoint’i kullanmak için idealdir. Gerçekten iki seçenekten fazla ihtiyacınız varsa, anlamlı değerler kullanarak bir çok varyantlı bayrak (A/B/C) kullanın (örneğin control, new_copy, short_form) ki loglar okunabilir kalsın.

Bazı bayraklar geçici rollout bayraklarıdır: riskli bir şeyi göndermek, doğrulamak ve sonra bayrağı kaldırmak için kullanılır. Diğerleri ise SSO etkinleştirmek veya depolama bölgesini seçmek gibi kalıcı yapılandırma bayraklarıdır. Kalıcı konfigürasyonu ürün ayarları gibi ele alın; net sahiplik ve dokümantasyon gerektirir.

Bayrağın nerede değerlendirildiği önemlidir:

• Sunucu tarafı bayraklar daha güvenlidir çünkü karar backend’de (örneğin Go API) verilir ve istemci sadece sonucu alır.
• İstemci tarafı bayraklar (React veya Flutter) düşük riskli UI değişiklikleri için uygundur, ama kullanıcıların istemciyi inceleyip değiştirebileceğini varsayın.

Hiçbir zaman gizli bilgileri, fiyatlandırma kurallarını veya izin kontrollerini sadece istemci tarafı bayrakların arkasına koymayın.

Bir acil kapatma (kill switch) hızlı geri alma için tasarlanmış özel bir boolean bayraktır. Riskli bir yolu yeniden dağıtım olmadan derhal devre dışı bırakmalıdır. Girişler, ödemeler veya veri yazımları gibi kırılma riski yüksek değişiklikler için acil kapatmalar ekleyin.

Koder.ai gibi bir platformda hızlı inşa ediyorsanız, sunucu tarafı bayraklar ve acil kapatmalar özellikle faydalıdır: hızlı hareket edebilirsiniz, ancak gerçek kullanıcılar uç durumlarla karşılaştığında temiz bir “kapat” düğmeniz olur.

Kohortları basit tutarak hedefleme nasıl yapılır

Kohort hedefleme riski sınırlar. Kod dağıtılmıştır, fakat sadece bazı kişiler değişikliği görür. Amaç kontrol, mükemmel segmentasyon sistemi değil.

Başlamak için bir değerlendirme birimi seçin ve ona bağlı kalın. Birçok ekip kullanıcı düzeyinde hedefleme (bir kişi değişikliği görür) veya workspace/hesap düzeyinde hedeflemeyi (bir ekipte herkes aynı şeyi görür) tercih eder. Workspace hedefleme, faturalama, izinler veya ortak çalışma gibi paylaşılan özellikler için genellikle daha güvenlidir çünkü aynı takım içinde karışık deneyimler oluşmasını önler.

Çoğu ihtiyacı kapsayan küçük bir kural seti yeterlidir: kullanıcı öznitelikleri (plan, bölge, cihaz, dil), workspace hedefleme (workspace ID, organizasyon seviyesi, dahili hesaplar), yüzde rolloutu ve QA/destek için basit izin listeleri veya engelleme listeleri.

Yüzde rampalarını deterministik tutun. Bir kullanıcı sayfayı yenilediğinde eski ve yeni UI arasında gidip gelmemelidir. Aynı ID’nin sabit bir hash’ini her yerde (web, mobil, backend) kullanın ki sonuçlar eşleşsin.

Pratik bir varsayılan “yüzde rollout + izin listesi + acil kapatma”dır. Örneğin Koder.ai’de yeni bir Planning Mode prompt akışını ücretsiz kullanıcıların %5’i için etkinleştirirken bazı Pro workspace’leri erken denemeler için izin listesine alabilirsiniz.

Yeni bir hedefleme kuralı eklemeden önce sorun: gerçekten bu ekstra dilime ihtiyacımız var mı, bu kullanıcı düzeyinde mi yoksa workspace düzeyinde mi olmalı, metrikler düşerse kapatmanın en hızlı yolu nedir ve hangi veriyi kullanıyoruz (ve bunu hedefleme için kullanmak uygun mu)?

Riskli değişiklikler için adım adım rollout planı

Riskli değişiklikler sadece büyük özellikler değildir. Küçük bir prompt ayarı, yeni bir API çağrısı veya doğrulama kurallarında bir değişiklik gerçek kullanıcı akışlarını bozabilir.

En güvenli alışkanlık basittir: kodu gönderin, ama kapalı tutun.

“Varsayılan olarak güvenli” demek yeni yolun devre dışı bir bayrağın arkasında olması demektir. Bayrak kapalıysa kullanıcılar eski davranışı alır. Bu, zorunlu bir değişikliği herkes için zorunlu kılmadan merge ve deploy yapmanızı sağlar.

Rampalamadan önce “iyi”nin ne olduğunu yazın. Hızla kontrol edebileceğiniz iki veya üç sinyal seçin: değişen akış için tamamlama oranı, hata oranı ve özellikle özelliğe etiketlenen destek talepleri gibi. Durdurma kuralını önceden belirleyin (örneğin “hatalar iki katına çıkarsa kapatın”).

Panik olmadan hızla ilerlemenizi sağlayacak rollout planı:

1. Bayrak kapalıyken gönderin, sonra üretimde eski yolun hâlâ çalıştığını doğrulayın.
2. Önce dahili ekip için açın, gerçek hesaplar ve gerçek veri desenleriyle.
3. Küçük bir beta kohortu açın (genellikle %1–5) ve başarı sinyallerinizi izleyin.
4. Kademeli olarak artırın (10%, 25%, 50%, 100%), her adımda trendleri görmek için yeterince bekleyin.
5. Bir acil kapatma hazır tutun ki bir şey ters görünürse özelliği derhal devre dışı bırakabilesiniz.

Geri almayı sıkıcı hale getirin. Bayrağı devre dışı bırakmak kullanıcıları bilinen iyi deneyime geri döndürmelidir, redeploy gerektirmemelidir. Platformunuz snapshot ve rollback destekliyorsa (Koder.ai destekler), ilk maruziyetten önce bir anlık görüntü alın ki gerekirse hızla kurtarın.

Enstrümantasyon: ne değiştiğini ve kimlerin gördüğünü bilin

Bayraklar yalnızca iki soruyu hızlıca cevaplayabiliyorsanız güvenlidir: bir kullanıcı hangi deneyimi aldı ve bu yardımcı oldu mu yoksa zarar mı verdi? Küçük prompt veya UI değişiklikleri büyük dalgalanmalara neden olabileceğinden bu daha da önemlidir.

Önce bayrak değerlendirmelerini tutarlı bir şekilde loglayın. İlk günde gösterişli bir sisteme ihtiyacınız yok ama filtreleyip karşılaştırabileceğiniz tutarlı alanlara ihtiyacınız var:

• Bayrak anahtarı ve bir bayrak sürümü (veya konfigürasyon hash’i)
• Varyant (açık/kapalı veya A/B değeri)
• Eşleşen kuralın kohort tanımlayıcısı
• Kullanıcı/workspace ID’si (pseudonimleştirilmiş olabilir), ayrıca ortam (prod, staging)
• Zaman damgası ve istek ID’si (hatalarla birleştirebilmek için)

Sonra bayrağı saatlik izleyebileceğiniz küçük bir başarı ve güvenlik metrik setine bağlayın. İyi varsayılanlar hata oranı, p95 gecikme süresi ve değişiklikle ilişkili bir ürün metriğidir (kaydolma tamamlama, ödeme dönüşümü, 1. gün tutma).

Panik değil, durdurma tetikleyen uyarılar kurun. Örneğin: hatalar işaretlenen kohort için %20 artarsa rollout’u durdurun ve acil kapatmayı çevirin. Gecikme sabit bir eşiği aşarsa mevcut yüzdeyi dondurun.

Son olarak basit bir rollout kaydı tutun. Yüzdeyi veya hedeflemeyi her değiştirdiğinizde kim, ne ve neden kaydedin. Hızla iterasyon yaparken ve güvenle geri dönerken bu alışkanlık önemlidir.

Gerçekçi örnek: yeni bir onboarding akışını güvenle göndermek

Chat odaklı bir builder olan Koder.ai ile oluşturulmuş bir uygulamada yeni bir onboarding akışı göndermek istiyorsunuz. Yeni akış ilk çalıştırma UI’sini değiştiriyor, “ilk projenizi oluşturun” sihirbazı ekliyor ve başlangıç kodunu üreten prompt’u güncelliyor. Aktivasyonu artırabilir ama riskli: bozulursa yeni kullanıcılar takılabilir.

Tüm yeni onboarding’i tek bir bayrağın arkasına koyun, örneğin onboarding_v2, ve eski akışı varsayılan olarak bırakın. Net bir kohortla başlayın: dahili ekip ve davetli beta kullanıcıları (örneğin beta=true olarak işaretlenmiş hesaplar).

Beta geri bildirimi iyi görünürse, yüzde rampasına geçin. Yeni kayıtların %5’ine, sonra %20’sine, sonra %50’sine açın ve adımlar arasında metrikleri izleyin.

20%’de bir şey ters giderse (örneğin destek ekibi adım 2 sonrası sonsuz yüklenme rapor ediyorsa), panik yapmak yerine panolarda hızlıca teyit edebilmelisiniz: işaretli kullanıcılar için daha yüksek terk oranları ve “proje oluştur” endpoint’inde yükselen hatalar. Hızlı bir düzeltme yerine onboarding_v2’yi küresel olarak devre dışı bırakın. Yeni kullanıcılar derhal eski akışa geri döner.

Hatanın yamalandığını ve stabiliteyi doğruladıktan sonra küçük adımlarla tekrar rampalayın: önce sadece beta’ya açın, sonra %5, sonra %25, en sonunda sürpriz olmadan bir tam gün sonra %100’e çıkarın. Stabil olduktan sonra bayrağı kaldırın ve bir tarih belirleyip ölü kodu silin.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Özellik bayrakları hızlı yayınlamayı daha güvenli kılar, ama onlara gerçek ürün kodu gibi davranırsanız işe yarar.

Yaygın bir başarısızlık bayrak patlamasıdır: belirsiz adlarla, sahibi olmayan ve kaldırma planı olmayan düzinelerce bayrak. Bu, belirli kohortlarda görülen kafa karıştırıcı davranışlara ve hatalara yol açar.

Bir diğer tuzak, hassas kararları istemciye bırakmaktır. Bir bayrak fiyatlandırmayı, izinleri, veri erişimini veya güvenliği etkileyebiliyorsa, bunu tarayıcıya veya mobil uygulamaya güvenerek uygulamayın. Uygulamayı sunucuda zorlayın ve UI’ya sadece sonucu gönderin.

Ölü bayraklar daha sessiz ama risklidir. Bir rollout %100’e ulaştıktan sonra eski yollar “olur ya” diye kalır. Aylar sonra kimse neden var olduklarını hatırlamaz ve bir refaktör onları kırar. Geri dönüş seçeneklerine ihtiyacınız varsa snapshot veya net bir rollback planı kullanın, ama değişik stabil olduktan sonra yine de kod temizliğini planlayın.

Son olarak, bayraklar testleri veya incelemeleri yerine geçmez. Bayrak etki alanını küçültür; kötü mantığı, migration problemlerini veya performans sorunlarını engellemez.

Basit korunma yöntemleri çoğunu önler: açık bir isimlendirme şeması kullanın (alan-amac), bir sahip ve son kullanma tarihi atayın, hafif bir bayrak kaydı tutun (deneysel, rollout altında, tamamen açık, kaldırıldı) ve bayrak değişikliklerini yayın gibi ele alın (log, inceleme, izleme). Güvenlikle ilgili kararları istemcide uygulamayın.

Bayrağı etkinleştirmeden önce hızlı kontrol listesi

Hız iyi ama küçük bir değişiklik herkes için temel bir yolu bozduğunda sorun yaşarsınız. İki dakikalık kontrol saatlerce temizlik ve destek işini kurtarabilir.

Gerçek kullanıcılara açmadan önce:

• Açıkça adlandırın ki sonradan okunması kolay olsun (örneğin onboarding_new_ui_web veya pricing_calc_v2_backend).
• Bir sahip ve son kullanma tarihi atayın ki geçici bayraklar sonsuza kadar yaşamasın.
• Varsayılan durumu ve güvenli geri dönüşü yazın ki “kapalı” hâlâ çalışsın ve test edilsin.
• Bir cümlede rollout kurallarını tanımlayın (dahili kullanıcılar, sonra yeni kayıtların %5’i, sonra %25, sonra herkes).
• Yüksek riskli yollar için bir acil kapatma hazırlayın ve kimlerin bunu çevirebileceğini doğrulayın.

Pratik bir alışkanlık olarak hızlı bir “panik testi” yapın: bu özelliği etkinleştirir etkinleştirmez hata oranları yükselirse, bunu hızlıca kapatabiliyor muyuz ve kullanıcılar güvenli bir yere düşecek mi? Cevap “belki” ise, maruziyeti açmadan önce geri dönüş yolunu düzeltin.

Koder.ai içinde inşa ediyorsanız, bayrakları yapının bir parçası gibi ele alın: geri dönüşü planlayın, sonra değişikliği geri almanın temiz bir yoluyla gönderin.

Kohort hedefleme için güvenlik, gizlilik ve uyumluluk temelleri

Kohort hedefleme güvenli test sağlar, ama dikkatsizce yapılırsa hassas bilgileri sızdırabilir. İyi bir kural: bayrakların çalışması için kişisel verilere ihtiyaç duymaması.

Hesap ID’si, plan seviyesi, dahili test hesabı, uygulama sürümü veya rollout kovası (0–99) gibi sıkıcı hedefleme girdilerini tercih edin. Ham e-posta, telefon numarası, tam adres veya düzenlemelere tabi verilerden kaçının.

Bir kullanıcıyla ilgili bir şeyi hedeflemeniz gerekiyorsa, bunu beta_tester veya employee gibi kaba bir etiket olarak saklayın. Hedefleme için hassas nedenleri etiket olarak saklamayın. Ayrıca kullanıcıların bir ayarın ani görünümüyle bir şeyi çıkarım yapabileceğini unutmayın: bir ayar tıpkı bir tıbbi özelliği veya farklı bir fiyatı ortaya çıkarıyorsa, kuralların varlığını tahmin edebilirler.

Bölgeye göre rampalar yaygındır, ama uyumluluk yükümlülükleri doğurabilir. Bir özelliği yalnızca bir ülkede etkinleştiriyorsanız ve backend orada barınıyorsa verinin gerçekten orada kaldığından emin olun. Platformunuz ülke bazında dağıtımı destekliyorsa (Koder.ai bunu AWS üzerinde destekler), bunu rollout planının bir parçası olarak ele alın.

Denetim izleri tutun. Kim bir bayrağı değiştirdi, neyi değiştirdi, ne zaman ve neden açıkça kaydedilmiş olmalı.

Sonraki adımlar: hafif bir bayrak iş akışı kurun ve hızla ilerlemeye devam edin

Hafif bir iş akışı sizi hızlandırır ama bayrakları ayrı bir ürün hâline getirmez.

Tekrar kullanılabilecek küçük bir çekirdek bayrak setiyle başlayın: yeni UI için bir, backend davranışı için bir, ve bir acil kapatma anahtarı. Aynı desenleri tekrar kullanmak neyin canlı olduğunu ve neyin devre dışı bırakılabileceğini anlamayı kolaylaştırır.

Riskli bir şey inşa etmeden önce nerede kırılabileceğini haritalayın. Koder.ai’da Planning Mode auth, faturalama, onboarding, veri yazımları gibi hassas noktaları işaretlemenize ve bayrağın neyi koruması gerektiğine karar vermenize yardımcı olabilir. Amaç basit: bir şey ters giderse bayrağı kapatırsınız ve uygulama dün olduğu gibi davranır.

Her işaretli değişiklik için küçük, tekrarlanabilir bir sürüm notu tutun: bayrak adı, kimlerin aldığı (kohort ve rollout %), bir başarı metriği, bir koruyucu metrik, nasıl devre dışı bırakılacağı (acil kapatma veya %0’a ayarlama) ve kimlerin izlediği.

Değişiklik stabil olduğunda temiz bir temel oluşturmak için kaynak kodunu dışa aktarın ve büyük rampalardan önce ekstra güvenlik için anlık görüntüler alın. Sonra temizlik planlayın: bir bayrak tamamen açık (veya tamamen kapalı) olduğunda onu kaldırmak için bir tarih belirleyin ki sisteminiz görünürde anlaşılır kalsın.