This is a column about AI. My fiancé works at Anthropic. See my full ethics disclosure here.

In the first two episodes of Platformer’s mini-series on AI and jobs, we heard from two tech leaders who pushed back on the idea that AI is about to leave most white-collar jobs worthless. Box CEO Aaron Levie argued that the “last mile” of human labor will resist efforts to automate it. And Google’s senior vice president of technology and society, James Manyika, explained how tech has improved at automating tasks but not jobs.

For our third episode, I wanted to highlight a contrasting view — someone who believes that AI really is on its way toward eliminating certain jobs. Boris Cherny is the creator and head of Claude Code — the agentic coding tool that Anthropic released last year and is, by most measures, the fastest-growing AI coding tool in the world. 

Cherny belongs firmly to the camp that believes the end of software engineering as we know it is already underway. He hasn't written a line of code himself in more than six months, and he says that for the kind of work he does, coding is effectively "solved."

Given that he is, by his own account, actively automating his own job, it's no surprise that Cherny sees the disruption arriving far faster than our first two guests. He told me that the title "software engineer" could start to disappear by the end of this year, dissolving into something closer to something like "builder" as the designers, product managers, and managers around him start shipping code of their own.

But his own jobs forecast is more optimistic — and in some ways similar to our first guests — than some of his more prominent comments about coding being “solved” might suggest. While companies may hire fewer engineers as we know them today, he argues, they’ll hire more of whatever “builder” role replaces them. 

"I don't think we're going to call them engineers," Cherny told me. "But if we talk about people writing code, or using agents to write code, I think there will be 100 times more engineers than there are today. That's my prediction."

Cherny was an unlikely candidate to lead a revolution in coding. He studied economics, dropped out of college to run a startup at 18, did a stint at a hedge fund, and spent five years as a principal engineer at Meta before arriving at Anthropic in September 2024. When he arrived, Cherny began to explore what the company's API could do. The product that became Claude Code began life as a tool to tell him what song he was currently listening to. After iterating it on a couple months, he released the first version of Claude Code internally — and 20 percent of Anthropic’s engineers began using it on the first day.

As always, note that my fiancé works at Anthropic. But I couldn’t imagine trying to understand the AI and jobs story in this moment without talking to the person behind Claude Code.

Highlights of our conversation are below, edited for clarity and length. Listen to the entire conversation wherever you get your podcasts — just search for Platformer — or watch it on YouTube at youtube.com/caseynewton.

And let us know what you think — we're new to podcast production, and welcome your feedback at casey@platformer.news.

Casey Newton: You joined Anthropic in September 2024, and my understanding is that no one told you to go build a coding product — you were just trying to learn the API. Can you tell us the origin story of Claude Code? I've read that it controlled your music.

Boris Cherny: All of these things are true. I joined this team called the Labs team, which built a bunch of cool stuff. We built Claude Code — I built that. A different person built MCP, someone built Skills, and two other people built the desktop app. That was essentially the size of the team. It was tiny. We built these features over the course of a few months, and because a lot of them were weird ideas, we had no idea whether they were going to work.

For a while, Anthropic's focus has been on the same kinds of things: enterprise, coding, and safety. We knew that somewhere in this journey we should probably build some kind of product. Early on, Anthropic didn't actually know if it wanted to build products at all, but if we were going to, it needed to be coding-related, because that helps us build better coding models and it helps us study safety. 

We didn't know what it should be, though. At the time, the coding products out there were all IDEs or IDE extensions, because the capability of the model — this was Sonnet 3.5 — was not very good yet. The best it could do was fancy autocomplete: you'd write a little code and it would complete the line. We had this feeling that there was a product overhang — this idea that you could build a product that does something the model is totally capable of doing, but no one has built the product that lets the model do it. And I'll tell you, it's still the same feeling today. The model can do all these things, and there's no product that lets it.

So I wanted to learn how to use the Anthropic API, and I built the cheapest possible thing — a little thing that ran in the terminal, so I didn't have to build a user interface or an app. I built it in a couple of days and started giving it to people to see whether they'd use it and how, just out of curiosity. Over the next few weeks, more and more people at Anthropic started using it. First it was the people who literally sat around me, then the next layer of the onion, and a few weeks in, a lot of Anthropic was using it every day. It was weird, because it was a little prototype in the terminal — the most "engineering" product possible. A lot of engineers don't want to touch a terminal, but they did, and they used it.

Newton: I've read that within five days of the initial release, half the engineering team was already using it. As that was happening, did you have a moment of thinking, "Okay, software engineering just changed forever"? Or were you still just iterating on the product?

Cherny: I was so focused on shipping. As soon as I got the idea, I spent every night and every weekend on it — it was the only thing I thought about, the only thing I worked on. I started having dreams about Claude Code, and that's still all I dream about: what should we do next, what do we build next. There's a chance now to zoom out, because a lot of people are using it and there's a lot to learn about how. But for a long time we were so focused on building that I didn't even have a chance to think about what it was.

Newton: Was there a moment when you did zoom out? It might be too minimizing to say you stumbled across it, but it does seem like there was a sense of accidental discovery. Was there a moment of "Oh gosh, this is different from the other things I've hacked on"?

Cherny: There was a lot of surprise. Broadly, we knew we wanted to build a coding product, but no one thought it would be in a terminal. The first moment was when Claude told me what music I was listening to. There were a couple of versions of this — we actually have a video demo I recorded, which we just donated to a computer museum— it's a weird historical artifact. I remember posting it in my Slack and getting two reactions, because no one understood that this would be it. I asked Claude what music I was listening to, and it wrote a little code to open my music player. It wrote the code in AppleScript, which I don't know, and I wouldn't have thought to write code to answer that question. It just did it, and I thought, this is surprising — it solved the problem in a way I wouldn't have as an engineer. 

Over the last year and a half there have been so many moments like that. I had one with Cowork recently. Every time we release a new model, I experiment with it to see the frontier of what it can do, because one of the hardest things about building on a model is that it's advancing so fast — you have to recalibrate every month, as I'm sure you know. I used Cowork to book a bunch of flights. Usually it works okay; this time it worked perfectly. Now, any time I travel, I use Cowork to book it. It booked eight flights and five hotels. The only mistake was that one of the hotels was way over budget — I think it was like $5,000 a night.

Newton: Cowork wants you to have a great time when you go on your stay.

Cherny: I said, "Please rebook this one." But otherwise it just worked for a couple of hours and did all of it. It was so cool. I feel that surprise every week, every month.

Newton: This feels like a moment to zoom out from the story of an initial discovery that spreads rapidly through Anthropic, and now Claude Code has become a default tool for a growing number of engineers. It's one of the products making the question of job automation feel really salient — at least for software engineers, but maybe for more people than that. During our first episode, Aaron Levie told me he didn't see jobs going anywhere — that there's always going to be a last mile of human work the software can't do. You have publicly predicted that the title "software engineer" could start to go away as soon as this year. So is Aaron wrong about this?

Cherny: There's a bunch of stuff that's true, and a bunch we don't know. The trends are exponential, and exponentials are very hard to think in. Honestly, anyone saying they know is guessing — some of these are educated guesses based on what we're seeing and on history. 

I think a few things are going to happen. One is that a lot of companies will need fewer engineers, because each engineer is more productive, so you don't need as many to do the same work. At the same time, a lot of companies will need many more engineers, because every engineer is more productive — the company can do more things, start more products, create more businesses. You see this with our team: we are constantly bottlenecked on good engineers. We're hiring as quickly as we can, and a lot of our customers are exactly the same. So I think both things will happen, and it depends on the company and the business.

There's another thing happening, where the roles are all blending together in an interesting way I don't think anyone would have predicted. Our manager, Fiona, hadn't coded in 15 years; she joined Claude Code and now she's coding. Kat, our product manager, codes. Megan, our designer, codes. Everyone on the team codes — you don't have to be an engineer anymore. If you project the trend a little, everyone who's not an engineer is going to code a little more, and engineers like me are going to code less. I haven't written a line of code in over six months; I'm building stuff all day. I see it all blending into one thing. Call it a builder, call it an engineer, call it a product manager — I don't know what the title is, but the role is changing.

Newton: So how we conceive of these roles is definitely going to change, but what that means for how many jobs are available at which companies is still unclear.

Cherny: Yeah, and history has a lot of examples. The tractor was invented in the 1890s — I was just reading about this. A guy named John Froelich invented it in Iowa. At the time, farm work was all horse-powered; you needed horses. Even though the tractor was invented in the 1890s, it wasn't until the '60s in the US that there were more tractors than horses. It took about 70 years. The number of tractors went up, the number of horses went down, and the lines crossed in the '60s. 

There were a bunch of reasons. The technology was magical — you could harvest a lot more crops, productivity was much higher — but if you were a farmer who wanted to learn to use a tractor, it took training. At the beginning, tractors were expensive, so in a lot of cases horses were still cheaper. And the tractors weren't very good at first: maybe you could use one for wheat but not for corn, so it took a long time for someone to make a tractor that worked for corn, and for okra, and for all the other things. That just took a while. What we're seeing right now is the same thing on a speed run — but we're seeing very similar issues.

Newton: This is the "AI as normal technology" argument: even as labs come up with incredibly capable models, people are slow to change, organizations are slow to change, and it takes time for these technologies to filter through companies. At the same time, people look at what's been reported about Anthropic's revenue and say — it doesn't seem like it's taking that long this time. So we're still trying to hone in on the actual rate of change.

Cherny: Here's a question for you: do computers make you more productive?

Newton: Yes. But "do they make me more productive" feels like a different question from "do I work less because of computers," if that makes sense.

Cherny: So because you can do more, you do more — you fit more into the same eight hours.

Newton: Absolutely. To be candid, I used to record one podcast episode a week in addition to writing a couple of newsletters. During this miniseries I'm experimenting with doing a couple of podcasts a week in addition to writing multiple newsletters, and AI is a reason I can do that. It's an incredible research assistant and podcast producer. I'm able to produce more. But I don't feel like I'm working less — and that's not a complaint, just how I'm navigating this moment.

Cherny: I feel the same way. I can do so much more — all this stuff I didn't get to before, because I didn't have enough hours in the day. There's another weird historical thing. In the '90s, when companies were adopting the personal computer — after the mainframe, after these big industrial computers that cost millions — they got miniaturized, so the average startup could just get computers. And there was a real question of whether computers made you more productive. People were complaining that they didn't. Now we look back and think, of course they do — I can't imagine going back to filing and paper. 

There's an awesome Harvard Business Review article from 1990, and the case it made was this: they studied companies adopting computers and found that some were getting more productive and some weren't. The difference was that the companies getting more productive were the ones that threw away all their paper — the filing cabinets, the pens, the desk drawers — and put a computer at the center of everything. The other companies still had teams writing everything by hand, with a computer in the corner used for one thing. The first category had big productivity gains; the second didn't.

It's similar right now. At Anthropic, we organize everything around Claude. When people join, if they have questions about how to write code or contribute to a codebase, the answer is: ask Claude. If the question is how to file an expense receipt, ask Claude. If it's when the next company holiday is, ask Claude. All this stuff you used to do manually, Claude is at the center of. The companies that are really getting it put Claude right at the center — not on the outskirts somewhere. You have to change all the business processes, and that takes time.

Newton: I've been reading about the Solow paradox, which is basically what you just described. It's an observation by an economist in the '80s that you could “see the computer age everywhere except in the productivity statistics.” Despite a very large build-out of computers, you weren't seeing people get much more productive. Eventually the gains did materialize, because companies reinvented their workflows around the new technology. So the question now is how quickly the economy can do that.

I want to ask a couple more fine-grained questions about software engineering, because I've heard you say coding is effectively solved and that you haven't written code in six months. Engineers push back on this, saying coding isn't only about typing — it's about judgment and taste and critical thinking, and agents can still be quite bad at those. What do you make of that critique? Are there parts of coding that remain unsolved?

Cherny: The critique is totally right. This is one of those things that gets taken out of context. The full quote is: coding is solved fo