Key insights

• Claude Code now authors 4% of all public GitHub commits and is predicted to reach one-fifth by year's end
• Anthropic's core product strategy is to build for the model six months from now, not today's model
• Cherny argues the title 'software engineer' will start disappearing by end of year, replaced by 'builder'

---

In Brief

Boris Cherny, the creator and head of Claude Code at Anthropic, tells Lenny Rachitsky that coding is "largely solved" and that the real question is what comes next. He argues that the job title "software engineer" will begin to disappear by year's end, replaced by a broader role he calls "builder." The conversation covers how a throwaway terminal hack became a product that now accounts for 4% of all public GitHub commits, why Anthropic deliberately underfunds teams to force creative AI use, and what the printing press can teach us about the disruption ahead.

---

The claim: coding is a solved problem

Cherny's central argument is direct. At the 18-minute mark, he states that "coding is largely solved" for the kind of programming he does (18:20). He has not edited a single line of code by hand since November and ships 10 to 30 pull requests (PRs, proposed code changes submitted for review) per day, all written by Claude Code (16:50).

He backs this up with scale. According to a Semi Analysis report, Claude Code now authors 4% of all public commits on GitHub (the world's largest code hosting platform), and that figure is predicted to reach one-fifth of all commits by year's end (5:55). The day the episode was recorded, Spotify announced that its best developers hadn't written a line of code since December (6:11).

At Anthropic, productivity per engineer reportedly increased 200%, measured in pull requests (21:27). Cherny compares this to his previous role at Meta, where hundreds of engineers working on code quality produced gains of "a few percentage points" per year. The gap, in his framing, is enormous.

---

The next frontier: beyond writing code

Cherny argues that the interesting frontier is no longer code generation itself. Claude Code is already starting to come up with its own ideas by scanning feedback channels, bug reports, and telemetry data (17:55). He describes a case where a newer engineer on his team simply asked Claude Code to investigate a memory leak. The AI took a heap snapshot, wrote its own analysis tool on the spot, found the bug, and submitted a fix faster than Cherny could do it manually (22:55).

The model isn't just executing instructions anymore. Cherny uses Cowork (Anthropic's non-coding agent product) for project management, paying parking tickets, and coordinating his team through Slack and spreadsheets (18:40). Cowork was built in 10 days, entirely with Claude Code, and was used by millions shortly after launch (52:01).

The origin of Cowork illustrates a product principle Cherny calls "latent demand." People were using Claude Code for tasks it was never designed for: growing tomato plants, analyzing genomes, recovering corrupted wedding photos, analyzing MRIs (49:20). When non-technical employees at Anthropic started downloading Node.js just to access Claude Code through a terminal for SQL analysis, the signal was clear (50:01).

---

Principles for building in the AI era

Cherny shares several principles that guide the Claude Code team, many of them counterintuitive.

Underfund teams slightly

Anthropic deliberately puts fewer people on projects than traditional management would suggest. The constraint forces engineers to lean harder on AI, which leads to creative solutions that wouldn't emerge from a well-staffed team (24:28). Some Anthropic engineers spend hundreds of thousands of dollars per month in tokens (the units AI models use to process text, roughly 3-4 characters each) (27:45).

Give engineers unlimited tokens

Cherny advises companies not to optimize costs early. Let engineers experiment freely with the most capable model, and only optimize once an idea proves viable (26:11). This runs counter to the instinct of most CTOs, but Cherny argues the cost of individual experimentation is low relative to salary.

Build for the model six months from now

The early versions of Claude Code wrote only 20-30% of Cherny's code. The bet was that the model would catch up. When Opus 4 launched, it did, and growth went exponential (1:05:56). For startups, this means accepting weak product-market fit initially while betting that the next model will close the gap.

Don't box the model

Many builders instruct AI to follow rigid step-by-step workflows. Cherny argues this is almost always worse than giving the model tools and a goal, then letting it figure out the path (1:03:46). He ties this to Rich Sutton's "Bitter Lesson," a widely cited essay arguing that the more general approach always wins over the specialized one in the long run (1:04:45). Custom scaffolding might improve results by 10-20%, but those gains often get wiped out by the next model release.

Speed above all

If you can do something today, do it today. When Claude Code was just Cherny working alone, speed was the only competitive advantage against established coding tools (25:04).

---

The printing press analogy

Cherny reaches for a historical parallel. In mid-1400s Europe, literacy was below 1%. Scribes did all reading and writing for lords who often couldn't read themselves. The printing press changed that: in the 50 years after its invention, more material was printed than in the previous thousand years. The cost of printing dropped roughly 100 times. Global literacy eventually rose to 70%, though it took 200 years (32:59).

Cherny sees AI coding as a similar moment. A capability locked away to a small professional class is becoming accessible to everyone. He imagines a world where anyone can build software on demand, and suggests the consequences are as unpredictable as they were in 1450 (40:17).

He also shares a historical document where a 1400s scribe, asked about the printing press, was reportedly enthusiastic: the scribe said what they disliked was copying between books, while what they enjoyed was the art and the book binding. Cherny draws a parallel to his own experience as an engineer who no longer misses the tedious parts of coding (34:14).

---

Opposing perspectives

The roles question

Lenny Rachitsky ran an informal poll on X/Twitter. Among engineers and product managers (PMs), 70% reported enjoying their jobs more since adopting AI tools. Only about 10% said less. But among designers, only 55% said more and 20% said less (44:37). Cherny doesn't have a clear explanation for the gap, though he notes that Anthropic's designers largely code and seem to enjoy the new dynamic.

The broader prediction is that distinct roles (engineering, design, product management) will blur. Cherny suggests the job title "software engineer" will start to disappear by year's end, replaced by "builder" or something similar (43:10). On the Claude Code team, everyone codes: the PM, the engineering manager, the designer, the finance lead, the data scientist (41:33).

The skills and disruption question

Cherny acknowledges that coding skills will likely become irrelevant within a year or two, comparing modern programming to assembly language running beneath a higher-level abstraction (31:29). For now, understanding the layer underneath still helps, but he thinks this window is closing fast.

He doesn't avoid the pain that comes with this. He says the transition will be "very disruptive" and "painful for a lot of people," and frames this as a societal conversation, not just an industry one (40:32). Anthropic has hired economists, policy researchers, and social impact specialists to study the effects.

---

Safety as a product strategy

Cherny describes three layers of AI safety at Anthropic, each serving a different purpose (54:04):

The third layer explains why Anthropic releases products that feel rough. Claude Code was used internally for four to five months before public launch specifically to study safety (55:33). Cowork was called a "research preview" because the team needed real-world data on how a non-coding agent behaves when given access to people's email, Slack, and browser (56:05).

Anthropic also open-sources safety tools like its sandbox (a secure environment that limits what the AI agent can access on your system), designed to work with any agent, not just Claude Code (59:10). Cherny calls this the "race to the top."

---

How to interpret these claims

Cherny makes big claims with genuine conviction, but several factors deserve careful consideration before accepting them at face value.

The insider perspective

Cherny leads the product he's evaluating. His personal workflow (100% AI-written code, 10-30 PRs per day) happens at Anthropic, where the entire company is built around AI fluency and where engineers get unlimited tokens. Most companies have legacy codebases, compliance requirements, and engineers who aren't yet comfortable with AI tools. The gap between Anthropic's internal experience and the broader industry is likely significant.

Productivity metrics

The 200% productivity increase is measured in pull requests. But more PRs don't necessarily mean better software. A single PR that redesigns an architecture can be worth more than thirty that fix minor issues. Cherny acknowledges this indirectly when comparing to Meta, where "a few percentage points" of productivity gain was considered meaningful. The metric difference matters.

The "solved" framing

"Coding is largely solved" is a statement about Cherny's personal workflow, not a universal claim about all programming. He qualifies it with "at least for the kind of programming that I do" (18:22). Systems programming, safety-critical software, embedded systems, and fields with strict regulatory requirements may tell a different story. The gap between "solved for a senior AI engineer at a frontier lab" and "solved for the industry" is worth noting.

The printing press comparison

The analogy is compelling but imperfect. The printing press created a new skill (reading) that took 200 years to spread. AI coding tools are replacing an existing skill. The economic dynamics are different: scribes found new work in illumination and binding, but the comparison to modern software engineers losing their primary skill is not straightforward. Cherny himself acknowledges the transition will be "painful for a lot of people."

What strong evidence would look like

Independent studies measuring output quality (not just quantity) across diverse codebases and engineering teams, over timeframes longer than a few months. Controlled comparisons between AI-assisted and traditional development on production software with real users. Longitudinal data on what happens to code quality when the humans reviewing AI-generated code understand less and less of what they're reviewing.

---

Practical implications

For engineers

Cherny's advice is blunt: experiment with AI tools, don't be afraid of them, and become a generalist (40:59). The strongest engineers he works with cross disciplines. They combine product sense, design instinct, or business understanding with technical skills. The people who will be rewarded most are "curious generalists" who think about the broader problem, not just the engineering part (42:11).

His practical tips for Claude Code: use the most capable model (Opus 4.6 with maximum effort), start roughly 80% of tasks in plan mode (shift+tab twice in the terminal), and try different interfaces beyond the terminal (1:09:20). He notes that using a less capable model often costs more tokens because it requires more corrections.

For product builders

Build for the model that will exist in six months. Accept that your product-market fit will be weak at first. Don't box the model into rigid workflows. Follow latent demand: watch how people misuse your product, then build for that use case. And move fast.

For company leaders

Give engineering teams unlimited AI tokens. Underfund projects slightly to encourage creative AI use. Don't optimize costs until an idea has proved its value. The token cost of individual experimentation is small compared to engineering salaries.

---

Glossary

---

Sources and resources