Sledgehammers and nuts
Spec-driven development won. Kiro, GitHub's Spec Kit, Tessl — in one year, every serious dev tool learned to say "spec first." That's genuine progress: the industry finally admitted that vibes don't scale. And then it immediately built the opposite failure mode.
A reviewer testing Kiro filed a small bug and watched the tool inflate it into four user stories and sixteen acceptance criteria — in their words, "a sledgehammer to crack a nut." Anyone who has run these tools recognizes the moment. You wanted a typo fixed; you received a requirements document. The tools learned ceremony. They didn't learn when.
Triage is the unsolved problem
Here's the thing the category hasn't cracked: knowing whether a change is trivial or whether it needs grounding. Full ceremony on everything is bureaucracy — the user drowns in generated paperwork and turns the rigor off, which is worse than never having it. No ceremony on anything is the vibe-coding cliff everyone just climbed out of. Both failure modes lose the same user, from opposite directions.
And it isn't a detail you can bolt on later. Proportionality is the difference between discipline that compounds and discipline that gets disabled in week two. A methodology only survives contact with a real person if its cost tracks the size of the decision.
Rigor that can't tell a typo from an architecture change isn't rigor. It's a tax with good intentions.
Decide the move before the machinery
Doric's answer is a law we enforce at the front of every single turn: decide the move before the model plans. Before any machinery spins up, the turn is classified — is this a small, clear fix? Act on it; touch the thing, verify, done, no ceremony. Is it a new idea? Think first; no paperwork generated for a thought that's still forming. Is it big, or forky, or does it contradict something we decided? Now the full apparatus earns its keep: grounding, spec, Theo's review, the works.
Theo's assessment — trivial versus requires-grounding — is the hinge. It reads the change against the living map and the decision log, so "small" isn't judged by how short the request is, but by how far its consequences reach. A one-line request that touches the auth flow is not small. A paragraph-long request to reword the empty state is. Size of blast radius, not size of prompt.
The dial, not the switch: discipline in Doric turns loose → strict with the stakes. The typo gets a verified edit and nothing else. The schema change gets a spec, a review, and a veto-holding validator. Both get exactly the ceremony they deserve — and neither gets the other's.
Why this is the lane, not the feature
Every spec-driven tool can generate more process; that's what language models are best at. The scarce ability is withholding process — an engine confident enough in its map of your product to say "this one's trivial, I'll just do it" and be right. That takes the things the paperwork tools don't have: a living architecture map to measure blast radius against, a decision log to check contradictions against, and a validator whose job is judgment, not generation.
Spec-driven development taught the industry to write things down. The next lesson is older and harder: proportion. That's a place this category can be better, not just match — and it's where we've aimed Doric.
Related: Expansive in the thinking lane, disciplined in the commit lane →