I was told in 2002 that code automation would replace me by 2004. Twenty-three years later, I think someone finally made good on the threat; just not in the way any of us expected.

Boris Cherny, head of Claude Code at Anthropic, recently sat down with Lenny Rachitsky and said something that would have gotten him laughed out of any conference room five years ago: "Coding is largely solved." He hasn't edited a single line of code by hand since November 2025. He ships 10 to 30 pull requests a day. All written by Claude Code.

BLUF. The transition from "AI assists with code" to "AI writes all the code" happened faster than anyone outside the AI labs predicted. The implications extend well beyond engineering, and authors building software tools should pay attention.

What caught my attention wasn't the current state. It was the rate of change. Boris described how Sonnet 3.5 could run maybe 15 to 30 seconds before going off the rails. Opus 4.6 runs unattended for 10 to 30 minutes, sometimes hours or days. Claude Code now authors 4% of all public GitHub commits, and Anthropic believes the private repository number is significantly higher. Their daily active users doubled in just the past month.

I spent 35 years in the federal space watching technology adoption curves. They usually look like a logistics S-curve: slow adoption, inflection, plateau. What Boris described is an exponential that hasn't found its inflection point yet. That's a different animal entirely.

For context, when Boris joined Anthropic, they grew their engineering team roughly 4x. Engineering productivity per person increased 200%. In my old world of IT project management, a few percentage points of productivity gain per year was considered a win worth celebrating. Hundreds of percentage points is not an incremental improvement. It is a phase change.

Boris reached for the printing press as his historical analog, and I think it's the right one. Before Gutenberg, sub-one percent of Europe was literate. Scribes did all the reading and writing. Within 50 years of the press, more material was printed than in the previous thousand years. Over the next 200 years, literacy climbed to 70% globally.

The parallel to programming is direct. A small priesthood of specialists has controlled the ability to make computers do things for about 60 years. That monopoly is ending. Not because programmers are being replaced, but because the barrier to entry just collapsed.

He told a story about a scribe from the 1400s who was actually excited about the press. The scribe hated copying between books. What he loved was the art — the illustration, the bookbinding. The press freed him to do more of what mattered. Boris said he feels the same way about engineering. The tedious parts — dependency management, git operations, configuration — those were never the point. The point was figuring out what to build and whether it serves the user.

As someone who spent years wrestling with Ruby gems and Rails migrations, I felt that in my bones.

This is where it gets interesting for someone in my position. I'm transitioning from a technical career to full-time authorship while still building tools like Verkilo.

Boris's team built Co-work, their non-coding agent product, in 10 days. Using Claude Code. The product ships a full virtual machine with security sandboxing. It was immediately more popular than Claude Code was at its own launch. Why? Because people had been abusing Claude Code for non-technical tasks — analyzing genomes, recovering wedding photos from corrupted drives, growing tomato plants — all through a terminal. The demand was latent. They just had to build the front door.

The principle Boris kept returning to was "latent demand." Watch what people are trying to do with your product that you never designed it for. That's your roadmap. He compared it to Facebook Marketplace emerging from the observation that 40% of Facebook Group posts were people buying and selling things.

For those of us building software as a means to an end — not as the end itself — this changes the calculus. The question is no longer "can I build this?" The question is "should I build this, and what problem does it actually solve?"

Two principles from the interview stuck with me as relevant beyond engineering.

First, the Bitter Lesson. Rich Sutton's idea that the more general model always outperforms the more specific one. Boris applied this to product development: don't over-engineer scaffolding around AI models. Don't build rigid step-by-step workflows. Give the model tools and a goal, then get out of the way. The scaffolding you build today gets wiped out by the next model release anyway.

Second, build for the model six months from now, not the model of today. Claude Code was not very useful when it launched. Boris was still using Cursor for most of his coding through mid-2025. But the product was designed with the assumption that models would get dramatically better, and when Opus 4 shipped, Claude Code's growth went vertical. The bet paid off because the architecture was ready when the capability arrived.

There's a Shape Up parallel here that I appreciate. In Basecamp's framework, you make a bet on a defined appetite and ship within the cycle. Boris is making a similar bet. Except the cycle is defined by model capability curves rather than calendar sprints. You place the bet, build the architecture, and wait for the model to catch up. Uncomfortable for the first six months. Then it clicks.

Boris predicted that by end of 2025, the title "software engineer" would start to be replaced by "builder." On his team, everyone codes;  the product manager, the engineering manager, the designer, the finance person, the data scientist. The most effective people cross disciplines. They're not specialists in one function. They're generalists who happen to be excellent at the thing they're building.

This tracks with what I've observed in my own career. The best project managers I worked with understood the technology. The best developers understood the business. The walls between these disciplines were always somewhat artificial. AI is just dissolving them faster.

His advice for anyone trying to stay ahead: experiment with the tools, be a generalist, don't be afraid. Use the best model available. Start in plan mode. Let the AI do the first pass, then review.

I spent the past 25 years as a developer or managing the people and processes around code. Now I'm building a writing application and trying to ship novels at scale. At every stage, the tools changed but the underlying work stayed the same: figure out what matters, build the thing, ship it, learn from the response.

The tools just got radically better. That's not a threat. It's an invitation.

-- 
Ben 
iu, kiun vi fidas, estas unu el ni