Claude Code ile Flutter UI yinelemesi: pratik bir iş akışı

Sorun: hızlı UI yinelemesi kaosa dönmemeli

Hızlı Flutter UI çalışmaları genelde iyi başlar. Bir düzeni ayarlarsınız, bir buton eklersiniz, bir alanı taşırsınız ve ekran hızla düzelir. Sorun birkaç tur sonra ortaya çıkar: hız, kimsenin gözden geçirmek istemediği bir değişiklik yığınına dönüşür.

Takımlar genellikle aynı başarısızlıklarla karşılaşır:

• Widget ağacı plansız büyür, bu yüzden "küçük" bir değişiklik birçok dosyada düzenleme gerektirir.
• Durum UI kodunun üzerine eklenir; yeniden oluşturulmalar öngörülemez olur ve hataları izlemek zorlaşır.
• Navigasyon mantığı dağıtılır (burada bir push, orada bir pop) ta ki akışlar kullanıcıların gerçekte uygulamada nasıl gezindiğiyle uyuşmaz hale gelene dek.
• İsimlendirme kayar, bileşenler çoğalır ve kim gerçek widget olduğundan emin olmaz.
• Diff’ler devasa hale gelir; inceleyenler aceleyle bakar, sorunlar gözden kaçar ve regresyonlar sonra ortaya çıkar.

Büyük bir sebep "tek büyük prompt" yaklaşımıdır: tüm özelliği tanımlayıp, tüm ekran setini isteyip büyük bir çıktı kabul edersiniz. Asistan yardım etmeye çalışır ama aynı anda çok fazla parçaya dokunur. Bu, değişiklikleri dağınık, gözden geçirilmesi zor ve birleştirmesi riskli yapar.

Tekrarlanabilir bir döngü netlik sağlar ve etki alanını sınırlar. "Özelliği inşa et" demek yerine şu adımları tekrarlayın: bir kullanıcı hikayesi seçin, bunu kanıtlayan en küçük UI dilimini üretin, o dilim için sadece gerekli durumu ekleyin, sonra tek bir yol için navigasyonu bağlayın. Her geçiş incelemeye yetecek kadar küçük kalır ve hatalar kolayca geri alınır.

Amaç, kullanıcı hikayelerini somut ekranlara, durum yönetimine ve navigasyon akışlarına dönüştüren pratik bir iş akışı sunmaktır. İyi yapıldığında modüler UI parçaları, küçük diff’ler ve gereksinimler değiştiğinde daha az sürpriz elde edersiniz.

Kullanıcı hikayelerini inşa edilebilir bir UI spesifikasyonuna dönüştürün

Kullanıcı hikayeleri insanlar için yazılır, widget ağaçları için değil. Bir şey üretmeden önce hikayeyi görünür davranışı tanımlayan küçük bir UI spesine çevirin. "Tamam" test edilebilir olmalı: kullanıcının ne görebileceği, dokunabileceği ve doğrulayabileceği; "tasarımın modern hissetmesi" değil.

Kapsamı somut tutmanın basit yolu hikayeyi dört kovaya bölmektir:

• Ekranlar: ne değişir, ne olduğu gibi kalır.
• Bileşenler: hangi yeni UI parçaları görünür ve nerede yer alır.
• Durumlar: loading, success, error, empty ve her birinin ne gösterdiği.
• Olaylar: tap’ler, swipe’lar, pull-to-refresh, geri navigasyon, retry.

Hikaye hâlâ belirsizse bu soruları düz bir dille cevaplayın:

• Hangi ekranlar değişiyor, hangileri aynı kalıyor?
• Hangi yeni bileşenler görünüyor ve nereye aitler?
• Hangi durumlar mevcut ve her biri ne gösteriyor?
• Hangi olaylar durumu değiştiriyor?
• Uygulamayı çalıştırdıktan sonra 30 saniyede yapabileceğiniz kabul kontrolü nedir?

Erken kısıtlamalar ekleyin çünkü bunlar her düzen seçimini yönlendirir: tema temelleri (renkler, boşluk, tipografi), cevap verebilirlik (önce telefon portresi, sonra tablet), ve erişilebilirlik asgari koşulları (dokunma hedefi boyutu, okunabilir metin ölçekleme, ikonlar için anlamlı etiketler).

Son olarak, neyin kararlı neyin esnek olduğunu belirleyin ki kod tabanında gereksiz tekrarlar oluşmasın. Kararlı öğeler diğer özelliklerin dayandığı şeylerdir: rota isimleri, veri modelleri ve mevcut API’ler. Esnek öğeler ise düzen yapısı, mikro metin ve kesin widget bileşimi gibi üzerinde daha rahat deneme yapabileceğiniz öğelerdir.

Örnek: "Kullanıcı olarak detay ekranından bir öğeyi Favorilere kaydedebilmeliyim." Yapılabilir bir UI spesifikasyonu şu olabilir:

• Detay ekranında bir yer imi (bookmark) ikonu gösterilir.
• Dokunmak kaydedilmiş durumunu değiştirir.
• Kaydederken küçük bir ilerleme göstergesi gösterilir.
• Başarısız olursa satır içi hata ve Tekrar (Retry) eylemi gösterilir.
• Navigasyon aynı kalır (yeni rota yok).

Bu, tahmin yapmadan inşa etmek, gözden geçirmek ve yinelemek için yeterlidir.

Diff’lerin küçük kalması için yineleme döngüsünü kurun

Küçük diff’ler daha yavaş çalışmakla ilgili değildir. Her UI değişikliğini incelemesi, geri alması ve bozmaması kolay hale getirir. En basit kural: yinelemede bir ekran ya da bir etkileşim olsun.

Başlamadan önce sıkı bir dilim seçin. "Orders ekranına boş durum ekle" iyi bir dilimdir. "Tüm Orders akışını yeniden düzenle" değil. Amaç, bir takım arkadaşının bir dakikada anlayabileceği bir diff elde etmektir.

Stabil bir klasör yapısı da değişikliklerin sınırda kalmasına yardımcı olur. Basit, özellik-öncelikli bir yapı widget’ları ve rotaları uygulama genelinde dağıtmaktan alıkoyar:

lib/
  features/
    orders/
      screens/
      widgets/
      state/
      routes.dart

Widget’ları küçük ve bileşik tutun. Bir widget net girişler ve çıkışlar aldığında, durumu etkilemeden düzeni değiştirebilir veya düzeni değiştirmeden durumu. Düz değerler ve callback’ler alan widget’ları tercih edin; global state okumayan.

İncelemesi kolay bir döngü:

• Dilim için 3–6 satırlık bir UI spes yazın (ne görünür, tap ne yapar, loading/error nasıl görünür).
• Sadece gerekli minimum dosyaları oluşturun veya düzenleyin (çoğunlukla bir ekran ve bir ya da iki widget).
• Ekranı çalıştırın, sonra bir temizlik geçişi yapın (isimlendirme, boşluk, kullanılmayan prop’ları kaldırma).
• Dilime uygun bir commit mesajı ile commit atın.

Sert bir kural koyun: her değişiklik kolayca geri alınabilir veya izole edilebilir olmalı. Yineleme yaparken rastgele refaktörlerden kaçının. İlgisiz problemler görürseniz not alın ve ayrı bir commit’te düzeltin.

Araçlarınız snapshot ve rollback destekliyorsa, her dilimi bir snapshot noktası olarak kullanın. Koder.ai gibi bazı vibe-coding platformları snapshot ve rollback içerir; cesur UI denemelerini güvenli hale getirebilir.

Erken yinelemeleri sakin tutan bir başka alışkanlık: paylaşılan bileşenleri düzenlemek yerine yeni widget eklemeyi tercih edin. Paylaşılan bileşenler küçük değişikliklerin büyük diff’lere dönüşmesine neden olur.

Kullanıcı hikayesinden widget ağacı üretme adım adım

Hızlı UI çalışması, düşünmeyi yazmaktan ayırdığında güvenli kalır. Kod üretmeden önce net bir widget ağacı planı çıkarın.

1. Sadece bir widget ağacı taslağı isteyin. Widget adları, hiyerarşi ve her parçanın ne gösterdiğini isteyin. Henüz kod yok. Bu aşamada eksik durumlar, boş ekranlar ve tuhaf düzen seçimleri ucuza yakalanır.

2. Sorumlulukları belirten bir bileşen dökümü isteyin. Her widget odaklı olsun: biri header render etsin, biri listeyi, diğeri boş/hata UI’sını. Bir şeyin daha sonra duruma ihtiyacı varsa şimdi not edin ama uygulamayın.

3. Ekran iskeleti ve stateless widget’lar oluşturun. Başlangıç için tek bir ekran dosyası, yer tutucu içerik ve net TODO’larla başlayın. Girişleri (constructor parametreleri) açık tutun ki gerçek durumu daha sonra plugin etmeden ağaç yeniden yazılmasın.

4. Stil ve düzen ayrık bir geçişte ekleyin: boşluk, tipografi, tema davranışı ve duyarlı davranış. Stil değişikliğini ayrı bir diff olarak ele alın ki incelemeler basit kalsın.

İşe yarayan bir prompt deseni

Asistanın uygulanamaz UI icat etmemesi için kısıtları başta koyun:

• Hedef cihazlar (sadece telefon, tablet de, yönlendirme)
• Tasarım kısıtları (Material 3, mevcut tema renkleri, boşluk kuralları)
• Navigasyon beklentileri (geri davranışı, varsa deep linkler)
• Kabul kriterleri (ne görünmeli ve dokunulabilir olmalı)
• Mevcut kod sınırları (hangi dosyalar/widget’lar kalmalı, isimlendirme konvansiyonları)

Somut örnek: kullanıcı hikayesi "Kullanıcı kaydedilmiş öğelerimi gözden geçirebilsin ve bir öğeyi kaldırabilsin." Bir app bar, öğe satırları olan bir liste ve boş durum içeren bir widget ağacı isteyin. Sonra SavedItemsScreen, SavedItemTile, EmptySavedItems gibi bir dağılım talep edin. Sadece ondan sonra stateless iskeleti sahte verilerle oluşturun ve son olarak stil (divider, padding, net kaldır butonu) için ayrı bir geçiş yapın.

UI kodunu şişirmeden durum yönetimi ekleyin

Her widget karar vermeye başladığında UI yinelemesi bozulur. Widget ağacını aptal tutun: durumu okuyup render etsin, iş kurallarını barındırmasın.

Önce durumları düz bir dille adlandırın. Birçok özellik yalnızca "loading" ve "done" den daha fazlasına ihtiyaç duyar:

• Loading (ilk yükleme veya yenileme)
• Empty (henüz veri yok)
• Error (istek başarısız, izin yok)
• Success (veri hazır)
• Partial input (form başlandı ama geçerli değil)

Sonra durumu değiştirebilecek olayları listeleyin: tap’ler, form gönderimi, pull-to-refresh, geri navigasyon, retry ve "kullanıcı bir alanı düzenledi". Bunu önceden yapmak tahminleri engeller.

Widget’lardan durumu ayrı tutun

Özellik için tek bir durum yaklaşımı seçin ve ona sadık kalın. Amaç "en iyi pattern" değil; tutarlı diff’lerdir.

Küçük bir ekran için basit bir controller (ChangeNotifier veya ValueNotifier gibi) sıklıkla yeterlidir. Mantığı tek bir yerde tutun:

• Girdiler: UI’den gelen olaylar (submit, refresh, edit)
• Çıktı: UI’nın render edeceği tek bir durum objesi
• Yan etkiler: API çağrıları ve navigasyon istekleri

Kodu eklemeden önce durum geçişlerini düz cümlelerle yazın. Örnek bir login ekranı için:

"Kullanıcı Sign in'e dokunduğunda: Loading olarak ayarla. E-posta geçersizse: Partial input’ta kal ve satır içi mesaj göster. Parola hatalıysa: Error ile mesaj göster ve Retry etkinleştir. Başarılıysa: Success olarak ayarla ve Home’a navigasyon yap."

Ardından bu cümlelere uyan minimal Dart kodunu üretin. İncelemeler basit kalır çünkü diff’i yazılı kurallarla karşılaştırabilirsiniz.

Geçersiz girişler için test edilebilir kurallar ekleyin

Doğrulamayı açık yapın. Girdiler geçersiz olduğunda ne olacağını karar verin:

• Göndermeyi engelliyor musunuz yoksa izin verip hata mı gösteriyorsunuz?
• Hangi alanlar ne zaman hata gösterir?
• Geri navigasyon kısmi girişi siler mi yoksa saklar mı?

Bu cevaplar yazıldığında UI temiz kalır ve durum kodu küçük kalır.

Gerçek kullanıcı davranışına uyan navigasyon akışları tasarlayın

İyi navigasyon küçük bir harita olarak başlar, rotalar yığını olarak değil. Her kullanıcı hikayesi için dört anı yazın: kullanıcı nereden girer, en olası sonraki adım nedir, nasıl iptal eder ve "geri" ne anlama gelir (önceki ekrana mı dönülür yoksa güvenli ana duruma mı?).

Önce bir rota haritası oluşturun, sonra ekranlar arası veri taşımayı kilitleyin

Basit bir rota haritası genelde yeniden çalışmaya neden olan soruları yanıtlamalıdır:

• Giriş: hangi ekran ilk açılır ve nereden (sekme, bildirim, deep link)
• Sonraki: birincil ileri yol nedir
• İptal: kullanıcı akışı terk ederse nereye gider
• Geri: geri izinli mi ve neyi korumalı
• Fallback: gerekli veri yoksa nereye gidilir

Sonra ekranlar arasında hangi parametrelerin geçeceğini tanımlayın. Açık olun: ID’ler (productId, orderId), filtreler (tarih aralığı, durum), ve taslak veri (kısmi doldurulmuş form). Bunu atlarsanız bağlamı global singleton’lara tıkarsınız veya ekranları bağlam "bulmak" için yeniden inşa edersiniz.

Deep linkler ve "sonuç döndürme" pattern’leri için plan yapın

Deep linkler bugün dağıtıma hazır olmasa bile önemlidir. Kullanıcı akışının ortasına inen bir kullanıcı geldiğinde ne olacağına karar verin: eksik veriyi yükleyebiliyor musunuz yoksa güvenli bir giriş ekranına mı yönlendiriyorsunuz?

Ayrıca hangi ekranların sonuç döndürmesi gerektiğini belirleyin. Örnek: "Adres Seç" ekranı bir addressId döndürür ve checkout ekranı tam yenileme yapmadan güncellenir. Döndürülen şekli küçük ve tipli tutun ki değişiklikler kolayca gözden geçirilebilsin.

Kodlamadan önce uç vakaları çağırın: kaydedilmemiş değişiklikler (onay diyaloğu göster), kimlik gerekli (login sonrası durumu devam ettir), eksik veya silinmiş veri (hata göster ve çıkış yolu sun).

UI değişikliklerini gözden geçirilebilir ve modüler yapın

Hızlı yineleme yaparken gerçek risk "yanlış UI" değil, "gözden geçirilmesi imkansız UI"dır. Bir ekip arkadaşı neyin değiştiğini, neden değiştiğini ve neyin sabit kaldığını söyleyemiyorsa, her sonraki yineleme yavaşlar.

Yardımcı bir kural: önce arayüzleri kilitleyin, sonra iç detayların hareket etmesine izin verin. Public widget prop’larını (girdi) sabitleyin, küçük UI modelleri ve rota argümanlarını sabitleyin. Bunlar adlandırılıp tiplenince widget ağacını şekillendirirken uygulamanın geri kalanını kırmadan yeniden düzenleyebilirsiniz.

Küçük, stabil dikişleri tercih edin

Kod üretmeden önce diff-dostu bir plan isteyin. Hangi dosyaların değişeceğini ve hangilerinin dokunulmaması gerektiğini söyleyen bir plan, incelemeleri odaklı tutar ve istem dışı refaktörleri engeller.

Diff’leri küçük tutan desenler:

• Public widget’ları ince tutun: sadece ihtiyaç duydukları veri ve callback’leri kabul etsinler, singleton’lara erişimden kaçının.
• İş kurallarını widget’ların dışına taşıyın: kararları bir controller veya view model’e koyun, UI durumu render etsin.
• Bir UI parçası sürekli değişmeyi bıraktığında onu tipli, net bir API ile yeniden kullanıma çıkarın.
• Rota argümanlarını açık tutun (çok sayıda opsiyonel alandan ziyade tek bir argüman objesi temizdir).
• PR açıklamasına kısa bir değişiklik günlüğü ekleyin: ne değişti, neden ve ne test edilmeli.

İnceleyenlerin sevdiği somut bir örnek

Hikaye: "Alışveriş yapan kullanıcı, checkout’tan gönderim adresini düzenleyebilsin." Önce rota argümanlarını kilitleyin: CheckoutArgs(cartId, shippingAddressId) sabit kalır. Sonra ekran içinde yineleme yapın. Düzen oturduktan sonra AddressForm, AddressSummary ve SaveBar olarak ayırın.

Durum yönetimi değişirse (ör. doğrulama widget’tan CheckoutController'a taşınırsa), inceleme okunaklı kalır: UI dosyaları çoğunlukla render değişikliğini gösterirken controller mantık değişikliğini tek bir yerde gösterir.

AI asistanla yineleme yaparken yapılan yaygın hatalar ve tuzaklar

Hızlanmanın en hızlı yolunu yavaşlatan şey asistanın her şeyi birden değiştirmesini istemektir. Eğer bir commit düzeni, durumu ve navigasyonu birden değiştiriyorsa, inceleyenler neyin hataya neden olduğunu anlayamaz ve geri alma zorlaşır.

Daha güvenli bir alışkanlık: yinelemede bir amaç olsun: önce widget ağacını şekillendir, sonra durumu bağla, sonra navigasyonu bağla.

Dağınık kod yaratan hatalar

Oluşan hızlı sorunlardan biri üretilen kodun her sayfada yeni bir desen icat etmesidir. Biri Provider kullanırken, diğeri setState, üçüncü bir sayfa özel bir controller sınıfı tanıtıyorsa uygulama hızla tutarsızlaşır. Küçük bir pattern seti seçin ve ona sadık kalın.

Başka bir hata async işleri doğrudan build() içinde çalıştırmaktır. Hızlı demo için görünüşte iyi olabilir ama rebuild’lerde tekrarlanan çağrılara, flicker’a ve izlenmesi zor hatalara neden olur. Çağrıyı initState(), bir view model veya özel bir controller’a taşıyın; build() yalnızca render etsin.

İsimlendirme sessiz bir tuzaktır. Derlenen ama Widget1, data2 veya temp gibi adlar okuyanı zorlayan kod gelecekteki refaktörleri ağrılı kılar. Net isimler asistanın sonraki değişiklikleri daha iyi üretmesine de yardımcı olur çünkü niyet belli olur.

Kötü sonuçları önleyen gardrail’lar:

• Iterasyonda sadece birini değiştir: düzen, durum veya navigasyon
• Özellik boyunca aynı durum desenini tekrar kullan
• build() içinde ağ veya DB çağrısı yok
• Yer tutucu isimleri gerçek fonksiyonel isimlerle değiştirin
• Daha fazla iç içe yapı eklemek yerine widget çıkarın

İç içe geçme tuzağı

Görsel bir hata düzeltmek için bir buton hizasını düzeltirken başka Container, Padding, Align, SizedBox ekleyerek ağacı okunamaz hale getirmek klasik bir hatadır.

Bir buton yanlış hizalanmışsa önce sarıcıları kaldırmayı, tek bir üst düzen widget’ı kullanmayı veya kendi kısıtlamalarıyla küçük bir widget çıkarmayı deneyin.

Örnek: toplam fiyatın yüklenirken zıpladığı bir checkout ekranı. Asistan fiyat satırını "stabilize etmek" için daha fazla sarıcı ekleyebilir. Daha temiz çözüm, satır yapısını değiştirmeden basit bir yükleme yer tutucusu ile alan ayırmaktır.

Sonraki commit’ten önce hızlı kontrol listesi

Commit etmeden önce iki dakikalık bir geçiş yapın: kullanıcı değerini kontrol edin ve sürpriz regresyonlardan korunun. Amaç mükemmellik değil; bu iterasyonun gözden geçirilmesi, test edilmesi ve geri alınmasının kolay olduğunu doğrulamaktır.

Commit-ready kontrol listesi

Kullanıcı hikayesini bir kez okuyun, sonra çalışan uygulama (veya basit bir widget testi) üzerinde aşağıyı doğrulayın:

• Widget ağacı hikayeyle eşleşiyor: Kabul kriterlerindeki kilit öğeler görünür. Metin, butonlar ve boşluk kasıtlı hissettiriyor.
• Tüm durumlar ulaşılabilir: Loading, error ve empty durumu sadece koda çizilmemiş; tetiklenebiliyor ve kabul edilebilir görünüyor.
• Navigasyon ve geri davranışı mantıklı: Geri beklenen ekrana dönüyor, diyaloglar düzgün kapanıyor ve deep link (kullanılıyorsa) mantıklı bir yere iniyor.
• Diff’ler küçük ve sahipliği belli: Değişiklikler az sayıda dosoyla sınırlı ve net sorumluluk var. Rastgele refaktör yok.
• Geri alma temiz: Bu commit geri alınırsa diğer ekranlar hâlâ derlenip çalışıyor. Geçici bayraklar veya placeholder asset’leri kaldırın.

Kısa bir gerçeklik kontrolü: yeni bir Order detay ekranı eklediyseniz, (1) listeden açılabildiğini, (2) loading spinner gösterdiğini, (3) hatayı simüle edip görebildiğinizi, (4) boş siparişi görebildiğinizi ve (5) geri bastığınızda listeye garip sıçramalar olmadan döndüğünüzü doğrulayabilmelisiniz.

Workflow’unuz snapshot/rollback destekliyorsa, daha büyük UI değişiklikleri öncesi snapshot alın. Koder.ai gibi bazı platformlar bunu destekler ve ana dalı riske atmadan daha hızlı yinelemenize yardımcı olabilir.

Gerçekçi bir örnek: kullanıcı hikayesinden ekranlara üç iterasyonda geçiş

Kullanıcı hikayesi: "Alışveriş yapan kullanıcı öğeleri göz atabilsin, detay sayfasını açabilsin, öğeyi favorilere kaydedebilsin ve sonra favorilerimi görüntüleyebilsin." Amaç kelimelerden ekranlara üç küçük, gözden geçirilebilir adımda ilerlemek.

İterasyon 1: sadece tarama (browse) listesine odaklanın. Gerçek veriye bağlı olmayan ama render edebilen bir widget ağacı oluşturun: Scaffold ile AppBar, yer tutucu satırlardan oluşan ListView, loading ve empty durumları için net UI. Durumu basit tutun: loading (CircularProgressIndicator), empty (kısa mesaj + belki Try again butonu), ready (liste gösterilir).

İterasyon 2: detay ekranı ve navigasyonu ekleyin. Açıkça belirtin: onTap bir rota push eder ve küçük bir parametre objesi geçirir (ör. item id, title). Detay sayfasını başta salt okunur olarak bırakın: başlık, açıklama yer tutucusu ve Favorite aksiyon butonu. Amaç hikayeyle eşleşmek: liste -> detay -> geri, ekstra akış yok.

İterasyon 3: favorilere kaydetme durum güncellemelerini ve UI geri bildirimlerini ekleyin. Favoriler için tek bir doğruluk kaynağı (memory içinde bile olsa) ekleyin ve bunu her iki ekrana bağlayın. Favorite’a dokununca ikon hemen güncellensin ve küçük bir onay (SnackBar gibi) gösterilsin. Sonra aynı state’i okuyan bir Favorites ekranı ekleyin ve boş durumu yönetin.

Gözden geçirilebilir bir diff tipik olarak şöyle görünür:

• browse_list_screen.dart: widget ağacı + loading/empty/ready UI
• item_details_screen.dart: UI düzeni ve navigation param kabulü
• favorites_store.dart: minimal state tutucu ve güncelleme metotları
• app_routes.dart: rotalar ve tipli navigasyon yardımcıları
• favorites_screen.dart: durumu okur ve empty/list UI gösterir

Eğer herhangi bir dosya "her şeyin olduğu yer" haline gelirse, bir sonraki adıma geçmeden önce onu bölün. Küçük, net isimli dosyalar sonraki yinelemeyi hızlı ve güvenli kılar.

Sonraki adımlar: döngüyü özellikler boyunca tekrarlanabilir hale getirin

Eğer iş akışı yalnızca siz "odakta"yken çalışıyorsa, ekran değiştirince veya bir ekip arkadaşı özniteliklerine dokunduğunda bozulur. Döngüyü bir alışkanlık haline getirin: yazın ve değişiklik boyutu etrafında gardrail’lar koyun.

Yeniden kullanılabilir bir prompt şablonu oluşturun

Her yineleme aynı girdilerle başlaması ve aynı tür çıktı üretmesi için takımca tek bir şablon kullanın. Kısa ama spesifik tutun:

• Kullanıcı hikayesi + kabul kriterleri ("tamam" ne demek)
• UI kısıtları (tasarım sistemi, boşluk, tekrar kullanılacak bileşenler)
• Durum kuralları (durum nerede tutulur, yerel vs paylaşılan)
• Navigasyon kuralları (rotalar, deep linkler, geri davranışı)
• Çıktı kuralları (dokunulacak dosyalar, güncellenecek testler, diff’te ne açıklanacak)

Bu, asistanın özellik ortasında yeni pattern’ler icat etme şansını azaltır.

"Küçük"ü tanımlayın ki diff’ler öngörülebilir kalsın

Her iterasyonu sınırlandırmak için inceleme sırasında uygulanabilir bir tanım seçin. Örnek kurallar:

• Her iterasyonda en fazla 3–5 dosya değişikliği
• Bir iterasyonda bir yeni widget veya bir yeni navigasyon adımı
• Döngü ortasında yeni bir durum yönetimi yaklaşımı getirme
• Bir sonraki iterasyona geçmeden önce her değişiklik derlenip çalışmalı

Kötü bir adımı hızlı geri alabilmeniz için kontrol noktaları ekleyin. En azından commit’leri etiketleyin veya büyük refaktörlerden önce lokal checkpoint’ler saklayın. Workflow’unuz snapshot/rollback destekliyorsa bunları agresif kullanın.

Eğer sohbet tabanlı bir iş akışıyla uçtan uca Flutter uygulamaları üretebilen bir sistem istiyorsanız, Koder.ai planning mode’u planı ve beklenen dosya değişikliklerini gözden geçirmenize yardımcı olur.