Key insights:
Claude Code is now used by NASA, major tech companies, and thousands of startups. But it started as a simple terminal chat app that one engineer built to test an API. Boris Cherny, the creator of Claude Code, recently sat down with the Y Combinator Lightcone podcast to share the full story. What he revealed is a masterclass in product development, building for the future, and staying humble as an engineer.
The origin story is surprisingly accidental. Boris joined Anthropic's labs team, which was exploring coding products. Nobody told him to build a CLI. He just needed to understand the Anthropic API, so he built a small terminal chat app to interact with it.
"I just built like a little terminal app to use the API. That's all that I did," Boris explained. He didn't build a fancy UI because it was just for himself. The terminal was the cheapest, fastest way to get something working.
Then tool use came out. Boris gave the model the bash tool, mostly because it was the example in the docs. He asked it to read a file. It worked. Then he asked it what music he was listening to. The model wrote AppleScript to check his Mac's music player. That was his first "feel the AGI" moment.
Boris expected the terminal to have a three-month lifespan. He thought they'd quickly move to something more sophisticated. That was over a year ago, and the terminal is still the primary interface.
The reason is simple. Every UI they could have built would have been irrelevant within six months because the model was improving so fast. The terminal's constraints became its strength. You don't need to understand Vim, tmux, or SSH. You just open the tool and it guides you.
"If you asked me this a year ago I would have said the terminal has like a three-month lifespan," Boris admitted. "I've been wrong so far about the death of the CLI. So I'm probably not the person to forecast that."
The model wasn't great at writing code initially. Boris used it personally for automating git commands and operating Kubernetes. The first coding use case was writing unit tests because it was lower risk.
But the internal adoption at Anthropic was explosive. Two days after the first prototype, Boris's teammate Robert was already using it to code. When they did their launch review, Anthropic's CEO Dario asked if engineers were being forced to use it because the adoption chart was vertical. They weren't. People just kept telling each other about it.
Boris shared several principles that guided Claude Code's development. These aren't abstract theories. They're lessons learned from shipping a product that now accounts for 4% of all public code commits worldwide.
Boris called latent demand "the single biggest idea in product." He mentioned it repeatedly throughout the conversation. The concept is straightforward: people will only do things they already do. You can't get people to do new things. You can only make existing behaviors easier.
Plan mode is a perfect example. Before it existed, users were already typing things like "come up with a plan but don't write any code yet" into their prompts. Boris saw this pattern in GitHub issues and internal Slack feedback. He built plan mode in 30 minutes on a Sunday night and shipped it Monday morning.
CLAUDE.md came from the same principle. Users were already writing markdown files with instructions and having the model read them. Boris just formalized what people were already doing.
At Anthropic, the team builds for the model six months from now. This sounds counterintuitive because you can't find product-market fit if the product doesn't work today. But Boris argues it's essential.
"If you spend a bunch of work and find PMF for the product right now, you're just going to get leapfrogged by someone else because they're building for the next model," he said. The practical approach is to feel out the boundary of what the current model can do, then build for where you think it'll be in six months.
When Claude Code launched, the model could barely write code. Boris was betting that it would get good at coding. That bet paid off. If he'd only built for what the model could do at launch, the product would look completely different and probably wouldn't exist.
The Claude Code team has a framed copy of Rich Sutton's "The Bitter Lesson" on their wall. The core idea is that the more general approach always beats the more specific one. In practical terms: never bet against the model.
Boris calls non-model code "scaffolding." You can build scaffolding to improve performance by 10-20% in some domain. Or you can wait a couple months and the next model will just do it natively. The team constantly faces this trade-off.
The result is that Claude Code gets completely rewritten on a regular cycle. "There is no part of Claude Code that was around six months ago," Boris said. They remove tools every couple weeks and add new ones. About 80% of the codebase is less than a couple months old.
Boris shared specific workflows and tips that reveal how power users get the most out of Claude Code. Some of these insights challenge common assumptions about how to work with AI coding tools.
Boris's personal CLAUDE.md has exactly two lines. The first enables automerge on PRs. The second posts PRs to the team's internal Slack channel. That's it.
His advice for anyone whose CLAUDE.md has grown too large: delete it and start fresh. "The capability changes with every model," he explained. "Do the minimal possible thing in order to get the model on track." If you delete your CLAUDE.md and the model goes off track, add instructions back one at a time. With each new model, you'll need less.
The team's shared CLAUDE.md is also relatively short, maybe a couple thousand tokens. Multiple team members contribute to it several times a week. When someone makes a preventable mistake in a PR, Boris tags Claude on the PR and says "add this to the CLAUDE.md."
Boris starts about 80% of his sessions in plan mode. His workflow involves opening multiple terminal tabs, starting each in plan mode, then moving to the desktop app's code tab for even more parallel sessions. Once a plan looks good, he tells Claude to execute.
With Opus 4.5 and beyond, Boris found that once the plan is solid, the model stays on track almost every time. The babysitting shifted from "during and after execution" to just "during planning."
Here's the interesting part: Boris thinks plan mode has a limited lifespan. Claude Code can now enter plan mode by itself. The team is working on making it enter plan mode at exactly the point where a human would have wanted to. "Maybe in a month," Boris said when asked if explicit plan mode prompting would become unnecessary. Plan mode itself is remarkably simple. All it does is add one sentence to the prompt: "please don't code."
A sub-agent is just a recursive Claude Code instance. The team calls the parent "mama Claude." Boris calibrates the number of sub-agents based on task difficulty. For really hard research tasks, he might spawn three, five, or even ten sub-agents to research in parallel.
One practical tip Boris shared: for debugging, have one agent look at logs while another looks at the code path. His Claude Insights feature actually suggested this to him, recommending he spin up multiple sub-agents for parallel debugging instead of doing it sequentially.
The team's plugins feature was entirely built by a swarm of agents over a weekend with minimal human intervention. An engineer gave Claude a spec, told it to use an Asana board, and Claude created tickets, spawned agents, and the agents picked up tasks independently.
Boris made some bold predictions about where things are heading. These aren't speculative fantasies. They're extrapolations from trends he's watching inside Anthropic every day.
Boris thinks the title "software engineer" will eventually go away. It might become "builder" or "product manager" or persist as a vestigial label. But the work will change fundamentally.
On his team at Anthropic, every function codes. PMs code. Designers code. Engineering managers code. The finance person codes. Boris sees this spreading everywhere. Engineers will also write specs, talk to users, and do product research. The specialist coder role is dissolving into a generalist builder role.
He sees two types of effective engineers on his team: hyper-specialists who understand one domain better than anyone, and hyper-generalists who span product, design, user research, and business. The generalists are increasingly valuable because they can direct AI tools with broader context.
The numbers are staggering. Since Claude Code's introduction, productivity per engineer at Anthropic has grown 150%, measured by pull requests and cross-checked against commits and commit lifetimes. The team doubled in size, but productivity per person grew 70% on top of that.
For context, Boris was previously responsible for code quality at Meta across all products. There, a 2% productivity gain represented a year of work by hundreds of people. A 150% gain is, in his words, "completely unheard of."
Boris personally lands about 20 PRs per day. He uninstalled his IDE. He doesn't edit a single line of code by hand. It's 100% Claude Code. Across Anthropic, AI-written code ranges from 70-90% depending on the team, with many individuals at 100%.
Boris offered several concrete pieces of advice for builders:
For dev tool founders specifically, Boris recommends thinking about what the model wants to do and making that easier. Don't put the model in a box with a rigid API. See what tools it wants to use, see what it's trying to do, and enable that.
If you're interested in building automation systems and working with AI tools like Claude Code, the Complete RPA Bootcamp teaches you to go from beginner to pro with Robotic Process Automation, Agentic Automation, and Enterprise Orchestration. Instead of letting AI replace you, you become the one building the automation. You can apply here.
For the full conversation with Boris, including his thoughts on TypeScript parallels, terminal UX design, and why he left Meta for Anthropic, watch the complete interview embedded below from the Y Combinator YouTube channel. It's packed with insights you won't find anywhere else about how one of the most important developer tools of this era was built.
