The thing you ship is not the thing you scoped, and you cannot point at where it changed.
You wrote a one-page spec. Three features, one shipping path, two weeks to ship. Three weeks later you have eleven features, half from "while we're here" conversations and half from AI suggestions that sounded reasonable in the moment.
Your week became review work.
Where the work moves
Software discipline used to be a downstream activity. You wrote requirements, you built, you reviewed what got built against the requirements. The bottleneck was building, so the cheap thing was talking about what to build, and the expensive thing was changing it after.
AI inverted this. Building is cheap now, so the cheap thing is letting the AI build whatever it wants. The expensive thing is unwinding what got built. Most of the discipline-work I do these days is downstream: review cycles, critique passes, scope audits, infrastructure I had to build just to claw back what the AI did when I was not looking.
The work happens either way. The question is whether you do it before the AI starts, or after.
The complacent AI
The AI treats suggestions as legitimate by default. It does not know your customers, your stage, your runway, or what it actually costs your team to support one more thing in production. When you ask "what else should we build," it has answers. When you ask "should we build this," it will build it. What it cannot say is "that is not your MVP."
Product judgment lives outside the AI. The AI generates options well, but refusing them is your job.
When you don't refuse, features stack, and stacking dilutes. The first few features in your MVP each carry real weight, because each one is doing visible work for a specific user. The more you add, the less any single one matters, until the product becomes a generic surface where nothing stands out.
Three laws
Telling the AI to "be minimal" or "keep it focused" does not actually constrain it. The AI has seen those words attached to plenty of outputs that still added things, so it treats them as a flavor preference rather than a real rule. What does constrain the AI is laws specific enough that you can tell when one has been broken.
Here are three.
Write these into the AI's instructions before the conversation starts. The AI can fail "ship a focused MVP" without anyone noticing for weeks; it cannot fail "no more than three features in v1" without you noticing immediately.
Restraint
The concept behind these laws comes from three people who have spent careers practicing what Zen calls Kanso, the discipline of simplicity through deliberate omission:
- The absence is the design (inspired by Rick Rubin). He strips songs to their essentials, removing tracks one at a time and listening for what changes, until what remains has nowhere to hide.
- Less, but better (inspired by Dieter Rams). His ten principles of good design all point to letting the product step out of the way of the person using it.
- The best product dissolves into use (inspired by Naoto Fukasawa). His "Without Thought" workshops train designers to make products that get out of the way so the user notices the problem getting solved instead.
Every feature you add competes with every other feature for the user's attention, your support capacity, and the integrity of the original idea. The unbuilt features are the design.
Upstream
When the laws live in the prompt, the work downstream shrinks. The reviews get shorter because there is less drift to catch. The critiques find smaller issues because the big ones got prevented. The audits become spot checks rather than archaeology.
The AI holds whatever line you draw. Figuring out where to draw it is your next challenge.