# Designers propose, engineers review ## Short narrative Mode should increase designer leverage without pretending engineering review disappears. Designers propose production-aware UI changes; engineers stay in the path. ## Why this wedge matters Question it answers: > Why won't this scare serious teams? Narrative: > Designers can move work closer to implementation without removing engineering review. This protects us from the bad interpretation: > "Oh, so designers are bypassing engineering with AI?" The stronger story is: > Designers propose production-aware UI changes. Engineers stay in the review path. ## How it supports the launch spine This is the adoption-safety wedge inside the launch spine. It makes the promise credible because Mode does not ask teams to trust unreviewed AI changes; it moves work toward a PR, diff, branch, or other engineering-reviewable output when the proof supports it. ## Strategic bet This framing lowers adoption resistance. Designers get more autonomy, but engineering stakeholders still see a reviewable artifact and clear boundary. ## Why Mode is suited Mode can frame outputs as scoped proposals or reviewable changes. This is safer than claiming designers bypass engineering or ship production changes by default. ## Product entry / CTA path Ask users to create a scoped UI proposal that engineering can inspect. ## Proof needed Show the inspectable review path. A real PR is ideal only if true. Otherwise show reviewable output, changed files, notes, branch/diff/export, or whatever the product honestly supports. ## Launch-spine relevance This wedge is essential to the current favored launch narrative: > Mode lets Design Engineers change the actual product — using its real code, components, and design system — then move the work toward a PR or engineering review. ## Risks / confusions - Too operational to be the only category hook. - Must not imply no engineers are needed. - If proof lacks a real review artifact, keep language at `reviewable output`.