Tasks too big for one prompt

Everything works beautifully at small scale. You ask, Claude does it, you look at the result. The loop is so easy that people carry it straight into work it can’t hold — and that’s where the afternoon goes.

The failure is specific and it’s worth naming, because it doesn’t look like a failure while it’s happening. You ask for something large in one sentence. Claude, being capable and willing, starts building. Twenty minutes later there’s a great deal of work in front of you, and it is confidently, thoroughly, the wrong thing. Nothing malfunctioned. It just answered a question you didn’t realise you’d asked vaguely.

First: is this actually a big task?

The instinct is to measure size in lines of code. That’s the wrong ruler — a one-character change can be enormous and a two-hundred-line change can be trivial.

A task is big when you can’t say, in one sentence, exactly what done looks like — because there are decisions to make and things nobody knows yet.

Size lives in the decisions and the unknowns. Four signals give it away:

• It spans multiple files. One file is usually one idea. Six files is six places to be subtly wrong.
• It contains real decisions. Which library? Where should this live? What happens to people who already signed up? If you’d have to stop and choose, so will Claude — and it will choose for you if you let it.
• It has unknowns. Things neither of you can predict without looking. “There’s auth code somewhere but I don’t know how it works.”
• You can’t describe done in one sentence. If the finish line is fuzzy to you, it’s fuzzier to Claude.

One signal is a yellow light. Two is a red one.

And note the trap: the big task usually sounds shorter. “Add a blog section” is three words and hides four decisions. “Change the headline on the homepage to my name” is eight words and hides none. Word count is a liar; counting the hidden decisions tells you the truth.

Plan before you act

The moment you spot size, your next message is not the work. Asking a big task cold is telling a contractor “build me a kitchen” and leaving for the weekend — you’ll come back to a kitchen, just probably not yours.

Instead, get a plan first. Plan mode is built for exactly this: Claude reads, explores, and proposes an approach while touching nothing. The mechanics of it — how to turn it on, how it sits alongside the other permission settings — are on permissions and staying in control. What matters here is the arithmetic, which is lopsided enough to settle the argument:

• Writing a plan costs minutes; reading one costs thirty seconds.
• Undoing a botched multi-file task costs an afternoon.

It is always cheaper to disagree with a plan than to undo the work. Plan mode moves the disagreement to the cheapest possible moment: before any work exists. Same instinct as measuring before you cut. The five minutes up front are not the slow part — the do-over is.

Skip it for the small stuff. Reading a plan for a typo fix is pure ceremony. The four signals above are also your plan-mode signals.

Then argue with the plan

Here’s the failure that wastes the plan you just asked for: it arrives neatly numbered, sounds confident, and you approve it. Then you spend an hour fighting the thing you approved.

A plan is not a contract. It’s a draft, and its entire value is that it’s still cheap to argue with. Arguing is the point; approving is not.

Read it looking for trouble. Four things to scan for:

• Wrong assumptions. It guessed at something you actually know. “I’ll add a build step to compile the styles” — but your site is deliberately plain HTML with no build step. It didn’t know. Now it does.
• Missing edge cases. The happy path is handled and nothing else is. What about the empty state? The error case? The page with no posts yet?
• Scope creep. The plan is helpfully doing more than you asked — restyling neighbouring pages, renaming things, tidying a file you never mentioned.
• Things it should have asked. Where does this file live? What’s it called? One page or many? If Claude picked where it should have asked, the plan is where you catch it.

A worked example, because scope creep is the one that hides best. You asked for a blog page. The plan comes back:

1. Add a blog.html page with placeholder posts.
2. Add a “Blog” link to index.html.
3. Style the posts to match styles.css.
4. Clean up the old contact handler in server/index.js while we’re in here.

Steps 1–3 are the blog. Step 4 rewrites your backend, which you never mentioned. “Skip step 4 — don’t touch server/, just add the blog.” One sentence, and you’ve just avoided debugging a broken contact form an hour from now.

Pushing back needs no special syntax, only specificity: “keep it plain HTML and CSS, no build step”, “put the posts in one blog.html, not a file each”, “what does the page look like with no posts yet?” Claude revises and shows you again. You’re still in plan mode; nothing has moved. Go around as many times as you need — the going around is the work right now.

Slice it yourself

Sometimes you read the plan and your gut says no — not because any step is wrong, but because there are fifteen of them and you can already tell three will drift. The fix isn’t a better plan. It’s a smaller one.

Never let a single run of work be longer than you can check.

This is the one part of this page that is entirely yours. Plan mode and the checklist come from Claude; deciding how big a bite to take is your call, and a lot of the real skill lives there.

Think of each slice as a checkpoint. A big task done in one shot has exactly one checkpoint — the end — so if it’s wrong, all of it is wrong at once. The same task in four slices has four, and a problem surfaces at the slice where it started. More slices, more checkpoints, less to throw away.

To pick the first slice, look for the first piece whose result you can see and check on its own. Very often that’s the reading piece:

First slice	What you get
Bad first slice	”Add the whole blog section.” Now you’re staring at a new page, homepage edits and a pile of CSS with no idea whether any of it is right.
Good first slice	”List exactly which files you’d touch and roughly what changes in each — don’t edit anything yet.” Nothing was edited, and you can now see the surface area and judge whether this is a tidy three-step job or a scary thirty-step one.

What gets in the way is ambition. You want it done in one shot — one prompt, walk away, come back to a finished feature. One big shot that fails costs far more than three small ones that each work, so the slow-looking path is almost always the faster one. It just doesn’t have a do-over hiding at the end.

Watch the TODO list

Once work starts on something multi-step, a checklist usually appears in the chat — items moving from pending, to in progress, to done. That’s the TODO list, and it’s doing more for you than it looks.

Claude writes it to keep itself honest: laying out the steps, committing to them on screen, and ticking them off so nothing quietly gets dropped. For you it’s the difference between a spinner and a window. You can see where it is (“step 3 of 5”), what’s still coming, and — most usefully — the seams. If something needs correcting, interrupting between items is far cleaner than interrupting inside one, and the list is what shows you where those moments are.

One correction, since it catches people: the list is not a contract. As Claude learns things mid-task it may revise an item, add one it didn’t foresee, or drop one that turned out unnecessary — and you want that. But it means “the TODO said it would do X” isn’t a guarantee. So read the list when it appears. If a step is missing, wrong, or something you don’t want, say so right then. Objecting at step 3 costs a sentence; noticing at step 5 costs a do-over.

Interrupt early — the cost is not flat

Claude is working, you’re watching, and something’s off. Wrong file, an approach you know won’t work, suspicious confidence about something you’re certain is false. Stop it. In the Desktop app that’s the stop control on the running task; in the terminal it’s Esc.

Drift comes in three recognisable shapes:

• Wrong direction. It’s solving a slightly different problem than the one you asked about. You wanted a fix; it’s doing a redesign.
• Right direction, wrong choice. Correct file, correct goal, using a library or pattern you don’t want.
• Spinning. It tries something, it fails, it tries almost the same thing again. Twice is coincidence. Three times is a signal.

Any of them is enough. You don’t need certainty — a strong hunch will do, since pausing costs nothing and you can always say continue.

The reason “early” is the whole game is that the cost of waiting isn’t flat, it compounds with every file touched. Interrupt at minute one and you lose a sentence. Interrupt at minute ten and you lose ten minutes of work plus the time to untangle it.

What stops people is politeness — a faint sense that interrupting is rude, like talking over someone mid-sentence. Let it go. Watching a machine carefully build the wrong thing in order to be polite is the most expensive courtesy in software.

Then redirect briefly and specifically: “you’re editing the wrong file — the blog link goes in index.html”. Claude picks up from there; what it already did stays, and you can keep or undo it.

When to stop nudging and start over

Some conversations go bad in a way no nudge can rescue. Claude is confidently wrong, or looping on a broken approach, or certain a function exists when it doesn’t — and the thread gets heavier and less useful with every message.

When a conversation is stuck, more messages usually make it worse. Stop and start a fresh one.

That feels backwards, and the mechanism explains why it isn’t. Everything said so far is still in the conversation, including the wrong turn five messages ago. Each new reply is coloured by that context, so you’re not correcting a clean slate — you’re stacking a correction on a growing pile of confusion, and the pile usually wins. It’s giving directions to someone already lost and rattled: past a point, more directions are just more noise.

So end it and open a new one, but carry across only what mattered — the finding, plus the lesson:

“Earlier I tried adding the blog by editing the navigation inline in every page and it kept getting tangled, because the markup is duplicated across index.html, about.html and contact.html. Try a different approach, and only touch blog.html and index.html.”

That hands the fresh conversation the useful discovery without the dead ends, and adds a tighter constraint so there are fewer ways to wander off again. It’s the slicing instinct, used as a rescue.

The thing to get past is sunk cost. Fifteen minutes of wrestling feels like something you’d be throwing away — but those fifteen minutes taught you what doesn’t work, and that comes with you. A fresh conversation armed with what you learned will usually fly past the one you’ve been nursing.

A different problem that looks the same: a conversation going perfectly well that has simply run long, until Claude starts dropping details you settled an hour ago. That’s not a bad thread, it’s a full context window, and the fix is to tidy rather than discard — /compact instead of /clear. The tell is timing: sharp early, slipping only after a long session. That belongs to running a session well.

Are you iterating, or thrashing?

There’s a subtler version of the stuck conversation, and it catches people who are doing everything else right. You ask for a fix, then another, then a refactor on top of that, then a different approach to the refactor — and an hour later you genuinely can’t tell whether you’ve moved forward or walked in a circle.

If you can’t say what’s still wrong in one sentence, you’re either done or stuck. Both have the same next move: stop.

The signals, in rough order of reliability:

• Each new prompt is shorter and vaguer than the last (“just make it work”).
• You’re re-asking the same thing in different words.
• You’ve reverted the same change two or three times.
• You’ve forgotten what the original task was and would have to scroll up to check.
• The diff is growing in directions you don’t remember asking for.

Any one of these alone is fine. Two together is a strong signal. Three is the alarm.

The reset is the same shape as the restart above, and it isn’t quitting: decide what the actual goal was and write it down, note where things currently stand (commit it, or note which file is in what shape), then start a new chat carrying only the file and the goal. A fresh conversation with a clean prompt routinely resolves in three turns what fifteen turns of drift couldn’t.

The workflow is the skill

Look back at the moves. Not one is clever. Plan mode is a keystroke. Reading a plan is reading. Stopping is one key. Slicing is choosing a smaller bite. Individually none of it would impress anyone.

Chained together, they’re the difference between handing Claude something big and hoping, versus handing it something big and steering. Spot the size, plan, argue, slice, watch the list, interrupt on drift, compact when it runs long, restart if it truly stalls.

The result isn’t that big tasks get easier. It’s that they stop being one bet and become a series of small, checkable steps — which is the same thing every experienced person does with large work, in any field, for exactly the same reason.