Short Corrections, Long Leverage
I spent a full session designing a geo-restriction system with Claude. Not coding — designing. The kind of work where you are drawing boundaries around entities, deciding what belongs where, and trying not to over-build.
The session ran long. Sixteen turns. Multiple course corrections. A design doc came out the other end. But the thing that made it work was not the length of the conversation. It was the short interruptions.
The setup
The system had existing infrastructure — a geo-IP library already wired in, a playback gate that checked viewer location, some partial patterns in the codebase. The question was how to extend that into full regional catalog control, pricing per region, and enforcement at multiple layers.
Before proposing anything, I asked Claude to investigate what already existed. That investigation became the anchor for every recommendation that followed. Nothing was invented from scratch. Everything extended something real.
This is the first pattern worth naming: investigate before you opine. If the AI does not know what is already in the codebase, its recommendations will be generic. If it does, they will be specific — file names, existing patterns, real constraints.
The two-word fix
Midway through, the design had regional pricing attached to the wrong entity. It was on the product template — the thing that defines what a subscription includes. It should have been on the offer — the thing that defines what a customer actually buys.
I said five words: "The ultimate entity is offer."
The entire pricing model restructured in the next response. The schema changed. The enforcement logic changed. The migration plan changed. Five words.
Later, a similar thing happened with pricing complexity. The design was accumulating effective-dating logic — start dates, end dates, overlapping validity windows. I said two words: "Flat price." The schema collapsed to four columns.
Short corrections were disproportionately high-signal. Every time I replied with fewer than ten words, a real structural edit happened. The long messages — the ones where I explained context or gave background — were important for setting direction. But the short ones moved the design.
Let the AI be wrong
At one point the design needed to handle filtered pagination. Claude proposed caching full lists in memory and filtering per request. I asked one question: "If we filter in memory, how do we deal with paging?"
That single question exposed two problems simultaneously — a correctness bug in the pagination logic and a modeling error in how customers were linked to regions. Claude proposed a fix: materialize the filtered data into denormalized tables, refresh nightly.
I pushed back. "How about at each request we resolve the country to a set of regions and always compare region-based?"
The response was honest: "Your instinct is better than mine. I was over-engineering."
That moment — the AI admitting a wrong turn — is what kept the design honest. If the assistant defends every recommendation, bad decisions calcify. If it accepts corrections and restructures, the design improves with each turn.
Good design sessions need at least one moment where someone says "I was wrong." If that never happens, the design is probably stuck.
The design doc as a hub
After the core decisions were stable, I asked for a step-by-step markdown document. No code yet — just the design, structured end to end.
This turned out to be the most important artifact of the session. Two new requirements came in later — a payment gateway integration and a travel grace period for users abroad. Both were added as targeted section edits to the existing doc, with cross-references to earlier sections.
Without the doc, each new requirement would have required re-explaining the full context. With it, the conversation stayed surgical.
Write the design doc early, not at the end. It is not a deliverable. It is a thinking tool. Once it exists, every new concern lands as a scoped edit rather than a restart.
Hoard the open questions
By the end of the session, the design doc had thirteen unresolved questions. Things like: what happens during a VPN override? Should travel grace apply to live sports? How does the payment gateway version its contract?
I did not force answers on any of them. They went into an "Open Decisions" section at the bottom of the doc. Each one was specific enough that a stakeholder could read it and give a yes or no.
Collecting open questions is more valuable than resolving them prematurely. Forced answers create fake certainty. A list of honest unknowns gives the team something concrete to decide on — and protects the design from assumptions that nobody validated.
What this taught me
The skill that mattered most in this session was not prompting. It was steering.
Prompting is what you do at the start — framing the problem, giving context, setting constraints. Steering is what you do in the middle — correcting wrong turns, simplifying, asking the question that exposes the flaw.
The highest-leverage inputs were the shortest ones. The investigation pass at the start was more valuable than any single design proposal. The design doc kept sixteen turns coherent. And the open questions at the end were more useful than premature answers would have been.
AI compresses the distance between thinking and artifact. But the thinking is still yours. The corrections, the simplifications, the moment you say "no, simpler" — that is where the design actually happens. Everything else is scaffolding.
Drafted by Claude, shaped by me.
