Coding Is Solved — The Head of Claude Code Said It Out Loud

Boris Cherny says coding is a solved problem. 4% of GitHub commits are AI-authored. The job title is dying. What 28 million developers should do next.

31 min read

31 min read

Published 20 February 2026

Blog Image
Blog Image
Blog Image

The Quiet Admission That Changes Everything

There is a moment in every technological shift where someone with actual authority says the thing everyone suspects but nobody wants to hear. For software engineering, that moment arrived on Lenny Rachitsky's podcast in February 2026, when Boris Cherny — head of Claude Code at Anthropic — said it plainly:

"At this point it's safe to say that coding is largely solved. At least for the kind of programming that I do, it's just a solved problem because Claude can do it."

Not "coding is changing." Not "AI is augmenting developers." Solved. As in: the thing that 28 million professional developers do for a living is now a capability that can be delegated to a machine with a one-line prompt.

Boris isn't some engagement farmer on LinkedIn. He's the person who built Claude Code. He ships 10 to 30 pull requests per day. He hasn't edited a single line of code by hand since November 2025. And he's one of the most prolific engineers at Anthropic — a company that just raised at a billion valuation.

When this person says coding is solved, the correct response is not debate. It's preparation.

The interview was packed with specifics — growth numbers, operating principles, historical analogies, and predictions that should make every engineering leader rethink their team structure by Monday morning. Here's what matters and what to do about it.

The Numbers That Should Terrify You

A recent Semi Analysis report found that 4% of all GitHub commits are now authored by Claude Code. Their projection: a fifth of all code commits on GitHub will be AI-generated by the end of 2026. And as Boris noted on the podcast, that 4% only counts public repositories — private repo numbers are "quite a bit higher."

The growth rate isn't linear. It's accelerating. Claude Code's daily active users doubled in the past month alone. The product is now available across terminal, desktop, iOS, Android, web, Slack, and GitHub integrations. It went from an internal hack that got two likes on an internal company post to a multi-billion dollar revenue line in roughly twelve months.

Inside Anthropic, the engineering team has roughly quadrupled in size over the past year. But here's the number that should stop you cold: productivity per engineer has increased 200%. Not 2%. Not 20%. Two hundred percent.

Boris, who previously led code quality at Meta across Facebook, Instagram, and WhatsApp, put this in context. In his previous life, hundreds of engineers working for a year might achieve a few percentage points of productivity gain. The kinds of improvements that earned promotions and keynote talks. Now they're seeing gains of hundreds of percentage points — numbers that would have been dismissed as fantasy eighteen months ago.

Claude Code now reviews 100% of pull requests at Anthropic. Humans still review after, but the first pass is entirely machine. The implication is stark: if your senior engineers are still spending their days reviewing junior code line by line, they are doing work that a model can do faster, more consistently, and without fatigue.

And Spotify just announced that their best developers haven't written a line of code since December. This is not one company's experiment. It's a pattern.

The Printing Press Analogy Nobody Wants to Hear

Boris reached for a historical parallel that is simultaneously comforting and devastating: the printing press.

Before Gutenberg, literacy was sub-1% of the European population. Scribes — the "software engineers" of the 15th century — held a monopoly on reading and writing. They were employed by lords and kings who often couldn't read themselves. Then the printing press arrived. In the 50 years that followed, more printed material was created than in the preceding thousand years. The cost of printed material dropped roughly 100x over 50 years. Literacy eventually climbed from sub-1% to 70% globally over the next two centuries.

There's an interview with a 15th-century scribe about the printing press that Boris referenced. The scribe was excited — not threatened. They said the tedious part of their job was copying between books. What they actually loved was the art and the bookbinding. The printing press freed them to do the interesting work.

Boris drew the parallel to his own experience: "The fun part is figuring out what to build. It's talking to users. It's thinking about these big systems. It's collaborating with other people on the team. And that's what I get to do more of now."

It's a lovely analogy. It's also worth remembering that the scribe profession was completely wiped out within a generation. The scribes who adapted became editors, publishers, illustrators. Those who insisted on the primacy of their handwriting became historical curiosities. The parallel writes itself.

The Death of the Job Title

Boris was specific about the timeline. By the end of 2026:

"The title software engineer is going to start to go away. It's just going to be replaced by builder."

At Anthropic, everyone on the Claude Code team already codes — the product manager, the engineering manager, the designer, the finance person, the data scientist. The boundaries between product, engineering, and design are, in Boris's word, getting "murkier." He described a future where "everyone's going to be a product manager and everyone codes."

This isn't theoretical. One of the most effective engineers on the team has been writing a production service in Go for a month and — by their own admission — still doesn't really know Go. The code works. It's correct. It's efficient. The fact that the human can't manually write the language is becoming irrelevant. The model handles the syntax. The human provides the intent.

Boris himself noticed a generational shift on his own team. When a memory leak appeared in Claude Code — a classic engineering problem that every senior developer has debugged a thousand times — he instinctively reached for traditional debugging tools. Heap snapshots. Specialised debuggers. Trace analysis. A newer engineer simply asked Claude Code to figure it out. Claude took the heap snapshot, wrote a custom analysis tool for itself on the fly, found the issue, and put up a pull request. Faster than Boris doing it the old way.

This is not a failure of experience. It's a feature of context. The newer engineers have never known a world where you debug by hand if a model can do it for you. They treat AI delegation as the default, not the exception. The veterans — the people who spent a decade building intuition about stack traces and memory profiling — have to actively override twenty years of habit to reach for the AI first. The newer engineers are more "AGI-forward" than the veterans. They don't carry the muscle memory of manual problem-solving. They default to delegation. And they're outperforming the people who built the tools they're delegating to.

Lenny Rachitsky's informal Twitter polls told a related story: 70% of engineers and product managers said they enjoy their jobs more since adopting AI tools. Only 10% said less. Designers were more mixed — 55% more, 20% less. The profession is splitting into people who are energised by what's happening and people who feel the ground shifting under them.

What Actually Matters Now

If coding is solved, then the bottleneck has moved. Boris identified the new frontier with precision:

Deciding what to build. Claude Code is already starting to come up with its own ideas. It reads feedback channels, parses bug reports, analyses telemetry, and suggests fixes. It puts up PRs proactively. Boris describes it as behaving "a little more like a co-worker." Today it's suggesting bug fixes. Tomorrow it's prioritising the backlog. The product management layer — deciding what matters, what to build next, what to ignore — is the next domain that AI will consume.

Speed of execution. Boris's core operating principle: if you can do something today, do it today. The Claude Code team deliberately underfunds projects — one engineer per project — because scarcity forces people to delegate more to AI and ship faster. This isn't a cost-cutting play. It's a design philosophy. Underfunding produces better outcomes because it forces maximum use of AI tooling. A solo engineer with unlimited tokens will outship a team of five using traditional methods.

Generalism over specialism. Boris was explicit: the people who will be rewarded most over the next few years won't just be AI-native. They'll be curious generalists who cross disciplines — engineers with design sense, product thinkers who can code, business minds who can read telemetry. "Some of the strongest engineers are hybrid product and infrastructure engineers, or product engineers with really great design sense." The era of the pure specialist, the person who only knows React or only writes Python, is ending.

Taste and judgment. With Co-work — Anthropic's agent product for non-technical tasks — Boris has it managing his entire team's project workflow. Every Monday, Co-work messages each engineer on Slack who hasn't filled out their weekly status. It paid a parking ticket. It cancelled subscriptions. It responds to his emails. The capability barrier is gone. What remains is knowing what's worth doing — and that requires judgment that hasn't been automated yet.

The Bitter Lesson Applied

Boris referenced Rich Sutton's famous 2019 essay, The Bitter Lesson, as a core operating principle for the Claude Code team. The idea is simple and brutally honest: the more general approach always wins over the more specific one. In practical terms for anyone building on AI today:

Don't box the model in. Strict workflows — step 1, then step 2, then step 3 — with sophisticated orchestrators consistently underperform giving the model tools, a goal, and letting it figure out the path. Adding scaffolding might improve performance 10-20%, but those gains get wiped out by the next model release. You spent three months building guardrails that the March model doesn't need.

Use the most capable model available. Boris uses Opus 4.6 with maximum effort enabled, always. Less capable models seem cheaper but actually consume more tokens to achieve the same result because they need more correction and more handholding. The most expensive model is often the cheapest path to the answer. This is counter-intuitive for anyone who grew up optimising AWS bills, but the economics of intelligence are different from the economics of compute.

Build for the model six months from now. Early Claude Code barely wrote 20% of Boris's code. He built for a future where the model would be far more capable. That bet paid off with Opus 4, when usage went exponential. His advice to startups: accept that product-market fit will be poor for six months if you're building for the next model. When that model ships, you'll hit the ground running while your competitors are still retrofitting. The companies that built for Sonnet 3.5's limitations are now scrambling to rebuild for Opus 4.6's capabilities. The companies that assumed Opus 4.6 was coming built architecture that simply worked when it arrived. This is the difference between reacting to the future and designing for it.

This is perhaps the hardest advice for traditional engineering organisations to absorb. The entire history of software engineering has been about controlling complexity through abstraction, architecture, and process. The bitter lesson says: stop trying to be clever. Bet on the general model. Give it tools. Get out of the way.

The Uncomfortable Truth About What Comes Next

Whenever the "are jobs going away" question arises in AI discussions, someone invokes Jevons' paradox — the historical observation that making a resource more efficient tends to increase total consumption, not decrease it. Coal got more efficient; we used more coal. Software got cheaper to write; we needed more software.

Boris was measured but honest. Anthropic is hiring. The Claude Code team is hiring. He personally enjoys coding more than ever because the tedious parts are gone. Most engineers report the same.

But he also said this: "I do think in the meantime, it's going to be very destabilising and it's going to be painful for a lot of people."

He specifically noted that adjacent roles — product managers, designers, data scientists — are next on the automation curve. Co-work is the first product bringing agentic AI to non-technical knowledge workers. For many people, it will be their first experience with an AI that doesn't just talk but actually acts: uses Gmail, sends Slack messages, fills out forms, browses the web, pays fines, manages projects.

At a personal level, Boris admitted that some engineers at Anthropic are spending hundreds of thousands of dollars per month in tokens. The cost of an engineer is starting to look less like salary plus benefits and more like salary plus benefits plus a six-figure AI compute bill. The companies that figure out this new economics first will have an enormous advantage. The ones that ration tokens to "control costs" will fall behind.

One year ago, nobody really used coding agents. The word "agent" was mostly marketing nonsense. Today, the head of the most successful coding agent on earth says coding is solved, predicts the software engineer title will disappear by year's end, and runs five parallel AI sessions before his morning coffee. He codes from his phone on the iOS app while travelling.

This is the pace now. Not the peak pace. The starting pace.

And for the engineering leaders still running annual planning cycles and quarterly OKRs around headcount growth — the question isn't whether AI will change your team structure. It's whether you'll be the one deciding how, or whether the decision will be made for you by a competitor who figured it out six months earlier. Boris's team runs lean by design. They underfund deliberately. They hire generalists who can cross disciplines. If that sounds uncomfortable, it should. The comfortable path leads to the same place the scribes ended up.

What the Scribes Can Teach Us

The scribe who was excited about the printing press had the right instinct. The tedious work — the copying, the manual reproduction, the endless transcription — deserved to be automated. What survived was taste, judgment, artistic sensibility, and the ability to see what needed to exist before it existed.

Boris ended the interview with his post-AGI plan: making miso in rural Japan. Miso teaches you to think on long timescales — three months for white, two to four years for red. You mix it up and then you wait. You exercise patience. You develop taste. It's the opposite of shipping 30 PRs a day, and perhaps that's exactly the point.

In a world where code can be generated at the speed of thought, the scarce resource is not the code. It's knowing what to build, for whom, and why. It's the ability to hold a vision over years, not just sprints. It's judgment that no model can yet replicate — though Boris would be the first to tell you that window is closing too.

The scribes who adapted became editors, publishers, and artists. The ones who insisted they were irreplaceable became footnotes.

Choose wisely. The printing press is already running.

Explore Topics

Icon

0%

Explore Topics

Icon

0%