Clarify before you code

The function that did exactly what you asked

The task says: “write a function to deduplicate the user list.” You describe it to the assistant, it returns a clean implementation that drops rows where every field matches, the sample input collapses nicely, tests pass. Done in six minutes.

Except the list has the same person three times — once as jane@work.com, once as jane@home.com, once as Jane Smith with a typo. The team meant those are duplicates. Your function kept all three. The AI didn’t make a mistake; it solved the problem you actually gave it, fast and well.

Predict, before reading on: at what moment was this outcome decided? Not while coding — the code is fine. It was decided at a question you didn’t ask, before a single line existed.

The cost of a confident wrong aim

Clarification has the best cost asymmetry in all of engineering, and AI widens it. The price of asking is one sentence and a few seconds. The price of not asking is everything downstream of a wrong assumption — the design, the implementation, the tests you wrote to confirm it, and the time to discover the mismatch — all of which the AI helped you produce faster, so there’s more sunk in the wrong direction when you finally notice.

This is the counter-intuitive consequence of the last chapter’s “stakes rise” argument. Cheaper production doesn’t make aim matter less; it makes it matter more, because the cost of executing the wrong target dropped to near zero while the cost of choosing the wrong target stayed high. When solving the wrong problem is slow and painful, the pain is a (late, expensive) signal. When it’s fast and pleasant, nothing warns you. So the discipline has to move to the front, on purpose.

In an interview this is doubly true: clarification is the behaviour that scores Trade-off Awareness, and skipping it is the second-most-common reason strong candidates are cut. The interviewer is often watching for the question as much as the answer.

What to clarify

Not all clarification is equal. A question about the language or a variable name signals that you don’t know where the risk is. The high-value move is to find the one term or requirement the whole solution pivots on and resolve that. A working checklist, fastest payoff first:

• The pivotal term — the word with two meanings (“duplicate,” “relevance,” “recent,” “valid”). Resolving it changes the algorithm, not the syntax.
• The success condition — what does “done and correct” look like concretely? What’s the output on the input that isn’t in the examples?
• The shape and scale of inputs — empty, huge, malformed, adversarial; 100 rows or 100M.
• The binding constraint — latency, memory, a dependency you may/may not use, an SLA.

How to deliver it: restate the problem in your own words, then ask one targeted question. The restatement alone catches half of all misunderstandings, and it shows the interviewer your model of the problem. When there’s no one to ask — a timed take-home, an automated round — narrate the assumption and isolate it: “relevance isn’t defined, so I’ll assume recency-weighted and keep the scoring function swappable.” An un-answerable ambiguity then becomes visible judgment instead of a silent guess, and the isolation limits the blast radius if you guessed wrong.

Predict the pivotal question in each case before you reveal it:

The pattern: in each one, several questions are useful but exactly one resolves the ambiguity the whole design hangs on. Aiming is choosing that one.

Clarify with the AI, not just the human

Here’s the move that turns the assistant from a liability into an asset at this stage: clarify with it before you ask it to build. Prompt it to restate the problem, enumerate edge cases, and list the assumptions it’s about to make — before “now implement it.” A good model will surface the dedup-key ambiguity or the missing staleness policy on its own, which is exactly the thinking you want done early.

The discipline is ownership. The AI’s restatement is a draft of the spec, not the spec. You read its enumerated assumptions and decide which to accept, which to override, and which to escalate to a human — and you say so. The failure mode is letting the model’s confident restatement slide silently into being the requirement: that’s just the original “wrong aim” problem with an extra step. Used well, the assistant becomes a tireless clarification partner; used passively, it launders your vagueness into a plausible-looking target.

How this is graded

• Technical Correctness — your clarifying questions target the pivot that changes the algorithm (the dedup key, the staleness policy), showing you know where correctness actually lives.
• Trade-off Awareness — you decide scope and assumptions explicitly, and you weigh one-shot-now vs confirm-first against the cost of being wrong.
• Evaluation Rigor — clarifying the success condition is the seed of your test plan: you can’t define “right” (next chapter) until you’ve pinned what the task means.
• Communication (weighted) — restating the problem and narrating assumptions out loud is clarification and the clearest early signal that you understand what you’re being asked.

Industry variation

• Startups — clarify scope fast: the highest-value question is often “what’s the smallest version that’s actually useful?” so AI velocity ships the right MVP, not a polished wrong one.
• Big tech — in system-design rounds, clarification is the opening: scale, SLAs, read/write ratios. Jumping to boxes before pinning these is the classic cut.
• Regulated (fintech, health) — clarify the compliance constraint up front (PII handling, auditability); it’s frequently the binding requirement that reshapes the whole design.
• Frontier labs — clarify the actual research question and its evaluation before optimizing anything; “what would make this experiment conclusive?” beats a fast wrong metric.

Stretch: from aim to committed target

You’ve aimed — you know what the problem actually is. But an aim in your head still drifts once the AI starts producing plausible code. The next move is to make the target binding: write down the files, invariants, and tests that define “right” before you prompt, so the model has a specification to satisfy instead of a vibe to match. Sketch, for the “recent orders” task above, the two or three invariants you’d commit before generating a line.

Next: Chapter 3 — Preregistration, where clarification becomes a contract — “preregister, not prompt theater” — and governance over automation gets its sharpest tool.