How to Drive Claude Code Like It's Stolen

This is part of a series where we're building a DIY journey analytics platform from scratch. If you're just joining, check out the earlier posts to catch up!

Rather than walk through the next feature I've built for Trevorwithdata, I want to take a small detour and talk about how I'm actually building things.

Over the last few months, I've received two different types of reactions to this series. Some people reach out and ask a version of "how are you building this so fast on your own?" Other folks, who are usually too polite to mention it directly, say something like "Sure, anyone can vibe-code a compelling prototype. Production software is something else entirely."

Here's the thing - folks are right to be skeptical. There's certainly no shortage of vibe-coded AI slop out there, and as a technical PM leader who's delivered big data software to thousands of enterprises for over 15 years, the difference between a slick screen recording and software you'd actually put in front of an enterprise is not lost on me. The gap is huge, btw. The sheer number of edge cases, integration paths, and reliability concerns you have to handle to make an app dependable, scalable, and secure is something one person with a single AI chat session can't truly close in my opinion.

And yet... Claude Code's latest ability to spin up multiple simultaneous teams of agents is changing the limits of what's possible to such an extreme degree it's hard to appreciate.

So, for the rest of this post, I'm going to show you how I drive Claude Code like it's stolen: not as a single smart engineer, but as an entire engineering org. And to me, paying only $200 a month for an entire engineering org feels like straight up theft from Anthropic...

How Engineering Orgs Are Usually Structured

Before we get into Claude Code itself, let's first talk about how software engineering organizations are typically put together. Stick with me, because this is the mental model that the rest of this post hangs on.

If you've worked near a real engineering team before, you already know the shape of it. The codebase is shared, but the responsibility for it is divided. Someone owns the frontend, someone owns the backend services, someone owns the data infrastructure, someone owns the platform and deployment layer, and there's usually a QA function sitting slightly apart from all of them. Everyone can technically see the whole repository. Almost nobody works across all of it.

That division exists because of a hard limit: no single engineer can hold an entire production system in their head, not even that one dude who's been at the company since 1997. Even those experienced engineers hold only the shape of the system, meaning the interfaces, the contracts, and a rough map of where things live. The deep, detailed knowledge of any one area lives with the specialist who works in it every day. The whole thing functions because the boundaries between areas are clean enough that people can collaborate through interfaces instead of through total understanding.

Additionally, there's almost always a coordination layer: an engineering manager, a tech lead, a PM, a program manager. Their job is not to write the code; instead they translate goals into scoped pieces of work, hand each piece to the right person, review what comes back, and manage the dependencies between teams. And typically teams will write things down in some form: onboarding guides, architecture docs, working agreements, product requirements docs, or the "here's how we do things here" wiki.

Here's why I'm walking through all of this: an engineering org is a system for getting work done when the problem is bigger than any one mind can hold. And as it turns out, the structure companies evolved to manage human cognitive limits maps pretty well to managing a team of AI agents in my experience.

The rest of this post is going to cover how I've recreated that structure: a coordinator that never writes code, a set of specialists that each own one service, a QA function that verifies but never fixes, and a stack of written agreements that keeps all of them pointed the same direction.

Side Note: Agents in Claude Code

The general idea of an "AI agent" has been kicking around long enough that I'll assume you get the gist. What's worth nailing down before we go further is what "agent" specifically means inside Claude Code, because the term gets used a few different ways and two of those ways matter for the rest of this post.

In Claude Code, an agent is a session: an instance of Claude with its own context window, its own scope (typically a directory in the repo), its own configured set of tools, and a working contract (the CLAUDE.md files it loads on startup). You can spawn one as the main session you're talking to, as a named teammate inside an agent team, or as an ephemeral subagent that a parent agent spins up for a single focused task.

The team-vs-subagent distinction is the easy one to conflate. A teammate is durable: it stays in the team for the whole work session, you can DM it directly, it can DM its peers, and it owns its slice of the codebase the entire time. A subagent is ephemeral: a parent agent spins one up to do a single focused thing (like "read these twenty files and summarize how the SQL builder works"), the subagent does it, returns one answer, and disappears. Roughly: a subagent is like an intern, a teammate is a colleague.

Trevorwithdata uses both. The team is the org chart. Subagents are how an individual teammate offloads a chunk of grunt research without cluttering its own context window. With that distinction in hand, let's move on to how this works for Trevorwithdata in practice.

Meet the Team

So let's meet the Trevorwithdata team! Every one of these is a Claude Code agent with a specific role, a specific patch of the codebase, and its own written working contract. If the previous section resonated, you'll recognize the org chart immediately.

At the top is the lead, the session I typically talk to. It's my chief of staff: it takes my asks, breaks them into scoped pieces of work, and hands each one to the right specialist. When the work comes back, the lead reviews the diff, writes the commit message, and opens the PR. Specialists never push to git themselves, which means the lead has to actually read each diff instead of just trusting the teammate's summary of what changed. The lead never writes product code itself either. What makes it useful in that role is the context loaded into its root CLAUDE.md: what Trevorwithdata is, who our users are and what they're trying to accomplish, our product principles and roadmap, plus a high-level map of which service owns what and where the seams between them are. It's not deep code knowledge, but it's enough to scope, route, and review without bugging me about every decision.

Under the lead is a roster of specialists, one per service in the Trevorwithdata repo. Each one is scoped to a single folder and never works outside it:

Agent	Owns	Human equivalent
Apius	`services/api`	Backend engineer: the HTTP API, query execution, roles and permissions
Uigene	`services/ui`	Frontend engineer: the Next.js app, notebooks, the onboarding flow
Aiden	`services/ai`	AI engineer: the Claude-powered "Ask Trevor" assistant and its tools
Movet	`services/data-mover`	Data engineer: ingestion, stitching replays, schema drift, the long-running jobs
Billy	`services/billing` (WIP)	Billing engineer: Stripe integration, usage metering, trial credits
Infrancis	`infra`	Platform engineer: the Helm chart, deployments, multi-region clusters
Qebert	`qe`	QA: verifies everything, files bugs, and fixes nothing itself

Yes, the names are dumb 😆, but the prefix of each name encodes the role: Apius for the API, Uigene for the UI, Aiden for AI, Movet for the data-mover, Billy for billing, Infrancis for infra, Qebert for QE. When a notification pops up saying "DM from Qebert," I know exactly what's going on without having to remember which session was doing what.

The most important thing about each specialist is that it reads its own service's CLAUDE.md before doing anything else. That file is its working contract: how its specific service is built, the conventions to follow, the gotchas that have burned past sessions, the things that are explicitly out of scope. This is the "onboarding doc" parallel from the last section made literal. Uigene loads the UI conventions and the design system, Apius loads the API patterns and the role-enforcement rules, Movet loads the ingestion contract. None of them load any of the others, which is the whole idea. Bounded scope keeps each agent's context window clean and its work consistent.

Qebert earns a special mention because it's the one team member (outside of the lead) structurally forbidden from writing code. Its entire job is to reproduce a problem, trace it, and file an actionable bug report back to the lead. The toolkit for that is built around Playwright (wired up via MCP), which lets Qebert drive the UI in a real browser - reproducing bugs, capturing failing screenshots, and verifying that fixes actually behave the way the design says they should - plus the standard shell tools for hitting API endpoints with curl, checking logs, and reading source to trace root causes across the stack. If anyone asks Qebert to "just fix it," its working contract tells it to push back and route the work to the right specialist instead. This is the same wall real orgs put between QA and engineering, and for the same reason: the person who confirms a bug is broken shouldn't also be the person who decides it's fixed.

Put it all together and you have an org chart. A coordinator who never codes, a set of specialists who each own one service and never reach outside it, a QA function that verifies but never fixes, and a stack of written contracts that keeps everyone aligned.

There's also one more new "hire" I'm genuinely excited about. Anthropic recently launched Claude Design, which is awesome for creating visuals and prototypes that stay consistent with a product's design language. In our org, Claude Design is now the UX lead and owns the design system (more on this later) - what used to be a folder of static handoff files that Uigene diffed the UI against is now an active teammate that holds the visual language and can produce new designs that respect it. The division of labor stays clean: Claude Design owns what it should look like and how it should flow, Uigene owns making the code match. I won't pretend I have it perfectly dialed in this early, but having a real design function instead of a folder of files already feels like a meaningful shift. If anyone at Anthropic happens to read this - I just wish Claude Design had a better way of actually allowing my agent team to communicate with it! 🥺🙏

That's the team, newest hire and all. The rest of this post is how I actually drive it.

Tips For ClaudeMaxxing

I spent some time at the Anthropic booth at Google Cloud Next this year, where I got to hear Lydia Hallie walk through best practices for running Claude Code at scale. She presented four pillars for running it autonomously and safely:

Make the loop reliable
Run multiple instances
Personalize Claude Code
Ship safely at scale

In my experience, those pillars basically unpack into a list of concrete tips for, as my kids would say, ClaudeMaxxing. (I asked Lydia for the deck she presented afterward and she hasn't published it yet, so consider this a public second ask, Lydia if on the off chance you actually read this. 😁) Based on my experience and what Anthropic recommends, here are my top tips:

Invest heavily in CLAUDE.md. It's the closest thing we have to durable, no-cost shared context - every Claude Code session loads the files in scope automatically. The Trevorwithdata repo has a root CLAUDE.md plus per-service ones, and when I notice Claude making a mistake, the fix usually isn't a smarter prompt next time, it's a sentence added to the relevant CLAUDE.md so the next session doesn't make the same mistake.
Write specs before prompts. For anything bigger than a one-line tweak, a few minutes spent writing a clear spec (what we're building, what success looks like, what's out of scope, what the gotchas are) pays for itself many times over. Claude Code's plan mode is helpful for getting there.
Encode procedures as skills. When a CLAUDE.md section grows from a fact ("the API uses Firebase Auth") into a procedure ("here's how to add a new endpoint: 1, 2, 3..."), promote it to a skill. Skills load on demand and are invokable by name, so they don't eat context on every session. A /ship skill, for example, runs the lint and typecheck, stages everything, writes a conventional commit message, opens a PR, and posts the link.
Wire in MCP servers for external tools. The two I lean on most are BigQuery (for validating our data replication process is working perfectly) and GitHub (for issue management and PR review). Custom MCPs are easy to write and let me hand Claude purpose-built tools instead of asking it to compose shell commands.
Trust auto-mode as the proof point. When auto-mode runs a long task cleanly without me having to step in, that's the signal that the CLAUDE.md, the spec, the skills, and the MCP tooling are all in the right place. Until you can trust auto-mode on a workflow, the rest of these tips don't really pay off, because you'll still be sitting there clicking "approve" on every tool call.
Run multiple teams in parallel via git worktrees. Instead of pushing four independent jobs through a single lead, I spin up a separate lead for each initiative, each running its own team of agents in its own worktree. The leads run independently and in parallel, and I rotate between them reviewing diffs and unblocking decisions. Real product orgs scale in a similar way for a reason: when every workstream funnels through one coordinator, that coordinator becomes the bottleneck.
Keep yourself in the loop for the high-stakes stuff. For anything touching sensitive stuff like customer data or auth, my lead can write the code, run the tests, open the PR, and ping me, but the merge button stays mine. The "drive it like it's stolen" frame applies to the volume of work, not the riskiness of it: aggressive on the low-stakes surface area, careful on the high-stakes one.

A few honest caveats worth flagging. Running multiple teams burns a crap-ton of tokens, but the $200/month Claude Code Max plan lands almost perfectly for my nights-and-weekends usage - I usually hit 90%+ of my weekly budget by Sunday, and the throughput I get in return is mind-blowing. None of this worked at this scale for me until Opus 4.6 either, and even Opus 4.7 has its quirks (mostly over-engineering when left unsupervised), though smart team contracts and good CLAUDE.md files keep that mostly in check. And there are more knobs in Claude Code I haven't leaned on personally but absolutely would in a team setting: hooks for hard guardrails, plugins for bundling everything into shareable packages, and managed settings for org-level policy enforcement.

Now does this really give you parity with an entire engineering org? Honestly, yes in some ways, no in others. The throughput is genuinely there for a lot of work, especially the well-scoped, bounded changes that make up the bulk of shipping product. Where it falls short is the messier, more ambiguous work that benefits from years of accumulated taste and judgment - the kind of calls a senior engineer makes by instinct that an agent might over-engineer, miss, or get backwards. What's been exhilarating to watch is how fast the gap is closing. Even six months ago this whole setup wouldn't have worked, and now it does. I'm starting to see a world where the gap closes the rest of the way - maybe sooner than we'd have guessed.

Closing Thought

The throughput delta from running Claude Code at scale is honestly crazy and I expect this will only accelerate over time as Anthropic adds more agent team capabilities. It comes from making each session reliable, running several teams in parallel, building real tooling around them, and putting guardrails on the parts that need them. The frame I keep coming back to is the one from the start of this post: an engineering org is just a system for handling work that's bigger than any one mind can hold, and that's exactly what we're building when we run Claude Code as a team instead of as a chat window.

If you want to compare notes on how you're running Claude Code, or if you're building something similar and want to swap setups, connect with me on LinkedIn. And if you want to follow along as we keep building Trevorwithdata, the rest of the series is here.

Trevor Paulsen is a data product professional at UKG and a former product leader of Adobe's Customer Journey Analytics. All views expressed are his own.