ailiteracynepal 🇳🇵
Text size

Chapter 02 · Section III · 12 min read

Scoping tasks tightly

A big task and a small task look identical to Claude Code at the moment you press Enter. Learning to size an ask — small enough to verify, big enough to be worth the round-trip — is the productivity dial nobody teaches you.

The most common way engineers waste time with Claude Code is asking for too much at once. A single prompt that says “add authentication, wire up sessions, add rate limiting, and write the migration” will get you something — but that something will be four things that all half-work, and you will spend the next hour un-tangling which half.

The unit of work is “one thing you can verify”

A well-scoped prompt is one where, when the assistant claims to be done, you can check whether it is done in under five minutes. If the check would take twenty minutes and require reading three files, the scope was too big. Split it.

Concretely, that usually means:

  • One feature per prompt, not a bundle.
  • One file at the centre of the change, not a sweep across the tree.
  • A pass criterion you already have in mind before you press Enter: “the test passes,” “the type-checker is clean,” “the endpoint returns 201.”

The unclosed scope trap

Some prompts are perfectly worded but structurally impossible to close. Examples:

  • “Improve the code quality of this file.”
  • “Make this more idiomatic.”
  • “Optimise this.”

None of them have a stop condition. Claude will produce something, and it will look plausible, and you will have no way to tell whether it did what you meant. Rewrite these as closable asks: “Reduce the cyclomatic complexity of parseInput from 14 to under 8, preserving behaviour and tests” is closable. “Make it more idiomatic” is not.

Sizing up, not just down

The opposite mistake exists too. If every prompt is a tiny surgical fix, you spend more time reading Claude’s replies than doing work. For internally-consistent changes — “rename this class and update all callers” — one prompt covering the whole rename is fine, because the check (“does the type-checker still pass?”) is one command.

The right size is: a unit small enough to verify in one glance and big enough that Claude’s context-switching cost is worth paying.

When the task is genuinely big

Genuinely big work — “implement OAuth from scratch across the frontend, backend, and mobile app” — is not one prompt at all. It is a project. The right move is:

  1. Sketch the plan yourself, or with Claude in advisor mode.
  2. Break it into steps you would put on a checklist.
  3. Give Claude one step per prompt. Verify. Next.

Skipping step 1 and jumping straight into step 3 is the classic path to a lost afternoon.

Check your understanding

Quick check

Which of these is the best-scoped prompt?