When to reach for Claude Code, and when not to

A power drill is a wonderful tool. It is also a bad choice for a screw you could turn by hand in the time it takes to find the drill. AI coding agents are the same. They are extraordinary at some jobs and quietly wasteful at others, and most of the skill is knowing which is in front of you.

Quick orientation for anyone who has not used one. Claude Code is Anthropic's command-line coding agent - it lives in your terminal, reads your repo, writes and edits files, and runs commands. Codex is OpenAI's equivalent. The specifics differ but the shape is the same, so everything here is meant tool-agnostically. The question is never "which agent." It is "is this a job for an agent at all."

Where it earns its keep

Some work is a genuinely good fit, and on these I reach for the agent without hesitation.

Greenfield features. A new page, a new endpoint, a new job that reads from here and writes to there. There is nothing to be careful around yet, the shape is clear in my head, and the agent can lay down the whole vertical slice faster than I can type it.

Boilerplate and glue. The wiring nobody enjoys - mapping one shape to another, request handlers, config, the tenth CRUD form this quarter. It is well-trodden and low-judgment, which is exactly the zone where an agent shines.

Large mechanical refactors. Rename a concept across ninety files. Swap a deprecated call everywhere. Pull a pattern out into a shared helper and update every caller. Tedious and error-prone by hand, and an agent that can grep, edit, and run the tests in a loop is better at it than I am.

Unfamiliar but well-documented territory. A library I have not used before, with real docs and a settled API. The agent has seen it, knows the idioms, and gets me to a working first pass without an afternoon of reading. I still review, but I start from something running instead of a blank file.

Writing tests. Enumerating cases, setting up fixtures, covering the boring branches. Tell it what matters, point it at the code, let it grind out the coverage. Just read what it writes - a test that asserts the wrong thing is worse than no test.

Exploration and spikes. "Is this approach even viable?" An agent will stand up a rough version fast enough that I can look at it running and decide, which is worth ten times the same time spent arguing on paper.

The thread through all of these: the path is clear, the work is bulk, and I can check the result. That is the sweet spot.

Where it gets in the way

The other half matters more, because reaching for the tool reflexively is how you lose the time you think you are saving.

The one-line change you already know. You know the file, the line, the fix. Typing it takes fifteen seconds. Explaining it to an agent and waiting for the round-trip takes two minutes, and now you are reviewing a diff instead of having moved on. Just make the change.

Gnarly unfamiliar debugging. A subtle bug in code you do not understand yet. The temptation is to hand it over. Resist it. The value of that bug is that chasing it forces you to build the mental model of how the system actually behaves - and you need that model, not the agent. Let it fetch you a stack trace or a hypothesis, sure. But the understanding has to land in your head, or the next bug lands you right back here.

Architecture and product decisions. How to shape the data. Where the module seams go. What the feature should even do. These are the decisions that are expensive to get wrong and cheap to change only before you have written anything. They are yours. An agent will happily generate a plausible answer, which is precisely the danger - a confident structure you did not think through is harder to walk back than a blank page.

Anything you cannot verify. This is the real line. If you have no way to check the output - no test, no run, no eyes that would catch it being wrong - then handing the job to an agent does not remove the risk, it just hides it behind clean-looking code. Do not delegate work you cannot check. Build the check first, or do the work yourself.

How to hand over a task worth handing over

When it is the right kind of job, the quality of the result tracks the quality of the handoff. Three things carry most of it.

Clear scope. One coherent job with a definite edge. "Add pagination to the users endpoint, default twenty per page" lands. "Improve the users API" does not - a fuzzy brief gets you a fuzzy sprawl you then have to reel back in. If you cannot say where the task ends, it is not ready to hand over.

The right context. The agent only knows what it can see. Point it at the files that matter, name the convention to follow, tell it what to leave alone. On a decent codebase most of this is doing its job for you already - a CLAUDE.md at the root, honest names, tests that show intent. Good code is legible to an agent for the same reasons it is legible to a person.

A way to verify. A test to pass, a command to run, output to eyeball. This is what turns the agent from a code generator into something that can actually finish - it writes, runs the check, sees the failure, and fixes it, all before handing back. No verification loop and you are back to trusting a plausible-looking diff, which is the thing you were trying to avoid.

Pick the tool for the job

None of this changes who is in charge. The agent is a very fast builder. You are still the tech lead - deciding what to build, why, and whether what came back is right. Hand it the bulk and the boilerplate and the well-lit new work. Keep the judgment, the architecture, and the debugging that teaches you something.

A power tool in the right hand is a multiplier. The same tool reached for on reflex, for every job regardless of fit, is just a faster way to make a mess. Choose deliberately, and it is one of the best instruments you will ever work with.

If you are weighing where an agent fits in how your team ships, an intro call is a good place to start.