Bir Kararı Koda Dönüşmeden Önce Nasıl Kilitlerim?

Kod yazmaya başlamak ilerleme hissi verir.

Özellikle AI coding ile birkaç dakika içinde çalışan yüzey görmek mümkün.

Bu hız faydalı.

Fakat açık ürün kararları varsa hız, belirsizliği de hızla çoğaltır.

Ben bu yüzden bazı kararların koddan önce kilitlenmesini istiyorum.

Kilitlemek “her şeyi önceden bilmek” değildir

Waterfall plan yazmıyorum.

Gelecek altı ayı tahmin etmeye çalışmıyorum.

Kilitlemekten kastım, mevcut increment’in temel sorularını açık bırakmamak.

Örneğin:

Problem ne? Bu iteration hangi kullanıcı işini çözüyor? Scope dışında ne var? Canonical state nerede? Hangi domain değişiyor? Hangi state’ler destekleniyor? Başarı neyle kabul edilecek?

Bunlar açık değilse implementasyon sırasında developer veya agent cevap üretir.

O cevaplar zamanla ürün mimarisine dönüşür.

Build contract’ın çekirdeği

Ben build öncesi şu yapıyı kullanıyorum.

Problem Kullanıcının veya sistemin gerçek darboğazı.

Evidence Bunu nereden biliyoruz?

Decision Hangi davranışı seçiyoruz?

Scope Bu iterasyonda ne var?

Non-goals Özellikle ne yok?

Architecture impact Hangi domain, state, data ve platform etkileniyor?

Acceptance Çalıştığını hangi somut davranış gösterir?

Bu belge yüz sayfa olmak zorunda değil.

Net bir feature için bir ekran bile yeterli olabilir.

Ama kararların sahibi belli olur.

AI agent için neden daha önemli?

AI agent belirsizlikten korkmaz.

Boşluğu doldurur.

Bu aynı anda hem gücü hem riski.

“Settings’i geliştir” dediğinizde agent yeni tab, yeni state, yeni dependency veya yeni storage pattern oluşturabilir.

Tek tek kararlar mantıklı görünebilir.

Fakat ürünün mevcut sistemiyle çakışabilir.

Agent’a iyi prompt vermek sadece daha ayrıntılı görev yazmak değildir.

Doğru authority context’i vermektir.

• hangi dosya canonical,
• hangi karar reopen edilmeyecek,
• hangi dependency yasak,
• hangi acceptance gate zorunlu,
• production yolu ne.

Bu nedenle context architecture ve product architecture birbirine yaklaşır.

Scope’u non-goal ile korumak

“Mobil not UX’ini düzelt.”

Bu scope değil.

Daha iyi:

Problem: note selection mobilde destructive actions ile çakışıyor. Scope: row interaction, selected state, back behavior. Non-goal: notes data modelini, editor’ü ve folder architecture’ı değiştirme. Acceptance: 390px’de tap note’u açar; archive/delete explicit action olarak kalır; Android back bir üst hierarchy’ye döner.

Non-goal özellikle önemlidir.

Çünkü agent veya ekip iyi niyetle komşu alanları da “iyileştirebilir”.

Minimum correct change böyle korunur.

Architecture impact yazmadan kod açmıyorum

Bir değişiklik şu sorulara dokunuyorsa architecture impact var:

• source-of-truth,
• mutation,
• cache,
• route,
• platform,
• permission,
• billing,
• release,
• shared component.

Bu durumda “küçük feature” etiketi yanıltıcı olabilir.

Kod satırı az olabilir.

Risk alanı geniş olabilir.

Acceptance ekran görüntüsü değildir

“Güzel görünüyor” acceptance değildir.

Davranış yazılmalı.

Örneğin:

• keyboard ile ulaşılabilir,
• focus görünür,
• 390 / 768 / 1440’da overflow yok,
• error state doğru,
• live URL beklenen commit’i taşıyor,
• mobile back beklenen hierarchy’ye dönüyor.

Bu noktada QA sonradan gelen iş değil, kararın parçası olur.

Sonuç

Kod, ürün kararlarını vermek için pahalı bir yer olabilir.

AI ile kod ucuzlamış olsa bile yanlış kararın production maliyeti ucuzlamadı.

Ben bu yüzden önce kararın sınırlarını kilitliyorum.

Sonra kodu o kontratı gerçekleştirmek için kullanıyorum.