Inside Claude Code From the Engineers Who Built It

Boris, Cat, thanks for coming on. The first time I tried Claude Code, it felt like a whole new way to program: no editor, just a conversation with the terminal. How did you decide to go all‑in on that?

It was an accident. I tried our old research tool, saw it could one‑shot real changes, then hacked a tiny terminal chat to avoid building a UI, gave the model bash and even AppleScript, and it started wiring things up on its own; that made me rethink needing an IDE at all.

Most agents wrap file actions with custom tools, but Claude Code leans on bash. What did you learn from that choice?

We now have a handful of tools for better UX and permissions, like a search tool, but we prefer fewer knobs and enforce access in bash itself; we even removed an ls tool once bash permissions were solid to reduce model choice and context load.

How do you split responsibilities, and what is “AMP fooding”?

Boris drives technical direction; I support product packaging, launches, and quality bars. AMP fooding is our version of dogfooding, and most technical folks at Anthropic use Claude Code daily, so feedback pours in and we iterate fast.

Good ideas come from the whole team—sub‑agents, hooks, plugins, even the exclamation‑bash shortcut started as a personal annoyance; we try to make features dual‑use so humans and the model share the same tools and muscle memory.

Designing for both people and the model sounds tricky. Is it actually different?

Not really; clear, elegant human UX tends to be legible to the model too.

Because it runs in your terminal, the model sees what you see and can do what you can do, which keeps the mental model simple.

For builders thinking about agents, why start local versus the cloud?

Solve your own problem first. Local makes sense for coding, though we also support web, VMs, and even quick actions from a phone for remote use when that’s more convenient.

Favorite slash commands?

PR commit is great because it spells out the exact bash sequence for a safe commit.

Slash commands can template shell output, pre‑allow sensitive steps like git push or create PRs, and route to faster models like Haiku; I also use feature‑dev and code‑review flows so Claude handles first pass reviews while humans approve.

Planning has its own tricks. I sometimes let it try something bad to learn, then reset and write a better spec. How do you approach it?

I prototype to touch all systems, then reset; simple tasks can one‑shot while bigger features benefit from plan mode to align on steps first, and as models improve, more scaffolding moves inside the model.

How do you avoid building harness features that the next model will absorb?

We build what makes the experience premium today and happily delete it later; great UX now beats over‑optimizing for obsolescence.

Plan mode itself may vanish when the model infers intent to plan; we also trimmed thousands of prompt tokens as newer models no longer needed them.

Do you optimize for smaller models or focus on the best one?

Claude Code is positioned as premium, so we tune first for Sonnet 4.5 and explore efficient paths for smaller models in parallel.

You test frontier models before release. Harness quality makes differences obvious in Claude Code. What’s the benefit of building this inside the model team?

Researchers use the tool on hard tasks, so gaps surface quickly; shared evals help close the loop, and tough workloads separate models that look similar on easy prompts.

How do you use sub‑agents, and do you ever launch many at once?

For big migrations we spin up swarms—one agent makes a to‑do, many execute in parallel, and others filter false positives; inside code review, specialized agents check style, history, and bugs before a quality pass.

I even do expense reports with a me‑agent versus a company‑agent that debate. Is the benefit the personas or the separation?

It is the independent context windows; uncorrelated reasoning streams converge on better results than one monologue.

I am tinkering with a front‑end testing agent that uses Playwright to crawl the app and surface errors; it shows promise as a plugin.

Claude Code makes cross‑project pattern mining easy. How do you support that?

It can query your version control to find prior implementations and lift the relevant pieces into the current task.

Do logs and build diaries help the model remember?

Some users keep structured journals and agents distill lessons from them; single transcripts are noisy, so aggregating across many tasks yields safer, reusable guidance.

Think of it as storage plus retrieval; as models get smarter, they already self‑serve by grepping git history or shelling out when stuck.

We practice compounding engineering: every feature teaches the next. Are you building that loop into Claude Code?

We are moving that way with QuadMD notes, auto‑written tests, and custom lint rules; power users hack first, then we generalize the wins so everyone benefits.

How do you keep it flexible for experts but simple for the rest?

We expose core primitives—status line, custom slash commands, and hooks for determinism—and plugins make it easy to browse and install community commands and MCP servers.

Our product mantra is wait for demand: build hackable seams, watch how users push the boundaries, then productize the proven use; hooks came from people wanting Slack pings for permissions without us building an integration.

You rebranded from a code SDK to an agent SDK. Why?

People were already building non‑coding agents—writing assistants, email helpers, research bots—because once an agent can run for a long time, fetch from the web, and write code, you can squint and build almost anything.

By the time we renamed it, thousands of companies were already using it that way.

Internally we also run issue triage agents that dedupe reports, open PRs, and stitch logs from places like Sentry and BigQuery; they trigger on new issues and run as long as needed, and the future is more proactive agents, though today we are focused on rock‑solid task completion.

Why pick agentic retrieval over vector search, and are embeddings still relevant?

We used embeddings first but constant reindexing and local changes made them brittle; agentic search gets comparable accuracy with cleaner ops, though you can still wire your own index via MCP; top MCPs we love include Puppeteer, Playwright, Sentry, and Asana.

Any power‑user habits people should adopt?

Invite it to ask you questions, especially in plan mode; it behaves more like a real collaborator and lands better plans.

Do not skip plan mode, check in a project settings JSON to pre‑allow or block commands for your team, and use stop hooks to force keep‑going loops until tests pass; dangerous no‑prompt modes exist but use them judiciously.

You kicked off this CLI wave. Is the terminal the final form?

No, but we’re making it exceptionally smart while we explore other surfaces.

Autonomy windows keep lengthening into hours, which raises questions about persistent containers and Claude‑to‑Claude monitoring; expect new interfaces soon alongside the CLI, VS Code GUI, web, and mobile.

The terminal intimidates new users.

We see that too, which is why the VS Code GUI and web app are friendlier on‑ramps, with more graphical paths coming.

Adjacent teams like data science are adopting it, and while we’ll keep core focus on pro engineers, we want the system hackable so others can succeed.

If code is wordy, just say simplify and it tightens it up; that is faster than a command because it needs almost no context.

We are still early on the adoption curve; micro‑skills keep shifting as models improve, so we try to stay humble and learn in public.

Building for yourself is the best compass, and AI reset the board so you can ship personal tools that matter.

I have a shopping advisor agent and a light email responder built on the SDK; inside the team, demos beat docs because a fifteen‑second clip communicates the vibe instantly.

Cheap prototypes let you iterate until it clicks.

We rebuilt plan mode multiple times, and shared interactions like Shift‑Tab for auto‑accept or Shift‑T for plan make the system feel consistent.

We codify style in QuadMD, cultivate product sense, and even taught thinking toggles to move from natural language to clear UI; extended thinking boosts Sonnet 4.5 a lot and is now one tap away, and our favorite metric is red diffs; unship when a better thing replaces it, and despite more code, per‑engineer output is up around seventy percent by simple measures like PRs.

Ship faster and you risk clutter. How do you keep it coherent?

We insist on intuitive primitives and progressive reveal—inline tips, change logs, thinking notices—and even let the model demonstrate features; press Control O to see raw transcripts only when it helps.

Everyone is racing to a CLI now. How does that change your mindset?

Imitation is flattering; we mostly keep our heads down and build what our users and we need next.

How do you think about unshipping on your side?

We are not great at it yet, especially in our email product where power and clarity are both essential; we want to prune without losing flexibility.

Unshipping has a social cost because someone’s feature is on the line, so it takes conviction.

At Instagram we deleted features based on real usage rather than burying them, and it kept the product clean and focused.

This was fantastic. Thanks for sharing how you think and build—keep going.

This is AI and I, a treasure chest of brain‑popping insights with Dan Shipper at the helm. Tap like, hit subscribe, and buckle up for more—this ride moves fast.