How Anthropic's Own Team Uses Claude Code (and What I Copied)

A year into Claude Code, the way the people who built it actually use it looks nothing like “type a prompt, watch it write code.” Anthropic’s own engineers run fleets of agents at once, fix the system instead of the instance, and make verification something an agent can do on its own. The interesting part isn’t the tool, it’s the working habits, and most of them transfer directly to how the rest of us should build.

I build with Claude Code every day, the outbound system I wrote about and the agent pipelines behind Geonimo both live in it. So when Anthropic’s team shared how they work, I paid attention to what matched my own experience and what I was still getting wrong. Here are the habits worth stealing.

Stop correcting the agent. Fix the system.

The single most important habit: when Claude does something wrong, do not just tell it to do it differently this time. Write the correction into a durable place, a rule in CLAUDE.md, or a reusable skill, so it never makes that mistake again. Correct the instance and you repeat yourself forever; fix the system and the agent compounds. This is the difference between a chatbot and a coworker.

This clicked for me because it is exactly what made my outbound system work. The “directives” I lean on there are the same idea: encode the judgment once, then let the agent execute it consistently. The artifact you are really building is not the output, it is the set of instructions that produces good output on its own.

Let Claude interview you

The worst prompt is “make it better.” The second worst is one where you try to specify every detail up front. As the models get more capable, the better move is to resist over-constraining them. Your real requirements are latent: you know what you want when you see it, but you’re bad at articulating it cold, the same way your users are. A capable model is often better at pulling those requirements out of you than you are at writing them down.

So prompt for an interview. Name the areas you care about, the audience, the constraints, then ask Claude to question you before it builds. You’ll get a spec that reflects what you actually meant, not what you managed to type at 9am. For anything visual, review the result as a rendered page and a screenshot rather than a wall of text; it is far easier to react to something concrete than to imagine it from a specification.

Verification is the real unlock (and it isn’t your unit tests)

Ask an enterprise about agent verification and they immediately think unit tests, linting, type checks. Those were already automated. The verification that matters for agents is different: can the agent run the thing and confirm it actually works? That is rarely as straightforward as a test suite, and it is the capability that separates an agent that needs babysitting from one that can run on its own.

The practical move is to make verification native to the artifact rather than bolted on. Anthropic’s team builds apps so the running state is readable by an agent (exposed in the DOM, with fixtures, known states, and invariants the agent can probe), then lets Claude run the checks, push off the happy path, and even record the result as evidence to share. The lesson generalizes far beyond front-end code: if you want an agent to work unattended, give it a way to prove to itself that the work is correct. That, more than raw model quality, is what makes long-running agents safe to trust.

Trust the agent enough to walk away

You cannot run more than one agent at a time if you are reading every permission prompt. The shift that unlocked fleets was moving from “approve every tool call” to auto-accept with a model checking each action for safety. Counterintuitively, that is safer than manual approval: when you approve 99% of prompts, your eyes glaze over and you rubber-stamp the dangerous 1%. Routing the check to a classifier means you only get pulled in for the genuinely suspicious calls.

That earned trust is what changes the unit of work. Instead of one agent you supervise, you start several, move on, and check back, the same way I run multiple agents across the Geonimo pipelines. The bottleneck stops being how fast you can type and becomes how good your ideas and your verification are.

Be a context minimalist

There was a season for prompt engineering and a season for context engineering, each matching where the models were at the time. With current frontier models the advice has flipped: give the minimal viable system prompt and the minimal set of tools, and let the model figure out the rest. Over-stuffing context is a form of micromanagement, it boxes the model out of better paths it would have found on its own. Tell it only what it genuinely needs, and leave room for its judgment.

What this means for how you build

Put these together and the job changes shape. You are no longer the person typing the code; you are the one who frames the problem, encodes the rules, designs the verification, and decides what is worth building. At Anthropic the roles have visibly merged, designers, PMs, even finance and data science work inside Claude Code, and engineers ship products end to end. The teams getting the most out of it treat the agent like the center of the process, not a tool bolted onto the side.

That is the same bet I make in my own work: the leverage is in being the person with product taste and end-to-end ownership who can turn an idea into a running system. The tool is remarkable, but it rewards the operator who brings judgment to it. See what I’ve built this way, or the stack I build with.

I use these habits to ship real products with Claude Code, from outbound systems to the LLM pipelines behind Geonimo. If you want help building this way, get in touch.