How Claude Code Was Built: The Engineer Behind the AI Coding Tool Changing How We Write Software

Posted on by
Contents show
How Claude Code Was Built: The Engineer Behind the AI Coding Tool Changing How We Write Software
How Claude Code Was Built: The Engineer Behind the AI Coding Tool Changing How We Write Software

How Claude Code Was Built: The Engineer Behind the AI Coding Tool Changing How We Write Software

Boris Cherny did not set out to build one of the most talked-about AI tools in tech. He was a Principal Engineer at Meta, a TypeScript book author, and someone who genuinely cared about code quality long before AI made it a hot topic. When he joined Anthropic and started tinkering with a side project that eventually became Claude Code, he had no idea it would reshape how engineers think about their own jobs.

This piece breaks down the key ideas from his conversation with Gergely Orosz on The Pragmatic Engineer podcast. Whether you are a developer, a student learning to code, or just someone curious about where software is heading, there is something worth thinking about here.

What Is Claude Code and Where Did It Come From

From Side Project to Core Tool

Claude Code started as something Boris built for himself. It was not the result of a big product meeting or a company-wide initiative. He was at Anthropic, experimenting with how AI could assist with actual coding tasks, and the tool slowly grew from a personal utility into something the whole company started using.

That kind of origin story matters. A lot of great software tools begin the same way: someone builds exactly what they need, and it turns out other people needed it too. Claude Code fits that pattern perfectly.

It is now a command-line tool that lets you work with AI agents to write, review, and manage code. And Boris, the person who built it, uses it to ship somewhere between 20 and 30 pull requests every single day.

The 5 Terminal Tabs Workflow

Here is where things get genuinely interesting. Boris does not just open one instance of Claude Code and ask it to do things one at a time. He runs five separate terminal tabs, each pointing to a different checkout of the codebase. Each tab has its own Claude agent working on a different task.

The process goes like this. He starts Claude in what is called “plan mode,” which means the agent lays out what it is going to do before doing anything. Boris reads that plan, refines it, pushes back if something looks off, and then lets the agent go. Once the plan is solid, the agent typically completes the implementation in one shot.

His words on this: once there is a good plan, it will one-shot the implementation almost every time.

That is a big deal. It means the quality of your input, specifically the planning stage, determines almost everything. Vague instructions lead to bad results. Specific, well-thought-out plans lead to clean code.

Building Claude Code with Boris Cherny

Lessons Boris Carried Over From Meta

Code Quality Has a Measurable Impact on Output

Before Anthropic, Boris spent five years at Meta as a Principal Engineer. One of the most important things he did there was run a study on code quality and its effect on engineering productivity. The results were not subtle. Clean, well-maintained codebases boosted output by a meaningful, double-digit percentage.

That lesson did not stay behind at Meta. It applies just as much to AI-generated code. When a codebase is messy, partially migrated, or mixing multiple frameworks in inconsistent ways, both human engineers and AI models get confused. The model cannot figure out which pattern to follow. Engineers waste time deciphering what is supposed to be the “right” approach.

Boris puts it plainly: always make sure that when you start a migration, you finish the migration.

That sounds simple. In practice, it is one of the hardest things to enforce in a real engineering team. Migrations get deprioritized. Teams ship new features on top of half-finished refactors. The technical debt quietly accumulates. Boris argues that this is not just a hygiene issue. It directly affects how much you can actually get done.

Automating Yourself Out of Code Review

Here is one of the more unusual things Boris did at Meta. He was one of the most active code reviewers at the company, which sounds impressive until you hear what he did with that role.

Every time he left the same type of review comment more than three or four times, he wrote it down in a spreadsheet. Once a pattern showed up that many times, he turned it into an automated lint rule. Basically, he kept making his own job smaller by automating away the repetitive parts of it.

Most people would see frequent review comments as evidence that they are doing important work. Boris saw them as evidence that a machine should be doing that part instead.

That mindset, automating the repeatable and focusing human attention on the parts that actually require judgment, is exactly the kind of thinking that leads to tools like Claude Code.

How Claude Code Actually Works Under the Hood

The Surprisingly Simple Search Strategy

One of the questions people have about AI coding tools is how they find the right information in a large codebase. With millions of lines of code, how does the agent know which files are relevant to the task at hand?

The Claude Code team tried several approaches. They experimented with local vector databases, which are a more technically sophisticated way of storing and retrieving code by meaning. They tried recursive model-based indexing. They tried other approaches that sounded fancy and promising.

None of them worked better than the simple alternative: regular glob and grep commands, driven directly by the model.

Glob and grep are old Unix tools. Glob finds files by pattern matching. Grep searches for text inside files. They are not glamorous. They do not involve machine learning or embeddings. They are just fast, reliable, and accurate.

The inspiration for this came from something Boris observed at Instagram. Meta's internal coding editor had a feature called click-to-definition, which lets you jump directly to where a function or variable is defined. When that feature broke, Boris watched how engineers adapted. They started searching the codebase manually, using basic search commands. They were surprisingly effective.

That observation stuck with him. The lesson was that simple tools used intelligently often beat sophisticated tools used blindly.

Permissions, Sandboxing, and What Happens When AI Edits Files

Giving an AI agent the ability to read and write files is not a decision to take lightly. Claude Code has a permission system that asks for approval before doing anything significant. Boris went deep into how this works, especially around sandboxing, which is the concept of isolating what the agent can and cannot touch.

This matters even more for Claude Cowork, which is a related product designed for non-technical users. More on that in a moment.

Building Claude Cowork in 10 Days

Who Actually Uses Claude Code (Hint: Not Just Engineers)

While Claude Code was built with software engineers in mind, the team noticed something interesting. People who were not engineers were also using it. Data scientists, people in finance, people in sales operations. They were hacking around with the tool even though it was clearly designed for a technical audience.

Boris and the team saw that as a signal. There was demand for a version of this kind of tool that did not require you to be comfortable with a terminal.

Claude Cowork is what they built in response. It is a desktop application aimed at those non-technical users who still want to automate tasks, manage files, and work with AI without needing to know what a command line is.

Why Safety Was the Hard Part

You might think that building Cowork was mostly about adding a nicer interface. The reality was more complex. The actual hard engineering work was almost entirely about safety.

The team had to build classifiers to understand what the agent was about to do before it did it. They set up a virtual machine environment to run potentially risky operations in isolation. They added operating system-level protections specifically designed to prevent accidental file deletion. And they rethought the entire permission model for users who do not have a technical background and might not know what they are approving.

Cowork launched fast, built in roughly ten days, and grew faster in its early days than Claude Code did at launch.

The Culture at Anthropic That Makes This Possible

No Job Titles, Just “Member of Technical Staff”

One of the more unusual things Boris shared was about Anthropic's internal structure. Everyone at the company carries the same job title: Member of Technical Staff. There are no senior engineers, no staff engineers, no distinguished engineers in the traditional sense.

The reasoning behind this is specific. Without role-based titles, the default assumption is that everyone contributes to everything. Product thinking, design, infrastructure, research, it all bleeds together. Nobody can say “that is not my job” because there is no title signaling what anyone's job is supposed to be.

Boris described it as inverting the typical relationship between people, even when they do not know each other well. You do not go in assuming someone is above or below you. You just go in and work together.

Prototypes Instead of Documents

The Claude Code team does not write Product Requirement Documents, or PRDs, before building features. PRDs are the long specification documents that have been a standard part of product development for decades. You write one before building anything, it describes what you are going to build, and teams use it to align before writing any code.

At Anthropic, Boris says they skip that entirely. Instead, they build dozens of working prototypes before committing to a direction.

He was direct about why: there is no way they could have shipped what they shipped if they had started with static wireframes, Figma mockups, or a PRD. The product changes too fast, the tools change too fast, and the only way to know if something works is to build it and try it.

What This Means for Software Engineers Going Forward

Context Switching Is the New Deep Work

Boris made an observation about his own work that is worth sitting with. His days used to look like most engineers' days: long stretches of focused, single-threaded work on one problem at a time. That kind of deep, uninterrupted concentration was the gold standard.

Now, his days look completely different. Managing five parallel agents means constantly switching context. One agent finishes a plan and needs review. Another has hit a problem and needs direction. A third has produced a pull request that needs a quick check. You are never staying in one place for very long.

He put it this way: it is not so much about deep work anymore. It is about how good you are at context-switching and jumping across multiple different contexts very quickly.

That is a real shift in what makes someone effective as a software engineer. It raises interesting questions about which working styles will thrive in this new setup.

The Scribe Analogy

Boris brought up an analogy that is worth thinking about carefully. In medieval times, scribes were a small, elite group who knew how to read and write. They worked for kings, nobles, and institutions who were largely illiterate. They held significant power because of that skill.

When the printing press arrived, scribes technically lost their exclusive role. The skill they had was no longer rare. But what actually happened was not the end of writing as a profession. It was the beginning of a massive expansion of it. Many scribes became writers and authors. The market for written work grew far beyond what anyone had predicted.

Boris wonders if software engineers might follow a similar path. Coding is becoming more accessible. AI tools are lowering the barrier to writing software. Does that mean engineers become irrelevant?

His read is the opposite. Engineers who understand how to think about systems, who know how to manage AI agents effectively, who understand code quality and architecture, they might end up building things with a reach that was never possible before. The role shifts. The leverage grows.

Skills That Actually Matter Now

What Still Requires a Human

The conversation ended with a practical question: given all of this, what should engineers actually focus on developing?

A few things came up:

  • The ability to write a clear, specific plan before handing anything to an AI agent. Garbage in, garbage out still applies.
  • System thinking. Understanding how large pieces fit together is harder to delegate than writing individual functions.
  • Code review judgment. Not the repetitive kind that can be automated with lint rules, but the kind that catches architectural problems and design choices.
  • Communication. The lines between engineering, product thinking, and design are blurring at fast-moving teams. Being able to operate across those areas is becoming more valuable.
  • Finishing what you start. That lesson from Boris about completing migrations applies broadly. Half-done work creates compounding problems over time.

A Note on Who This Favors

Boris made a somewhat personal observation: the shift toward managing parallel agents and rapidly switching between tasks might actually favor people who have always worked that way. People whose brains do not naturally settle into long single-threaded focus. People who have historically been told their working style was a liability.

The technology has maybe caught up to a different kind of mind.

Final Thoughts

What Boris Cherny built with Claude Code is a product, yes. But the story behind it is really about a way of thinking about software, work, and the role of the engineer.

The ideas he brought from Meta about code quality, about automating repetitive review, about the value of finishing migrations, those all fed directly into how Claude Code was designed and how he uses it.

The lesson is not just “use AI tools.” It is about building good habits around clarity, planning, and quality, and then using AI to extend what you can do with those habits.

If you are learning to code right now, or thinking about what kind of engineer you want to become, the foundation has not changed as much as it might seem. Being specific, thinking about systems, caring about quality, and being willing to automate the boring parts so you can focus on the interesting ones. That is still the job.

The tools just got a lot more powerful.

More Posts:
Subscription Form