I Stopped Using Claude Code 'Correctly' and Got 3 Faster

Alexis Albouze — Mon, 20 Apr 2026 23:58:20 +0000

I was three hours into debugging a race condition when Claude Code told me it needed to compact the conversation.

You've seen this. The scroll starts. Twelve tool calls get collapsed into "I searched for the session handler." Eight file reads become "I reviewed the auth flow." All the concrete details — the exact line where the token was mutated, the specific test that flaked — gone. What remains is Claude's polite summary of what it thinks happened, which is not quite what happened.

I fixed the bug an hour later, in a new conversation, without Claude's help.

That night I rewrote how I use this tool. What follows is six months of production patterns that took me from "AI assistant" to "AI team." The throughline is one idea most people miss:

Stop treating Claude Code as one agent. Start treating it as a company.

The feature nobody explains well

Subagents are the answer. You've probably seen them mentioned. You've probably never used them seriously. I didn't, for six months.

Here's what a subagent actually is, stripped of marketing: it's a Claude process that runs in its own context window, does a scoped task, and returns only its final message to the caller. Thirty tool calls inside. A 200-word summary out.

That's it. That's the whole feature.

And that's why it matters: your context is your most expensive resource. Not your tokens — your attention. Every time Claude Code compacts, you lose fidelity. Every time your conversation window fills with git diff output, the model's reasoning narrows. Subagents are how you pay context somewhere else.

The rest of this post is five ways I do that in production, and the ugly parts nobody mentions.

Pattern 1: Swarm before you search

Your instinct when Claude says "I'll research this" is to let it do one search at a time. That instinct is wrong.

Last week I needed three things to land a feature:

How does our existing auth middleware handle token refresh?
What columns does the users_sessions table actually have?
Is there a rate limiter I can reuse, or do I need to build one?

Those three questions have nothing to do with each other. There is no reason to answer them sequentially. I fired them in one message, three subagents, parallel:

Task("How does auth middleware handle token refresh? Read
     apps/api/src/middleware/auth.ts and trace it.")

Task("Dump the current schema for users_sessions — show me
     every column, type, and constraint.")

Task("Find any rate-limiting utility in this repo. Look in
     middleware/, lib/, and package.json.")

Forty-seven seconds later I had three clean summaries. Sequential, that same work takes me six minutes and leaves my main context bloated with file contents I don't need.

The gotcha: don't do this when the questions depend on each other. If the answer to #1 tells you where to look for #2, parallel is wasted — you're just firing blind on #2.

Parallel when independent. Sequential when you're investigating.

Pattern 2: Get a second opinion from someone who wasn't in the room

A few months ago I shipped a migration that passed local tests and broke production in a way that cost us 40 minutes of partial downtime. The bug wasn't in the code. It was in my reasoning — I'd convinced myself the backfill was safe, walked Claude through my logic, and Claude had nodded along.

Of course it nodded. It had the same context I did. The same blind spot.

Now, before any migration ships, I spawn a fresh reviewer:

Task(
  subagent_type="code-reviewer",
  prompt="Review migration 0042_user_schema.sql.
  Context: adding NOT NULL column to a 50M-row table with
  backfill default. I believe this is safe under concurrent
  writes. I want an independent verdict, not validation.
  Tell me if it breaks and exactly where."
)

The subagent has no memory of my reasoning. No stake in my framing. It reads the SQL, pulls up docs on lock escalation, and tells me whether my instinct was right.

Eight out of ten times: it was. Two out of ten: a thing I'd missed. Those two are worth the pattern.

Pro tip I learned the hard way: explicitly tell the reviewer not to defer to you. Otherwise it'll say "this looks safe, but if you're unsure..." and you're back where you started.

Pattern 3: Delegate reading to someone with time

Our monorepo is 280k tokens of TypeScript. I can't fit it in a context window. Neither can Claude.

But I can send a subagent to go read it.

Last month I inherited a codebase module I didn't write. Before I touched anything, I asked:

Task(
  subagent_type="code-explorer",
  prompt="How does the billing module authenticate and
  authorize requests? I'm in apps/api/src/billing/. Trace
  the full flow from API route to the database. I want the
  3-4 files that matter, the pattern, and any gotchas."
)

Twelve minutes of the subagent reading things I didn't have time to read. I got back: "The pattern is X, the files are Y, the gotcha is that auth checks run after rate limiting, which is probably a bug."

I was writing my first PR forty minutes later. Without the subagent I would've spent that forty minutes opening files and losing the plot.

The ugly part: subagents hallucinate confidently. They'll tell you a helper function exists in a file where it doesn't, because they summarized the file in a way that felt right. I now treat every subagent summary as a hypothesis, not a fact. Trust but grep.

Pattern 4: Hire specialists

This is where the "company" metaphor gets real.

A general-purpose agent is a generalist. That's fine for most things. But sometimes you want a specialist — something with its own system prompt, its own tool allowlist, its own strict policies.

In ~/.claude/agents/ I keep small .md files that define custom subagents:

code-architect — designs features before I write them. Tools: read-only + TodoWrite. Never writes code. Returns blueprints. This stops me from vibe-coding into a corner.
code-reviewer — adversarial code review. Tools: read-only. Prompted to find problems, not approve. Explicit instructions to push back on weak reasoning.
claude-code-guide — answers "can Claude Code do X?" Tools: WebFetch, Read, Grep. No Write. No Bash. Ever. It's a documentation oracle.

Each is thirty lines of YAML + prompt. Each is version-controlled. Each does one thing really well.

The move: whenever you find yourself writing the same kind of prompt twice, that's a subagent waiting to be born. Extract it.

Pattern 5: The autonomous pattern (use with caution)

The pattern I'm most careful with.

Sometimes a task is so well-specified that I can hand it to a subagent and walk away. "Rename getUserById to getUserProfileById across the codebase, update tests, report." Fifteen minutes of my time, ten minutes of subagent work, done.

The conditions that make this safe:

The task is fully specified — no judgment calls left to make.
The work is reversible — I'm on a feature branch, sandbox, or can git reset.
I don't need to watch it — I'm not going to learn anything from watching.

Conditions that break this:

"Refactor this for clarity" — subjective, the agent will pick a direction I hate.
"Fix all the linter warnings" — some should be fixed, some should be ignored, the agent can't tell.
"Clean up the test suite" — judgment calls everywhere.

The heuristic: if you can write the task as a ticket for a junior engineer, it's safe to hand off. If you couldn't, you're about to get surprised.

Four non-obvious things that will save you

1. Every subagent prompt must stand alone.

The subagent has zero memory of your conversation. If you write "Fix the bug we discussed," it'll do something — probably wrong — and report success with confidence. Every subagent prompt should read like a ticket filed by someone walking into a standup: file, location, symptom, constraint, success criterion.

2. Never delegate synthesis.

Here's a mistake I made for weeks. I'd research a problem, get three subagent reports, and then write: "Based on the findings, fix the bug." That sentence pushes the hardest part — understanding — onto the subagent. The subagent hasn't read the three reports. The subagent has no idea what the pattern is across them.

You synthesize. You name the exact change you want. Then you delegate the typing.

3. The parent can't see raw outputs.

If you need the full test runner stdout, run the test tool directly. A subagent will run the tests, summarize them as "all 12 tests pass," and you won't have the one failure case buried in stdout.

Subagents for summaries. Direct tools for details. Know which one you need.

4. Agents lie in predictable ways.

They claim tests passed when they didn't read the last line. They claim files exist when they summarized an import statement as an implementation. They claim the pattern is X when X was the first pattern they considered and they stopped looking.

Every subagent summary is a hypothesis. Verify by reading the diff, greping the file, running the command. This one habit separates people who ship with AI tools from people who ship bugs with AI tools.

The shift

I used to write long prompts to a single Claude. More context, more instructions, more careful framing. It kept running out of room, losing fidelity, hitting compaction.

I now write short prompts to teams of Claudes. One does the research. One does the review. One does the writing. The main conversation stays focused on what it should be focused on: the decision, not the typing.

That's the 3×. Not because any single subagent is fast. Because the bottleneck was never the typing. The bottleneck was my context, and I was treating it like it was free.

Going deeper

If you want to actually build this kind of workflow end to end — custom subagents wired into hooks that run checks on every save, skills that encapsulate your team's repeatable patterns, MCP servers that give agents access to your internal systems — the gap between reading about it and doing it is real.

I run hands-on sessions in Paris at Intelligence Academy where we build this stack in a week: Claude Code, Cursor, Supabase, the works. If that's the path you want, it's the fastest one I know of.

Otherwise, the smallest thing you can do tomorrow: write one .md file in ~/.claude/agents/. One specialist. One job. Use it once. You'll understand what I mean about the shift.

What subagent patterns work for you? I want to steal the ones I haven't tried.

DEV Community: Alexis Albouze