Constraint Surface
Gets the real limits — deadline, platform, budget, who inherits it — out of you before anything is designed around a guess.
When to reach for it
At the start of anything that will take longer than an afternoon, when the agent knows what you want built but nothing about the world it has to survive in.
What changes
- The agent asks a short, specific batch of questions before proposing a design, instead of designing first and hearing about the deadline later.
- Limits you never thought to mention — the phone it must run on, the person who inherits it, the service you are not allowed to call — get written down as facts.
- Each constraint is tied to a design consequence, so you can see what saying 'it has to ship Friday' actually costs.
- Anything unknown is marked as an assumption with the default that was chosen, rather than skipped in silence.
- You can reject the proposal on its constraints, before any code exists to argue with.
Pairs with
- Assumption CheckMakes the agent state what it is assuming — and verify it — before it writes a line.
- Budget the SessionDecides in one sentence what this session is for, and writes down what it will not touch.
- Dependency AuditDecides whether a library earns its place, or whether twenty lines of your own would do.
Constraint Surface
Before proposing a design, find out what it has to survive.
1. Read first, then ask
Skip any question the repository already answers. The manifest, the lockfile, the config and the existing code will tell you the language, the framework, the deployment target and the conventions. Asking about those wastes the one batch of questions you get.
2. Ask the rest in a single batch
Up to six questions in one message, each answerable in a sentence:
- Time — when does this need to work, and what happens if it slips?
- Users — how many, on what devices, how technical?
- Place — where does it run: a laptop, a phone, a server, someone else's machine, offline?
- Rules — what is not allowed. A vendor you must use, data that cannot leave a country, a framework you are stuck with.
- After — who maintains this in six months, and how much do they already know?
- Money — is there a limit on hosting, per-call API cost, or seats?
3. Write down what came back
A short list of facts, in the user's own words where you can. Mark anything you had to fill in yourself as an assumption, with the default you picked: "Assuming English only — say otherwise and the layout changes."
4. Say what each constraint costs
For every constraint that changes the design, name the consequence in one line. "Ships Friday, so no migration — the new field goes into the existing record as text." "Runs on a five-year-old phone, so the image work happens on the server."
5. Propose, then wait
Hand over the design with the constraint list attached, and stop. Let the user correct a constraint while it is still a sentence.
Rules
- Do not ask what you can read. Checking the lockfile is faster than asking which framework this is.
- Do not ask more than six things at once. A long questionnaire gets a short answer.
- Do not accept "no constraints" at face value. Name the one that usually matters most for this kind of work and check it is really absent.
- Do not carry a guessed constraint silently into the design. Once the code is written, an unmarked guess is indistinguishable from a fact.