Strategic prompting: the prompt is a specification

Two prompts, one task, different programs

Two engineers need the same thing: validate an email for their signup form. One prompts “write a function to validate emails.” The other prompts “validate an email for a signup form: require exactly one @, a non-empty local part, and a dotted domain; treat tagged addresses (user+tag@…) as valid; return a bool; don’t pull in a validation library.”

The first gets a 200-line regex copied from a decade of Stack Overflow folklore that rejects the team’s own user+tag@ addresses. The second gets the function the team actually needs. Same task, same model, same minute.

Predict, before reading on: the model didn’t get smarter for the second engineer — so where did the difference come from? It came from which of them supplied the specification, and which left it to the model to guess.

Prompt as spec

If you did Chapter 3, the hard part of prompting is already done. The prompt should carry your clarified problem and your preregistered invariants and constraints — that is the precise prompt. The difference between the two email prompts above is exactly the difference between handing over a spec and asking the model to invent one.

This is also why chasing prompt “tricks” is a trap. Phrasings, magic words, and tool-specific syntax drift with every model release; “supply the specification the model would otherwise guess” is true of every model, this year and next. When a prompt underperforms, the durable fix is almost never a cleverer sentence — it’s a missing piece of spec. Ask what decision you left to the model’s defaults, and put it in the prompt.

Decompose or one-shot?

The main judgment call at this stage is granularity: ask for the whole thing at once, or break it up? The heuristic is about architecture content, not size:

• One-shot when the task is well-specified and has a single obvious shape — a pure function with clear inputs and outputs, your invariants attached. There are no architecture decisions to own, so let the model produce it and move to reading.
• Decompose the moment real architecture decisions appear: multiple components, ambiguous structure, anything large enough that a single output is hard to review. You prompt for the pieces and keep the seams — the interfaces between parts — because seams are where integration bugs concentrate and where your design judgment shows.

The un-one-shottable problem is the point of the harder modern rounds (Canva’s “complex, ambiguous, realistic” tasks): they can’t be vibe-prompted in one shot, so they reveal whether you can carve a problem into verifiable pieces. Predict the right approach in each case:

The thread: state the spec, decompose where architecture lives, and steer at the prompt rather than patching the output.

Constraints and context

A precise prompt supplies two things beyond the goal. Context: the interfaces and types it must match, the invariants from your preregistration, a representative example. Constraints: the boundaries — and crucially the negative ones. The model fills every unstated gap with a common default, so “don’t add a dependency,” “don’t change the public signature,” “handle the empty case explicitly” are not nags; they’re you closing the gaps before they open. A constraint in the prompt costs a clause; the same constraint enforced by hand-editing every regenerated output costs the rest of your session.

Context economy matters too: supply what’s relevant — the interface, the invariant, the one tricky example — not the entire codebase. A precise, scoped prompt beats an exhaustive one, the same way a good spec beats a data dump.

How this is graded

Trade-off Awareness is this chapter’s weighted dimension — the decompose/constrain decisions are trades made out loud:

• Trade-off Awareness (weighted) — you choose one-shot vs decompose by where architecture and risk live, and you scope context to what’s relevant rather than dumping or starving it.
• Technical Correctness — your prompt carries the invariants, so the spec you hand over is the correct one, not the model’s default.
• Evaluation Rigor — you constrain the output (including negatives) so it’s gateable, and you decompose the risky seam so it can be verified on its own.
• Communication — narrating why you’re decomposing here and constraining there shows the interviewer the judgment behind the prompt, not just the prompt.

Industry variation

• Startups — one-shot the small stuff to move; decompose only the core that must be right. Speed with a verified spine.
• Big tech — prompts become reviewable artifacts; decomposition tends to mirror service and module boundaries the team already reasons about.
• Regulated (fintech, health) — constraints encode compliance: “no PII in logs,” “no external calls,” stated in the prompt and enforceable in review.
• Frontier labs — precision matters most exactly where the problem is novel, because the model’s defaults were trained on the common case, which is the one you’re not solving.

Stretch: a good prompt earns good code — reading earns the right to ship it

A precise prompt dramatically raises the odds the output is right. It does not make it certain, and it does nothing about your understanding of what came back. Before the next chapter: when the model returns your rate limiter, what are the first two things you’d actually read — not skim — and why would a clean, well-commented result make that reading harder, not easier?

Next: Chapter 5 — Reading AI-generated code, where comprehension becomes the skill, and the fluency of the output is the trap.