This weekend I swapped my usual tech reading for Lenny’s podcast episode with Boris Cherny, head of Claude Code at Anthropic. AI is continuously reshaping how software engineers work — the tooling, the workflows, the expectations. And while that brings genuine excitement, the pace and the pressure to deliver more are increasing too. I was curious to hear Boris’s take on these dynamics, especially from someone leading the development of Claude Code, the AI coding agent whose adoption is growing fast.
I collected a few ideas from the episode titled “Head of Claude Code: What happens after coding is solved | Boris Cherny” — and added some of my own thoughts as a senior engineer with two decades in the field.
“Coding is largely solved” — what does that actually mean?
Boris said it plainly: “At least for the kind of programming that I do, it’s a solved problem because Claude can do it.” He ships 10 to 30 pull requests daily, all written by Claude Code. He has not edited a single line by hand since November 2025.
At Anthropic, productivity per engineer has increased 200% since Claude Code was introduced (concerning the number of PRs per engineer). Four percent of all GitHub commits worldwide are now authored by Claude Code, and Semi Analysis predicts that number will reach 20% by year-end. Even if these numbers are directionally wrong, the overall trend is hard to ignore.
These are striking numbers. But “coding is solved” does not mean “software engineering is solved.” There is an important distinction, and I think it is where the real opportunity lies.
The shift: from writing code to building systems
What Boris described about his daily work resonated with me. He spends his time thinking about systems, talking to users, reviewing feedback, designing what to build next. The tedious parts — dependency issues, boilerplate, git gymnastics — are handled by the agent. The parts that require judgment, context, and domain knowledge remain human.
He drew a parallel to medieval scribes reacting to the printing press. One scribe from the 1400s was actually excited — copying between books was the part he disliked. The art, the binding, the craft work — that stayed. The mechanical reproduction went away.
As someone who has spent 20 years shipping software, I see a similar pattern. The mechanical act of translating intent into syntax is being automated. What remains — and what becomes more valuable — is the architect’s role: understanding the problem, designing the right solution, assuring quality, and delivering value. The job title might still say “engineer,” but the work is increasingly about building and less about coding.
This applies mainly to high-level application development. In low-level, safety-critical, or highly regulated systems, manual reasoning and deep implementation knowledge remain central. AI helps, but does not replace that work.
This is not a loss. It is a shift in emphasis toward the parts of the job that most experienced engineers already consider the most important.
Practical advice from the podcast
Boris shared several concrete tips that I found worth noting:
Use the most capable model. He runs Opus 4.6 with maximum effort enabled at all times. His reasoning: less capable models look cheaper upfront but often consume more tokens because they need more correction. The best model frequently costs less per completed task. This matches my own experience — cutting corners on model capability tends to cost more in rework.
Start with a plan. Eighty percent of his tasks begin in plan mode. The model explores the problem and proposes an approach before writing any code. Once the plan is right, the implementation is usually correct on the first pass. This is the same discipline good engineers have always applied — think before you code. The tooling just makes it more explicit.
Be a generalist. The engineers who thrive on his team cross disciplines. Product engineers with design sense. Infrastructure engineers who understand the business. Engineers who talk to users directly. On the Claude Code team, everyone codes — the PM, the engineering manager, the designer, the finance lead, the data scientist. The boundaries between roles are blurring.
What this means for experienced engineers
There was one anecdote that stuck with me. Boris was debugging a memory leak the traditional way — heap snapshots, specialized debuggers, tracing allocations. A newer engineer on the team simply asked Claude Code to investigate. The agent took the snapshot, wrote its own analysis tool, found the issue, and submitted a fix — faster than Boris could do it manually.
The takeaway is not that experience is obsolete. Boris himself pointed out what made the difference: the newer engineer instinctively delegated to the AI, while he defaulted to the manual approach out of habit. The skill that mattered was not knowing how to take a heap snapshot. It was recognizing what a memory leak is, knowing it matters, and being able to evaluate whether the fix is correct and safe.
For engineers with deep experience, this is a favorable shift. Our understanding of systems, our ability to evaluate quality, our judgment about trade-offs — these are the exact capabilities that become more important when the coding itself is delegated.
Teams: speed and constraint as advantages
Boris described an approach at Anthropic that is counterintuitive: underfund projects slightly. Put one engineer on a problem instead of three. When someone is resource-constrained but has access to AI tools, they figure out how to leverage them. The intrinsic motivation to ship, combined with AI assistance, produces results that larger teams often cannot match.
The other side of this: give engineers unlimited tokens. Do not optimize costs upfront. The token cost for an individual experimenting is low relative to their salary. Premature cost optimization kills the exploratory work that produces the best results.
From my own experience leading teams, I see the logic. The best outcomes I have seen came from small, focused teams with clear ownership — not from throwing more people at a problem. AI amplifies that pattern.
What is coming next
The frontier is moving past code generation. Claude Code is already scanning feedback channels, reviewing bug reports, analyzing telemetry, and proposing its own fixes. It puts up pull requests and asks for review.
This trajectory suggests that the role of the engineer will continue shifting toward architecture, quality assurance, and system design. The coding part will become increasingly automated. The building part — deciding what to make, why, and how it fits together — will remain human for the foreseeable future.
My take
After more than 20 years of writing code, I do not see this as a threat to the profession.
I see it as the profession shifting. The most valuable things I do today are not the lines of code I write, but how quickly and reliably I can turn good decisions into working systems in production.
If “coding is largely solved,” then what remains is the harder, still interesting work: understanding problems deeply, designing robust systems, assuring quality, and delivering real value. The tools are changing. The job description is changing. But the core skill — building things that work for real users — is more relevant than ever.
In my opinion, the shift from coding to building is not something to fear.
It is something to prepare for. And for engineers who have spent years
developing judgment and systems thinking, it is an advantage.
Curious to hear what you think. Here’s the podcast that got me thinking.