Boris Cherny on Claude Code's First Year and What Comes After Coding
Lenny's Podcast
Boris Cherny created Claude Code and leads it at Anthropic. He spoke with Lenny Rachitsky around the product's one-year anniversary. His central claim is blunt: for the kind of programming he does, coding is "virtually solved." He has not edited a line of code by hand since November. In his view, the interesting questions have moved elsewhere: what Claude should work on, how agentic AI spreads to non-engineering work, how products should be built around rapidly improving models, and how Anthropic studies the safety of agents running in the real world. He is openly optimistic about where this leads, but he also says the transition "is going to be painful for a lot of people."
Two weeks at Cursor, and why he came back
Lenny opened by asking about an episode few people remember. About six months before the recording, Cherny left Anthropic for Cursor and returned two weeks later. Cherny called it "the fastest job change that I've ever had." He joined Cursor because he was a big fan of the product and was impressed by the team. He said they saw where AI coding was going before many others did, and he still thinks they're awesome.
He said that once he got there, he quickly realized what he missed was Anthropic's mission. The mission had drawn him to Anthropic in the first place. After working in big tech, he wanted to work at a lab and help shape "this crazy thing that we're building." What attracted him to Anthropic specifically was its focus on safety. He said that if you stop anyone in the hallway and ask why they're there, the answer will always be safety. He described mission-drivenness as something he personally needs in order to be happy. However exciting the work is, even building a great product, it wasn't a substitute for that.
The scale of the past year
Lenny cited a SemiAnalysis report finding that 4% of public GitHub commits are now authored by Claude Code, with a projection that it will reach a fifth of all commits by year's end. He also mentioned a Spotify headline, published the day of recording, saying its best developers hadn't written a line of code since December. Cherny said the 4% figure was far more than he had imagined. Because it counts only public commits, he said Anthropic believes the share in private repositories is "quite a bit higher." What struck him most was not the current level but the pace: across any metric, he said, Claude Code's growth rate is still accelerating. Lenny's introduction also noted that daily active users had doubled in the past month.
Near the end of the conversation, Lenny brought up revenue figures he had seen: roughly $2 billion for Claude Code and about $15 billion for Anthropic overall. Cherny called Claude Code "a multi-billion dollar business" and said all his friends now text him about it. Even so, he described the moment as early. Most of the world still doesn't use Claude Code or AI at all, so to him it feels like "this is 1% done."
From a little hack to a terminal product
Cherny placed Claude Code's origin inside a longer Anthropic thesis. The company, he said, builds models along a trajectory: first very good at coding, then at tool use, then at computer use. The team he originally joined, Anthropic Labs, produced Claude Code, MCP, and the desktop app. He said Mike Krieger and Ben Mann had recently restarted that team for "round two." He tied the thesis to safety. As AI becomes more capable, it stops being only a conversation partner and starts acting in the world. For engineers, that shift happened over the last year. With Cowork, he sees non-technical users making the same transition, some of them using an AI that actually acts, for example in their Gmail or Slack, for the first time.
When he joined, Cherny spent a month building "weird prototypes," most of which never came close to shipping, to learn the boundaries of what the model could do. He then spent a month doing post-training work to understand the research side. His reasoning is that good engineering requires understanding "the layer under the layer" you work at. In traditional product work, that layer is the runtime, the language, or the virtual machine. In AI, it's the model.
The first version was called Claude CLI. His recorded demo showed it using a few tools. What shocked him was that after he gave it a bash tool and asked what music he was listening to, the model wrote code to find out. He hadn't instructed it how to use the tool for that purpose. When he announced the prototype internally, the post got two likes. He thinks people didn't believe a coding tool could be terminal-based, since coding tools meant sophisticated IDEs.
The terminal wasn't a grand design choice at first. For the first couple of months Cherny was the only person working on it, and the terminal was simply the easiest thing to build. He draws a product lesson from this: under-resource things a little at the start. Later, when the team considered other form factors, they deliberately stayed with the terminal. The model was improving so quickly that they couldn't think of another interface that could keep up. Cherny said that honestly, the terminal was the only idea he had during many late nights of worrying about it.
Internally it caught on fast. Ben Mann nudged him to make a daily-active-users chart before launch, and it "went vertical" almost immediately. The external release in February was a different story. Cherny stressed that Claude Code was not an immediate hit publicly. Early adopters got it right away, but it took many months for most people to understand what it was. He thinks the terminal made it feel "a little alien," so users had to be open-minded and learn it. Today it runs in the iOS and Android apps, the desktop app, the website, and integrations such as Slack and GitHub, which are more familiar places. He called the whole experience humbling: "none of us really know what we're doing," and user feedback is the best signal the team has.
Tracing the exponential
Cherny described how Anthropic thinks in exponentials. He noted that three of the co-founders were the first three authors of the scaling laws paper. At the Code with Claude developer conference in May 2025, someone asked for his end-of-year predictions. He said that by the end of the year you might not need an IDE to code. He recalled the room audibly gasping. He said all he had done was trace the line of how much code Claude was writing. If you followed it, the line crossed 100% by year's end, "even if it just does not match intuition at all."
His own numbers followed that curve. In February, Claude Code wrote maybe 20% of his code. In May, about 30%, and he still used Cursor for most of his work. It crossed 100% in November. He said that from the earliest days it felt like he was "onto something," though it wasn't clear what. He hacked on it every night and weekend and credited his wife's support. His view on innovation is that you can't force it and there's no roadmap. People need psychological safety to fail, since it's fine if 80% of ideas are bad. They also need to be held accountable enough to drop bad ideas and move on rather than keep investing in them.
What 100% AI-written code looks like in practice
Cherny said he was one of the most prolific engineers at Instagram and still is at Anthropic, even while leading the team. He ships about 10, 20, or 30 pull requests a day, all written by Claude Code. He still reads the code. He doesn't think anyone can be fully hands-off yet, especially when many people run the software, because correctness and safety still need to be verified. At Anthropic, Claude reviews 100% of pull requests, and there is a human review layer after that, except for pure prototype code that won't run anywhere.
He usually has several agents running. He said about five were running during the recording. That morning, the first thing he did was open the Claude iOS app to have an agent double-check code he had written the day before (it was correct). His coding is now split roughly into thirds between the terminal, the desktop app, and the iOS app. He hadn't expected to be coding that way in 2026. Asked about the anxiety some people feel when their agents are blocked and waiting, he said he hasn't really felt it, because he always has agents running.
The next frontier: Claude proposing the work
Asked what comes after AI writing all the code, Cherny gave two answers. First, Claude is starting to come up with ideas. It reads feedback, bug reports, and telemetry, then proposes bug fixes and things to ship, which makes it "a little more like a co-worker." Second, the work is branching out beyond coding. He said coding is "virtually solved" at least for the programming he does. He expects that over the next few months it will become increasingly solved across the industry, for every codebase and tech stack.
His method for idea generation is simple: point Claude Code or Cowork at a Slack thread. The team has an internal feedback channel for Claude Code that has been a "firehose" since the 2024 internal release. In the early days, Cherny fixed every piece of feedback as fast as he could, often within a minute or five. He believes that speed encouraged more feedback because people felt heard instead of sending comments into a black hole. Now Claude does much of that work. It reads the channel, lists what it can do, and has already put up a couple of PRs for him to review.
He said the model has improved a lot at this. Part of that comes from coding-specific training, and he praised Opus 4.6 as "incredible." He added that training outside coding also transfers. On productivity, he gave these figures: since Claude Code was introduced, Anthropic's engineering team has grown by maybe 4x (he said he didn't know the exact number), and productivity per engineer, measured in pull requests, is up 200%. He compared this to his earlier job at Meta, where he was responsible for code quality across Facebook, Instagram, WhatsApp, and other codebases. There, a year of work by hundreds of engineers might produce a gain of a few percentage points. Seeing gains of hundreds of percent, he said, is "absolutely insane."
Getting stuck in old habits
Cherny named one personal downside of the fast pace. The model changes so often that he sometimes gets stuck thinking the old way, and new hires and new grads sometimes work in a more "AGI-forward" way than he does. A couple of months earlier, Claude Code had a memory leak. He did the traditional thing: took a heap snapshot, loaded it into a debugger, and pored over traces. A newer engineer simply asked Claude Code to figure it out. Claude took the heap snapshot, wrote a small tool for itself to analyze it (a "just-in-time program," as Cherny put it), found the issue, and put up a PR faster than he could. His takeaway is that long-time users have to keep moving themselves into the present, because "it's not Sonnet 3.5 anymore."
Team principles: underfund, go faster, give out tokens
Lenny mentioned that Cherny walks new team members through a set of principles, including that it's better to have Claude do something than to do it yourself. Cherny described several related ideas.
The first is to underfund projects a little. When a single engineer is put on a project and wants to ship quickly (a motivation Cherny sees as coming from within), they're pushed to "Claudify" and automate as much as they can. He said the team sees this over and over.
The second is to encourage speed: if something can be done today, do it today. Early on, when he was the only person on the project, speed was the only way to compete in a crowded coding market. It remains a team principle, and having Claude do more is the obvious way to go faster.
The third, which he often shares with CTOs, is not to cost-cut at the start. Give engineers as many tokens as possible. Some companies now offer unlimited tokens as a perk, which he encourages, because it frees people to try ideas that would otherwise seem too crazy. Once an idea works and starts consuming a lot of tokens at scale, that's the time to optimize, perhaps by switching from Opus to Sonnet or Haiku. Anticipating the objection that an Anthropic employee would naturally want more token usage, he argued that an individual engineer experimenting costs relatively little compared with their salary. He also said some Anthropic engineers are already spending hundreds of thousands of dollars a month on tokens, and that some other companies are starting to see similar patterns.
Does coding still matter?
Cherny said he has never enjoyed coding as much as he does now, because he no longer has to deal with the minutiae. He explained this through his background. He studied economics and taught himself to program in middle school, and his motivation was practical from the start. His first program stored math-test answers on a TI-83 Plus. When the next year's tests were too hard to pre-load, he wrote a small algebra solver, shared it with the class over a cable, and the whole class got A's until the teacher caught them. He did later fall for the beauty of programming. He wrote a book on TypeScript, started what was then the world's largest TypeScript meetup, and went deep into functional programming and type systems. Even so, he says code has always been a tool for him, not the goal. He acknowledged that not everyone feels this way. One engineer on his team, Lena, still writes C++ by hand on weekends because she enjoys it, and he believes there will always be room for that craft.
He doesn't worry much about his own skills atrophying. He sees programming as a continuum: pen-and-paper calculation, hardware, switches, punch cards, and then software running on virtual machines since roughly the 1960s. For now, he said, understanding the layer beneath still helps, and he thinks that holds "maybe for the next year or so," but soon it "just won't really matter," much like the assembly code running underneath a program today. Lenny asked whether people should still learn to code. Cherny said people using agents today still need to understand the layer under, but "in a year or two it's not going to matter." Lenny mentioned Elon Musk asking why AI doesn't just write binary directly. Cherny said it could if you wanted it to.
He shared a family story. His grandfather was one of the first programmers in the Soviet Union and worked with punch cards. Cherny's mother remembered drawing on the stacks of cards with crayons as a child. His grandfather never saw the transition to software. Cherny suspects some programmers of that generation didn't take software seriously and would have said it "isn't really coding," the same way some people now dismiss describing intent to an agent. (During this part, the two discovered they were both born in Odessa. Cherny's family came to the U.S. in 1995 and Lenny's in 1988.)
The printing press analogy
To place the moment in history, Cherny reaches for the printing press. In mid-1400s Europe, he said, literacy was under 1%. Scribes did the reading and writing for lords and kings who were often illiterate themselves. According to the figures he cited, more printed material was produced in the 50 years after Gutenberg than in the previous thousand years, and costs fell by around 100x. Literacy rose more slowly, because it required education systems and free time. Over roughly 200 years it reached about 70% globally. He expects a comparable transition, in which a skill held by a small group becomes accessible to everyone.
He also described a historical interview with a 15th-century scribe who welcomed the printing press. The scribe said they disliked copying between books and preferred illustration and bookbinding. Cherny identified with this. For him, coding has always included tedious parts, like wrestling with git and tooling. The enjoyable parts are deciding what to build, talking to users, thinking about systems and the future, and collaborating. He now does more of those. He mentioned an engineer who had spent a month building a well-functioning Go service and admitted he still didn't really know Go. Cherny's view is that if you know the result works correctly and efficiently, you don't need to know every detail.
He extended the analogy optimistically. Without spreading literacy, he argued, the Renaissance couldn't have happened, and modern coordination, down to the microphones in the room, wouldn't exist. He imagines a future a few years out where everyone can program, and he admits no one can predict what that will unlock. He paired this with a warning: the interim "is going to be very disruptive," and society has to work out together how to handle it.
Which roles are next, and how to prepare
Cherny expects the roles adjacent to engineering, such as product management, design, and data science, to change next. Eventually, he thinks, it will reach almost any work done on a computer. He argued that "agent" has been overused to the point of losing meaning. Technically, it means an LLM that can use tools and act: edit Google Docs, send email, run commands. A year ago, he said, few engineers had used an agent. Now it's how engineering work is done. Most non-technical workers have only used chatbots, and he sees Cowork as their first contact with agents. He said Anthropic has economists, policy staff, and social impact staff working on the implications, and that these decisions "shouldn't be up to us."
His advice for individuals has two parts. First, experiment with the tools, don't be afraid of them, and stay at the frontier. Second, be more of a generalist than before. On the Claude Code team, everyone codes: the PM, the engineering manager, the designer, the finance person, the data scientist. The strongest engineers he works with cross disciplines. They combine product and infrastructure, bring design sense, understand the business, or love talking to users. He expects the people rewarded most to be AI-native as well as curious generalists who think about the whole problem.
Asked whether engineering, design, and product management will survive as separate roles, he said they will in the short term, but he already sees about 50% overlap, with specialties at the edges. For example, an engineer might code a bit more while the PM handles more coordination, planning, and forecasting. By the end of the year, he expects the lines to blur further. In some places, he said, the title "software engineer" will start to disappear, replaced by "builder," or everyone will be a product manager and everyone will code.
Lenny shared an informal Twitter poll. About 70% of engineers and PMs said they enjoy their jobs more since adopting AI tools, and about 10% said less. Among designers, 55% said more and 20% said less. Cherny said he would like to talk to people in both groups. He noted that at Anthropic, even non-technical hires go through technical interviews and designers mostly code. From what he has seen, designers there enjoy being able to unblock themselves instead of relying on engineers. He also said designers use the Claude desktop app's Code tab more than the terminal. It runs the same agent and lets them run many sessions in parallel, which the team calls "multi-Clauding." He bets experiences are not uniform across companies.
Latent demand, for users and for the model
Cherny called latent demand "the single most important principle in product." The idea is that if people can hack or misuse a product to do something it wasn't designed for, that tells you where to take the product next. He gave examples from Facebook. Fiona Fung, the founding manager of Marketplace, has talked about how the product began with the observation, around 2016 by Cherny's recollection, that 40% of posts in Facebook groups were about buying and selling. That led to buy-and-sell groups and then Marketplace. He said Facebook Dating came from a similar observation: 60% of profile views were between people who weren't friends and were of the opposite gender.
Cowork came from the same principle. For about six months, many people had been using Claude Code for non-coding tasks: growing tomato plants, analyzing their genome, recovering wedding photos from a corrupted hard drive, analyzing an MRI. People were "jumping through hoops to use a terminal," which signaled a product was needed. Cherny first noticed this in May of the previous year, when he found data scientist Brandon running Claude Code in a terminal. Brandon had installed Node.js and Claude Code and was doing SQL analysis there. The next week, all the data scientists were doing the same.
Cherny described a second, newer version of the principle: look at what the model is trying to do and make that easier. Many early LLM applications put the model "in a box" as one component with predetermined interactions. Claude Code inverted that approach. The product is the model, surrounded by minimal scaffolding and a minimal toolset, and the model decides which tools to use and in what order. In research terms, he said, this is being "on distribution."
How Cowork was built in 10 days
According to Cherny, Cowork was built in about 10 days, entirely with Claude Code. Unlike Claude Code's slow start, it was a hit almost immediately and is growing much faster than Claude Code did early on. He credited the team, naming Felix, Sam, and Jenny. The team spent a few months exploring options before someone suggested putting Claude Code into the desktop app, and that's what worked. Claude Code also wrote Cowork's safety guardrails, including a full virtual machine that ships with the product. The team's job was to make the agent safer and more self-guided for non-engineers. Cherny said it launched early and is still rough around the edges, which is deliberate: releasing earlier than feels comfortable is how the team learns what users want.
He described Claude Code's growth as coming in inflections rather than one smooth curve. Opus 4 was one, November was another, and growth has kept steepening since. Early on, many users didn't understand what it was for, and the model "still wasn't very good."
Three layers of safety, and the race to the top
Cherny explained that early release is also a safety practice, and he described three layers of safety work. The lowest is alignment and mechanistic interpretability: understanding what happens inside the model during training. He said Anthropic is getting close to being able to monitor something like a neuron associated with deception and see when it activates. The second layer is evals, which place the model in synthetic situations, "in a petri dish," to see whether it behaves correctly. The third is observing behavior in the wild, which he said matters more as models get more sophisticated, since a model can look good on the first two layers and not on the third.
Claude Code, which he described as the first broadly used coding agent, was used internally for about four or five months before release because the team wasn't sure it was safe. Lessons from real-world use have since been fed back into the model and the product. Cowork followed the same path: it looked good on alignment, on evals, internally, and with a few customers, so it was released as a "research preview" to learn how it behaves in the real world.
On interpretability, Cherny recommended that Lenny interview Chris Olah, whom he credited with founding the field. He said model neurons, while different from animal neurons, behave similarly in many ways. He said there is now "quite strong evidence" that models do more than predict the next token, including planning ahead. He also described superposition: a single neuron can correspond to a dozen concepts and represent more sophisticated concepts in combination with others. Anthropic publishes much of this research to encourage other labs, which Cherny called the "race to the top." As an example from Claude Code, the team released an open-source sandbox that restricts what an agent can access on your system and works with any agent, not just Claude Code.
Advice for building AI products
Cherny offered several principles. First, don't box the model in. Strict step-by-step workflows and elaborate orchestrators usually do worse than giving the model tools and a goal. A year ago the scaffolding was necessary, he said, but now it mostly isn't. Rather than stuffing context up front, give the model tools to gather the context it needs.
Second, he cited Rich Sutton's "The Bitter Lesson," which he described as holding that more general models eventually beat specialized ones, and which he said the Claude Code team treats as a reference. His corollary is to bet on the more general model where you have the flexibility: avoid tiny models and fine-tuning in most cases. In his experience, scaffolding might add 10–20% in performance, but the next model often wipes out those gains.
Third, build for the model six months from now. Claude Code's early versions barely wrote his code, because the Sonnet 3.5-era models weren't good enough. The bet was that they would become good enough. That happened with Opus 4 and Sonnet 4. Opus 4 was, in his words, Anthropic's first ASL-3-class model, released in May, and that's when Claude Code's growth went exponential. He warned startups that this approach means weak product-market fit for the first six months, but when the model arrives, "you're just going to hit the ground running."
Asked what to expect from future models, he admitted that working inside a lab is "a little unfair," but named two bets. Models will get better at using tools and computers, and they will run unattended for longer. With Sonnet 3.5 a year ago, a model might go 15 or 30 seconds before going off the rails. With Opus 4.6, he said, it typically runs 10 to 30 minutes unattended, sometimes hours or days. He said there are examples of runs lasting many weeks.
Practical tips for Claude Code and Cowork
Cherny said there is no single right way to use Claude Code. Developers differ, and Claude Code can recommend and edit its own settings. He offered three general tips. First, use the most capable model. For him that's Opus 4.6 with maximum effort always enabled. He argued that less capable models can end up using more tokens because they need more correction, so the cheaper model isn't necessarily cheaper. Second, use plan mode, which he uses to start about 80% of tasks. He explained that it simply injects a sentence telling the model not to write code yet. In the terminal it's Shift+Tab twice. The desktop app and web have a button, it has just launched in the Slack integration, and it's coming to mobile. Once the plan looks good, he auto-accepts edits, because Opus 4.6 usually gets it right on the first try. Third, try different interfaces. It's the same agent everywhere, so use whichever one feels right.
For Cowork, found in the desktop app next to the Code tab, he suggested starting with a single task, such as cleaning up your desktop or answering your top three emails. Next, connect tools. His project-management example: the team keeps a spreadsheet with a row per engineer for weekly status updates, and every Monday Cowork messages on Slack each engineer who hasn't filled theirs in. Finally, run many tasks in parallel. He also said Cowork has paid a parking ticket and a traffic fine for him and canceled subscriptions. Lenny mentioned it filling out medical forms for a colleague on parental leave. Cherny said this didn't work when the team tried it a year ago because the model wasn't ready, and that Cowork now feels much like Claude Code did a year ago. He also revealed that one of Anthropic's PMs evaluated Cowork before launch against Lenny's post on 50 non-technical uses of Claude Code. When Cowork could handle 48 of the 50, the team judged it good enough.
Competition, miso, and common sense
Asked about Codex, Cherny said he had barely used it. When he tried it around launch, it looked a lot like Claude Code, which he found flattering. He welcomes competition because users should have choices, but he said his team spends little time on competing products and focuses on user feedback.
Ben Mann had asked what Cherny plans to do after AGI. Before Anthropic, Cherny lived in rural Japan, where he was the only engineer and the only English speaker in town. Neighbors built friendships by trading homemade pickles and miso, and he became decently good at making miso. He values how it forces long time horizons: white miso takes at least three months, red miso two to four years. Post-AGI, or if he weren't at Anthropic, he said, he'd probably be making miso. He added that living by the seasons in Japan, while reading a lot of science fiction, is what convinced him he had to help AI go "a little bit better," and that Ben Mann was also a big part of his decision to join Anthropic.
In the lightning round, he recommended Functional Programming in Scala, the best technical book he has read. He acknowledged readers may never use Scala, but said it teaches the elegance of thinking in types. He also recommended Charles Stross's Accelerando, which he feels captures the accelerating pace of this moment, and Cixin Liu's short-story collection The Wandering Earth, which he prefers even to The Three-Body Problem. He rarely watches TV but enjoyed Netflix's 3 Body Problem. His favorite product is Cowork, especially its Chrome integration, and his favorite podcast is Acquired, starting with the Nintendo episode. His life motto is "use common sense." He said many workplace failures come from following a process or momentum without thinking, and the best results come from people reasoning from first principles. He started using X out of boredom during a December "coding vacation" in Europe. He began answering posts about Claude Code and asking for bugs, and people were surprised that he could often fix a well-described bug within minutes by handing it to Claude.
Cherny closed by returning to Anthropic's core thesis: start with coding, then tool use, then computer use. He said Claude Code's specific form, a terminal product that became a multi-billion-dollar business, was a total surprise, but the direction was not, because it had been the company's belief for a long time. What keeps the product improving, he said, is users telling the team what's broken and what they want. His request to listeners was to tag him on Threads or X with bugs, feature requests, and what's missing.
100% of my code is written by Claude Code. I have not edited a single line by hand since November. Every day I ship 10, 20, 30 pull requests. So, at the moment I have like five agents running.
While we're recording this?
Yeah, yeah, yeah. Do you miss writing code?
I have never enjoyed coding as much as I do today because I don't have to deal with all the minutiae. Productivity per engineer has increased 200%.
There's always this question, should I learn to code?
In a year or two it's not going to matter. Coding is virtually solved. I imagine a world where everyone is able to program. Anyone can just build software anytime.
What's the next big shift to how software is written?
Claude is starting to come up with ideas. Looking through feedback, it's looking at bug reports, it's looking at telemetry for bug fixes and things to ship. A little more like a co-worker or something like that.
A lot of people listening to this are product managers and they're probably sweating.
I think by the end of the year everyone's going to be a product manager and everyone codes. The title software engineer is going to start to go away. It's just going to be replaced by builder and it's going to be painful for a lot of people.
Today my guest is Boris Cherny, head of Claude Code at Anthropic. It is hard to describe the impact that Claude Code has had on the world. Around the time this episode comes out will be the one-year anniversary of Claude Code. And in that short time, it has completely transformed the job of a software engineer. And it is now starting to transform the jobs of many other functions in tech, which we talk about. Claude Code itself is also a massive driver of Anthropic's overall growth over the past year. They just raised a round at over $350 billion.
And as Boris mentions, the growth of Claude Code itself is still accelerating. Just in the past month their daily active users has doubled. Boris is also just a really interesting, thoughtful, deep-thinking human. And during this conversation we discovered we were born in the same city in Ukraine. That is so funny, I had no idea.
A huge thank you to Ben Mann, Jenny Wen, and Mike Krieger for suggesting topics for this conversation. Don't forget to check out lennysproductpass.com for an incredible set of deals available exclusively to Lenny's newsletter subscribers. Let's get into it after a short word from our wonderful sponsors.
Today's episode is brought to you by DX, the developer intelligence platform designed by leading researchers. To thrive in the AI era, organizations need to adapt quickly. But many organization leaders struggle to answer pressing questions like which tools are working? How are they being used? What's actually driving value? DX provides the data and insights that leaders need to navigate this shift. With DX, companies like Dropbox, Booking.com, Adyen, and Intercom get a deep understanding of how AI is providing value to their developers and what impact AI is having on engineering productivity. To learn more, visit DX's website at getdx.com/lenny. That's getdx.com/lenny.
Applications break in all kinds of ways. Crashes, slowdowns, regressions, and the stuff that you only see once real users show up. Sentry catches it all. See what happened, where, and why. Down to the commit that introduced the error, the developer who shipped it, and the exact line of code all in one connected view. I have definitely tried the five tabs and Slack thread approach to debugging. This is better. Sentry shows you how the request moved, what ran, what slowed down, and what users saw. Seer, Sentry's AI debugging agent, takes it from there. It uses all of that Sentry context to tell you the root cause, suggest a fix, and even opens a PR for you. It also reviews your PRs and flags any breaking changes with fixes ready to go. Try Sentry and Seer for free at sentry.io/lenny and use code Lenny for $100 in Sentry credits. That's sentry.io/lenny.
Boris, thank you so much for being here and to the podcast.
Yeah, thanks for having me on.
I want to start with a spicy question. About 6 months ago, I don't know if people even remember this, you actually left Anthropic, you joined Cursor, and then 2 weeks later you went back to Anthropic. What happened there? I don't think I've ever heard the actual story.
It's the fastest job change that I've ever had.
I joined Cursor because I'm a big fan of the product. And honestly, I met the team and I was just really impressed. They're an awesome team. I still think they're awesome, and they're just building really cool stuff. And kind of they saw where AI coding was going, I think, before a lot of people did. So the idea of building a good product was just very exciting for me.
I think as soon as I got there, what I started to realize is what I really missed about Anthropic was the mission. And that's actually what originally drew me to Anthropic, also. Cuz before I joined Anthropic, I was, you know, I was working in big tech, and then at some point I wanted to work at a lab to just help shape the future of this crazy thing that we're building in some way.
And the thing that drew me to Anthropic was the mission, and it was, you know, it's all about safety. And when you talk to people at Anthropic, just like find someone in the hallway, if you ask them why they're here, the answer is always going to be safety.
And so this kind of like mission drivenness just really, really resonated with me, and I just know personally it's something I need in order to be happy. And that's just the thing that I really missed. And I found that, you know, whatever the work might be, no matter how exciting, even if it's building a really cool product, it's just not really a substitute for that. So for me it was actually pretty obvious that I was missing that pretty quick.
Okay, so let me follow the thread of just coming back to Anthropic and the work you've done there. This podcast is going to come out around the year anniversary of launching Claude Code. So I want to spend a little time just reflecting on the impact that you've had. There's this report that recently came out that I'm sure you saw by SemiAnalysis that showed that 4% of all GitHub commits are authored by Claude Code now. And they predicted it'll be a fifth of all code commits on GitHub by the end of the year. The way they put it is, "While we blinked, AI consumed all software development."
The day that we're recording this, Spotify just put out this headline that their best developers haven't written a line of code since December thanks to AI. More and more of the most advanced senior engineers, including you, are sharing the fact that you don't write code anymore, that it's all AI-generated, and many aren't even looking at code anymore is how far we've gotten. In large part, thanks to this little project that you started and that your team has scaled over the past year. I'm curious just to hear your reflections on this past year and the impact that your work has had.
These numbers are just totally crazy, right? Like, 4% of all commits in the world is just way more than I imagined. And like you said, it still feels like the starting point. These are also just public commits. So, we actually think if you look at private repositories, it's quite a bit higher than that.
And I think the craziest thing for me isn't even the number that we're at right now, but the pace at which we're growing because if you look at Claude Code's growth rate kind of across any metric, it's continuing to accelerate. So, it's not just going up, it's going up faster and faster.
When I first started Claude Code, it was just going to be a — like it was just supposed to be a little hack. You know, we broadly knew at Anthropic that we wanted to ship some kind of coding product. And you know, for Anthropic for a long time, we were building the models in this way that kind of fit our mental model of the way that we build safe AGI, where the model starts by being really good at coding, then it gets really good at tool use, then it gets really good at computer use. Roughly, this is like the trajectory. And you know, we've been working on this for a long time.
And when you look at the team that I started on, it was called the Anthropic Labs team. And actually Mike Krieger and, you know, Ben Mann, they just kicked this team off again for kind of round two. The team built some pretty cool stuff. So, we built Claude Code, we built MCP, we built the desktop app. So, you can kind of see the seeds of this idea, you know, like it's coding, then it's tool use, then it's computer use.
And the reason this matters for Anthropic is because of safety. It's kind of again, just back to that. AI is getting more and more powerful. It's getting more and more capable. The thing that's happened in the last year is that at least for engineers, the AI doesn't just write the code. It's not just a conversation partner, but it actually uses tools. It acts in the world. And I think now with Cowork, we're starting to see the transition for non-technical folks also. For a lot of people that use conversational AI, this might be the first time that they're using the thing that actually acts. It can actually use your Gmail. It can use your Slack. It can do all these things for you, and it's quite good at it. And it's only going to get better from here.
So, I think for Anthropic for a long time, there was this feeling that we wanted to build something, but it wasn't obvious what. And so, when I joined Anthropic, I spent one month kind of hacking and, you know, built a bunch of like weird prototypes. Most of them didn't ship, and, you know, weren't even close to shipping. It was just kind of understanding the boundaries of what the model can do.
Then I spent a month doing post-training, so, to understand kind of the research side of it. And I think honestly, that's just for me as an engineer, I find that to do good work, you really have to understand the layer under the layer at which you work. And with traditional engineering work, you know, if you're working on a product, you want to understand the infrastructure, the runtime, the virtual machine, the language, kind of whatever that is, the system that you're building on. But, yeah, if you're working in AI, you just really have to understand the model to some degree to do good work.
So, I took a little detour to do that, and then I came back and just started prototyping what eventually became Claude Code. And the very first version of it — there's like a video recording of this somewhere cuz I recorded this demo and I posted it. It was called Claude CLI back then. And I just kind of showed off how it used a few tools. And the shocking thing for me was that I gave it a bash tool and it just was able to use that to write code to tell me what music I'm listening to when I asked it like what music am I listening to.
And this is the craziest thing, right? Cuz it's like I didn't instruct the model to say, you know, use this tool for this or kind of do whatever. The model was given this tool and it figured out how to use it to answer this question that I had that I wasn't even sure if I could answer: what music am I listening to?
And so I started prototyping this a little bit more. I made a post about it and I announced it internally and I got two likes. That's the... Those likes sent to the reaction at the time.
Cuz I think people internally, you know, like when you think of coding tools, you think of IDEs, you think about kind of all these pretty sophisticated environments. No one thought that this thing could be terminal based. That's sort of a weird way to design it and that wasn't really the intention.
But you know, from the start I built it in a terminal because, you know, for the first couple months it was just me. So, it was just the easiest way to build. And for me this is actually a pretty important product lesson, right? It's like you want to under-resource things a little bit at the start.
Then we started thinking about what other form factors we should build and we actually decided to stick with the terminal for a while. And the biggest reason was the model is improving so quickly. We thought that there wasn't really another form factor that could keep up with it. And honestly, this was just me kind of like struggling with kind of like what should we build, you know, like for the last year Claude Code has just been all I think about. And so just like late at night, this is just something I was thinking about like, okay, the model's continuing to improve. What do we do? How can we possibly keep up? And the terminal was honestly just the only idea that I had.
And yeah, it ended up catching on. After I released it, pretty quickly it became a hit at Anthropic and, you know, the daily active users just went vertical. And really early on, actually before I launched it, Ben Mann nudged me to make a DAU chart. And I was like, you know, it's like kind of early, maybe, you know, should we really do it right now? And he was like, yeah. And so the chart just went vertical pretty immediately. And then in February we released it externally.
Actually, something that people don't really remember is Claude Code was not initially a hit. When we released it, it got a bunch of users. There was a lot of early adopters that got it immediately. But it actually took many months for everyone to really understand what this thing is. Just again, it's like it's just so different. And when I think about it, kind of part of the reason Claude Code works is this idea of latent demand, where we bring the tool to where people are and it makes existing workflows a little bit easier. But also because it's in a terminal, it's like a little surprising. It's a little alien in this way. So you have to kind of be open-minded and you have to learn to use it.
And of course now, you know, Claude Code is available, you know, in the iOS and Android Claude app. It's available in the desktop app. It's available on the website. It's available as IDE extensions, in Slack and GitHub, you know, all these places where engineers are. It's a little more familiar. But that wasn't the starting point.
So yeah, I mean, at the beginning it was kind of a surprise that this thing was even useful. And you know, as the team grew, as the product grew, as it started to become more and more useful to people, just people around the world from, you know, small startups to the biggest FAANG companies started using it and they started giving feedback. And I think just reflecting back, it has been such a humbling experience cuz we just keep learning from our users and just the most exciting thing is like, you know, none of us really know what we're doing. And we're just trying to figure it out along with everyone else and the single best signal for that is just feedback from users. So that's just been the best. I've been surprised so many times.
It's incredible how fast something can change in today's world. You launched this a year ago, and it wasn't the first time people could use AI to code, but in a year, the entire profession of software engineering has dramatically changed. Like there's all these predictions, oh, 100% of code's going to be written by AI. Everyone's like, no, that's crazy. What are you talking about? And I was like, oh, of course, it's happening exactly as they said. It's just that things move so fast and change so fast now.
Yeah, it's really fast. Back at Code with Claude back in May, that was like our first, you know, like developer conference that we did as Anthropic. I did a short talk and in the Q&A after the talk, people were asking, what are your predictions for the end of the year? And my prediction back in May of 2025 was, by the end of the year, you might not need an IDE to code anymore. And we're going to start to see engineers not doing this. And I remember the room like
audibly gasped. It was such a crazy prediction. But I think at Anthropic, this is just the way we think about things, in exponentials. And this is very deep in the DNA. If you look at our co-founders, three of them were the first three authors on the scaling laws paper. So we really just think in exponentials.
And if you kind of look at the exponential of the percent of code that was written by Claude at that point, and if you just trace the line, it's pretty obvious we're going to cross 100% by the end of the year, even if it just does not match intuition at all. And so all I did was trace the line, and yeah, in November, that happened for me personally, and that's been the case since, and we're starting to see that for a lot of different customers, too.
I thought that was really interesting what you just shared there about kind of the journey. Is this kind of idea of just playing around and seeing what happens? This comes up with OpenClaw a lot, just like Peter was playing around, and just like a thing happened. And it feels like that's a central kind of ingredient to a lot of the biggest innovations in AI, is people just sitting around trying stuff, pushing the models further than most other people.
I mean, this is the thing about innovation, right? You can't force it. There's no roadmap for innovation. You just have to give people space. You have to give them, maybe the word is like safety. So, it's like psychological safety that it's okay to fail. It's okay if 80% of the ideas are bad. You also have to hold them accountable a bit. So, if the idea is bad, you cut your losses, move on to the next idea, instead of investing more.
In the early days of Claude Code, I had no idea that this thing would be useful at all. Cuz even in February when we started, it was writing maybe, I don't know, like 20% of my code, not more. And even in May, it was writing maybe 30%. I was still using Cursor for most of my code. And it only crossed 100% in November. So, it took a while, but even from the earliest day, it just felt like I was onto something, and I was just spending every night, every weekend hacking on this. And luckily, my wife was very supportive. But it just felt like I was onto something. It wasn't obvious what. And then sometimes you find a thread, you just have to pull on it.
So, at this point, 100% of your code is written by Claude Code. Is that kind of the current state of your coding?
Yeah, so 100% of my code is written by Claude Code. I'm a fairly prolific coder, and this has been the case even when I worked back at Instagram. I was one of the top few most productive engineers. And that's actually still the case here at Anthropic.
Wow, even as head of the team?
Yeah, yeah. I still do a lot of coding. And so every day I ship like 10, 20, 30 pull requests, something like that. Every day? Every day. Yeah.
Good god. 100% written by Claude Code. I have not edited a single line by hand since November. And yeah, that's been it.
I do look at the code. So, I don't think we're at the point now where you can be totally hands-off, especially when there's a lot of people running the program. You have to make sure that it's correct. You have to make sure it's safe and so on. And then we also have Claude doing automatic code review for everything. So, here at Anthropic, Claude reviews 100% of pull requests. There's still a layer of human review after it, but you still do want some of these checkpoints. You still want a human looking at the code, unless it's pure prototype code that's not going to run anywhere. It's just a prototype.
What's kind of the next frontier? So at this point, 100% of your code is being written by AI. This is clearly where everyone is going in software engineering. That felt like a crazy milestone. Now it's just like, of course. This is the world now. What's kind of the next big shift to how software is written that either your team's already operating in or you think will head towards?
I think something that's happening right now is Claude is starting to come up with ideas. So Claude is looking through feedback. It's looking at bug reports. It's looking at telemetry and things like this, and it's starting to come up with ideas for bug fixes and things to ship. So it's just starting to get a little more like a co-worker or something like that.
I think the second thing is we're starting to branch out of coding a little bit. So I think at this point it's safe to say that coding is virtually solved. At least for the kinds of programming that I do, it's just a solved problem because Claude can do it. And so now we're starting to think about, okay, what's next? What's beyond this? There's a lot of things that are kind of adjacent to coding, and I think this is going to be coming, but also just general tasks. I use Cowork every day now to do all sorts of things that are just not related to coding at all, and just to do it automatically. For example, I had to pay a parking ticket the other day. I just had Cowork do it. All of my project management for the team, Cowork does all of it. It's syncing stuff between spreadsheets and messaging people on Slack and email and all this kind of stuff.
So I think the frontier is something like this. And I don't think it's coding, because I think coding is pretty much solved, and over the next few months I think what we're going to see is just across the industry it's going to become increasingly solved for every kind of code base, every tech stack that people work on.
This idea of helping you come up with what to work on is so interesting. A lot of people listening to this are product managers, and they're probably sweating. How do you use Claude for this? Do you just talk to it? Is there anything clever you've come up with to help you use it to come up with what to build?
Honestly, the simplest thing is open Claude Code or Cowork and point it at a Slack thread. For us, we have this channel that's all the internal feedback about Claude Code. Since we first released it, even in 2024 internally, it's just been this firehose of feedback. And it's the best. In the early days, what I would do is anytime that someone sends feedback, I would just go in and I would fix every single thing as fast as I possibly could. So within a minute, within 5 minutes, or whatever. And this really fast feedback cycle encourages people to give more and more feedback. It's just so important cuz it makes them feel heard. Cuz usually when you use a product, you give feedback, it just goes into a black hole somewhere, and then you don't give feedback again. So if you make people feel heard, then they want to contribute and they want to help make the thing better.
And so now I kind of do the same thing, but Claude honestly does a lot of the work. So I point it at the channel and it's like, "Okay, here's a few things that I can do. I just put up a couple PRs. Want to take a look at that one?" I'm like, "Yeah."
Have you noticed that it is getting much better at this? Because this is kind of the holy grail. Right now it's like, "Cool, building solved." Code review became kind of the next bottleneck. All these PRs, who's going to review them all? The next big open question is just like, "Okay, now humans are necessary for figuring out what to build, what to prioritize." And you're saying that that's where Claude Code is starting to help you. Has it gotten a lot better with, say, Opus 4.6, or what's been the trajectory there?
Yeah, yeah, it's improved a lot. I think some of it is training that we do specific to coding. So, obviously, best coding model in the world, and it's getting better and better. 4.6 is just incredible. But also, actually, a lot of the training that we do outside of coding translates pretty well, too. So there is this kind of transfer where you teach the model to do X, and then it kind of gets better at Y.
And the gains have just been insane. At Anthropic over the last year, since we introduced Claude Code, we probably, I don't know the exact number, we probably 4x'd the engineering team or something like this. But productivity per engineer has increased 200% in terms of pull requests. And this number is just crazy for anyone that actually works in this space and works on dev productivity. Cuz in a previous life I was at Meta, and one of my responsibilities was code quality for the company. So all of our code bases were my responsibility, like Facebook, Instagram, WhatsApp, all this stuff. And a lot of that was about productivity, because if you make the code higher quality, then engineers are more productive. And things that we saw is, in a year with hundreds of engineers working on it, you would see a gain of a few percentage points of productivity, something like this. And so nowadays seeing these gains of just hundreds of percentage points is just absolutely insane.
What's also insane is just how normalized this has all been. We hear these numbers, like of course AI is doing this to us. It's just so unprecedented, the amount of change that is happening to software development, to building products, to just the world of tech. It's just so easy to get used to it, but it's important to recognize this is crazy.
This is something I have to remind myself once in a while. There's sort of a downside of this because the model changes so... or actually there's many kinds of downsides that we could talk about. But I think one of them on a personal level is the model changes so often that I sometimes get stuck in this old way of thinking about it. And I even find that new people on the team, or even new grads that join, do stuff in a more kind of AGI-forward way than I do.
So, sometimes, for example, I had this case a couple months ago where there was a memory leak. And so what this is is, Claude Code's memory usage is going up and at some point it crashes. This is a very common kind of engineering problem that every engineer has debugged a thousand times. And traditionally, the way that you do it is you take a heap snapshot, you put it into a special debugger, you kind of figure out what's going on. You use these special tools to see what's happening. And I was doing this, and I was kind of looking through these traces and trying to figure out what was going on. And the engineer that was newer on the team just had Claude Code do it. And it was like, "Hey Claude, it seems like there's a leak. Can you figure it out?" And so Claude Code did exactly the same thing that I was doing. It took the heap snapshot. It wrote a little tool for itself so it can kind of analyze it itself. It was sort of a just-in-time program. And it found the issue and put up a pull request faster than I could.
So, it's something where, for those of us that have been using the model for a long time, you still have to kind of transport yourself to the current moment and not get stuck back in an old model, because it's not Sonnet 3.5 anymore. The new models are just completely, completely different. And just this mindset shift is very different.
I hear you have these very specific principles that you've codified for your team, that when people join, you kind of walk them through them. I believe one of them is: what's better than doing something? Having Claude do it. And it feels like that's exactly what you described with this memory leak, is just like you almost forgot that principle of like, "Okay, let me see if Claude can solve this for me."
There's this interesting thing that happens also when you underfund everything a little bit, because then people are kind of forced to Claudify. And this is something that we see. For work where sometimes we just put one engineer on a project, the way that they're able to ship really quickly, because they want to ship quickly, this is an intrinsic motivation that comes from within. You just want to do a good job. If you have a good idea, you just really want to get it out there. No one has to force you to do that. That comes from you. And so, if you have Claude, you can just use that to automate a lot of work. And that's kind of what we see over and over. So, I think that's one principle: underfunding things a little bit.
I think another principle is just encouraging people to go faster. So, if you can do something today, you should just do it today. And this is something we really, really encourage on the team. Early on, it was really important because it was just me. And so our only advantage was speed. That's the only way that we could ship a product that would compete in this very crowded coding market. But nowadays, it's still very much a principle we have on the team. And if you want to go faster, a really good way to do that is to just have Claude do more stuff. So it just very much encourages that.
This idea of underfunding, it's so interesting, because in general there's this feeling like AI is going to allow you to not have as many employees, not have as many engineers. And so it's not only that you can be more productive; what you're saying is that you will actually do better if you underfund. It's not just that AI can make you faster, it's that you will get more out of the AI tooling if you have fewer people working on something.
Yeah, if you hire great engineers, they'll figure out how to do it, especially if you empower them to do it. This is something I actually talk a lot about with CTOs at all sorts of companies. My advice generally is don't try to optimize. Don't try to cost cut at the beginning. Start by just giving engineers as many tokens as possible. And now you're starting to see companies like... at Anthropic, everyone can use a lot of tokens. We're starting to see this come up as a perk at some companies. If you join, you get unlimited tokens. This is something I very much encourage, because it makes people free to try these ideas that would have been too crazy. And then if there's an idea that works, then you can figure out how to scale it. And that's the point to kind of optimize and to cost cut, figure out, maybe you can do it with Haiku or with Sonnet instead of Opus or whatever. But at the beginning, you just want to throw a lot of tokens at it and see if the idea works, and give engineers the freedom to do that.
So, the advice here is just be loose with your tokens, with the cost of using these models. People hearing this may be like, of course, he works at Anthropic. He would want us to use as many tokens as possible. But what you're saying here is the most interesting, innovative ideas will come out of someone just kind of taking it to the max and seeing what's possible.
Yeah, and I think the reality is at small scale, you're not going to get a giant bill or anything like this. If it's an individual engineer experimenting, the token cost is still probably relatively low relative to their salary or other costs of running the business. So it is actually not a huge cost. As the thing scales up, so let's say they built something awesome and then it takes a huge amount of tokens and then the cost becomes pretty big, that's the point at which you want to optimize it. But don't do that too early. Have you seen companies where
their token cost is higher than their salary? Is that a trend you think we're going to find and see?
You know, at Anthropic we're starting to see some engineers that are spending, you know, like hundreds of thousands a month in tokens. So we're starting to see this a little bit. There's some companies that are... we're starting to see similar things.
Yeah.
Going back to coding. Do you miss writing code? Is this something you're kind of sad about, that this is no longer a thing you'll do as a software engineer?
It's funny for me, you know, when I learned engineering, for me it was very practical. I learned engineering so I could build stuff. And for me, I was self-taught. You know, I studied economics in school, but I didn't study CS, but I taught myself engineering kind of early on. I was programming in like middle school.
And from the very beginning it was very practical. So I actually learned to code so that I can cheat on a math test. That was like the first thing. We had these graphing calculators and, you know, I just programmed the answer into the
TI-83?
TI-83 Plus. Yeah, exactly.
Plus.
Plus, yeah. So I programmed the answers in, and then the next math test, whatever, the next year, it was just too hard. Like, I couldn't program all the answers in because I didn't know what the questions were. And so I had to write a little solver, so it was a program that would just solve these, you know, these algebra questions or whatever. And then I figured out you can get a little cable, you can give the program to the rest of the class, and then the whole class gets A's. But then we all got caught and the teacher told us to knock it off.
But from the very beginning, it's always just been very practical for me, where programming is a way to build a thing. It's not the end in itself.
At some point, I personally fell into the rabbit hole of kind of the beauty of programming. So I wrote a book about TypeScript. I started the... actually at the time it was the world's biggest TypeScript meetup, just because I fell in love with the language itself. And I kind of got in deep into functional programming and all this stuff.
I think a lot of coders get distracted by this. For me, there is a beauty to programming, and especially to functional programming. There's a beauty to type systems. There's a certain kind of buzz that you get when you solve a really complicated math problem; it's kind of similar when you kind of balance the types or, you know, the program is just really beautiful. But it's really not the end of it. I think for me, coding is very much a tool and it's a way to do things.
That said, not everyone feels this way. So for example, there's one engineer on the team, Lena, who, you know, was still writing C++ on the weekends by hand because, for her, she just really enjoys writing C++ by hand. And so everyone is different. And I think even as this field changes, even as everything changes, there's always space to do this. There's always space to enjoy the art and to kind of do things by hand if you want.
Do you worry about your skills atrophying as an engineer? Is that something you worry about, or is it just like, you know, this is just how it's going to go?
I think it's just the way that it happens. I worry about it too much personally. I think for me, programming is on a continuum.
And, you know, way back in the day... you know, software actually is relatively new, right? If you look at the way programs are written today, using software that's running on a virtual machine or something, this has been the way that we've been writing programs since probably the 1960s. So, you know, it's been like 60 years or something like that. Before that it was punch cards. Before that it was switches. Before that it was hardware. And before that it was just, you know, literally pen and paper. It was a room full of people that were doing math on paper.
And so, you know, programming has always changed in this way. In some ways you still want to understand the layer under the layer, because it helps you be a better engineer. And I think this will be the case maybe for the next year or so. But I think pretty soon it just won't really matter. It is just going to be kind of like the assembly code running under the program or something like this.
At an emotional level, you know, I feel like I've always had to learn new things. And as a programmer, it doesn't feel that new, because there's always new frameworks. There's always new languages. It's just something that we're quite comfortable with in the field. But at the same time, you know, this isn't true for everyone. And I think some people are going to feel a greater sense of, I don't know, maybe loss or nostalgia or atrophy or something like this.
I don't know if you saw this, but Elon was saying, why isn't the AI just writing straight to binary? Because what's the point of all this, you know, programming abstraction in the end?
Yeah, that's a good question. I mean, it totally can do that if you wanted to.
Oh, man. So what I'm hearing here, in terms of... there's always this question, should I learn to code? Should people in school learn to code? What I heard from you is your take is, in like a year or two, you don't really need to.
My take is, I think for people that are using Claude Code, that are using agents to code today, you still have to understand the layer under. But yeah, in a year or two it's not going to matter.
I was thinking about what is the right historical analogue for this? Because somehow we have to situate this thing in history and kind of figure out when have we gone through similar transitions? What's the right kind of mental model for this? I think the thing that's come closest for me is the printing press.
And so, you know, if you look at Europe in the mid-1400s, literacy was actually very low. It was sub 1% of the population; it was scribes that, you know, they were the ones that did all the writing. They were the ones that did all the reading. They were employed by lords and kings that often were not literate themselves. And so, you know, it was their job, this very tiny percent of the population, to do this.
And at some point, you know, Gutenberg and the printing press came along. And there was this crazy stat that in the 50 years after the printing press was built, there was more printed material created than in the thousand years before. And so the volume of printed material just went way up. The cost went way down. It went down something like a hundred X over the next 50 years.
And if you look at literacy, you know, it actually took a while, because learning to read and write is, you know, quite hard. It takes an education system. It takes free time. It takes not having to work on a farm all day so that you actually have time for education and things like this. But over the next 200 years it went up to like 70% globally. So I think this is the kind of thing that we might see, a similar kind of transition.
And there was actually this interesting historical document where there was an interview with some scribe in the 1400s about, how do you feel about the printing press? And they were actually very excited, because they were like, actually the thing that I don't like doing is copying between books. The thing that I do like doing is drawing the art in books and then doing the book binding. And I'm really glad that now my time is freed up.
And it's interesting, as an engineer, I sort of felt a parallel with this. Like, this is sort of how I feel, where I don't have to do the tedious work of coding anymore. Because this has always been sort of the detail of it. It's always been the tedious part of it, and kind of messing with Git and using all these different tools. That was not the fun part. The fun part is figuring out what to build and kind of coming up with this. It's talking to users. It's thinking about these big systems. It's thinking about the future. It's collaborating with, you know, other people on the team. And that's what I get to do more of now.
And what's amazing is that the tool you're building allows anybody to do this. People that have no technical experience can do exactly what you're describing. I've been doing a bunch of random little projects and it's just like, anytime you get stuck, just like, "Help me figure this out." And you get unblocked. I was an engineer earlier in my career for 10 years. And I just remember spending so much time on libraries and dependencies and little things and just like, "Oh my god, what do I do?" And then looking on Stack Overflow. And now it's just like, "Help me figure this out." And here's step by step, 1, 2, 3, 4. Okay, we got this.
Yeah, exactly. Exactly. I was talking to an engineer earlier today. They're writing some service in Go and, you know, it's been like a month already and they built up the service. It's working quite well. And then I was like, "Okay, so how do you feel writing in Go?" He was like, "You know, I still don't really know Go, but..." And I think we're going to start to see more and more of this. If you know that it works correctly and efficiently, then you don't actually have to know all the details.
Clearly, the life of a software engineer has changed dramatically. It's like a whole new job now as of the past year or two. What do you think is the next role that will be most impacted by AI, either within tech, like, you know, product managers, designers, or even outside tech? Where do you think AI is going next?
I think it's going to be a lot of the roles that are adjacent to engineering. So yeah, it could be product managers, it could be design, could be data science. It is going to expand to pretty much any kind of work that you can do on a computer, because the model is just going to get better and better at this. And, you know, the Cowork product is kind of the first way to get at this, but it's just the first one. And it's the thing that I think brings agentic AI to people that haven't really used it before. And people are just starting to get a sense of it for the first time.
When I think about tech engineering a year ago, no one really knew what an agent was, no one really used it, but nowadays it's just the way that, you know, we do our work. And then when I look at non-technical work today, or maybe semi-technical, like product work and, you know, data science and things like this, when you look at the kinds of AI that people are using, it's always these conversational AI, it's a chatbot or whatever, but no one really has used an agent before.
And this word "agent" just gets thrown around all the time and it's just so misused, it's lost all meaning. But agent actually has a very specific technical meaning, which is it's an AI, it's an LLM that's able to use tools. So it doesn't just talk, it can actually act and it can interact with your system. And, you know, this means it can use your Google Docs and it can send email, it can run commands on your computer and do all this kind of stuff. So I think any kind of job where you use computer tools in this way, I think this is going to be next.
This is something we have to kind of figure out as a society, this is something we have to figure out as an industry. And I think for me also, this is one of the reasons it feels very important and urgent to do this work at Anthropic, because I think we take this very, very seriously. And so now, you know, we have economists, we have policy folks, we have social impact folks. This is something we just want to talk about a lot, so as a society we can kind of figure out what to do, because it shouldn't be up to us.
So the big question, which you're kind of alluding to, is jobs and job loss and things like that. There's this concept of Jevons paradox: just as we can do more, we hire more, and it's not actually as scary as it looks. What have you experienced so far, I guess, with AI becoming a big part of the engineering job? Are you hiring more than if you didn't have AI? And just thoughts on jobs?
Yeah, I mean, for our team, we're hiring. So the Claude Code team is hiring. If you're interested, just check out the jobs page on Anthropic. Personally, you know, all this stuff has just made me enjoy my work more. I have never enjoyed coding as much as I do today, because I don't have to deal with all the minutiae. So for me personally, it's been quite exciting. This is something that we hear from a lot of customers, where they love the tool, they love Claude Code because it just makes coding delightful again. And that's just so fun for them.
But it's hard to know where this thing is going to go, and again, I just have to reach for these historical analogs. And I think the printing press is just such a good one, because what happened is this technology that was locked away to a small set of people, like knowing how to read and write, became accessible to everyone. It was just inherently democratizing. Everyone started to be able to do this. And if that wasn't the case, then something like the Renaissance just could never have happened, because a lot of the Renaissance was about knowledge spreading. It was about written records that people used to communicate. You know, because there were no phones or anything like this. There's no internet at the time. So it's about, what does this enable next?
And I think that's the very optimistic version of it for me, and that's the part that I'm really excited about. It's just unimaginable. You know, we couldn't be talking today if the printing press hadn't been invented. Our microphones wouldn't exist. None of the things around us would exist. It just wouldn't be possible to coordinate such a large group of people if that wasn't the case.
And so I imagine a world, you know, a few years in the future, where everyone is able to program. And what does that unlock? Anyone can just build software anytime. And I have no idea. It's just the same way that, you know, in the 1400s, no one could have predicted this. I think it's the same way. But I do think in the meantime, it's going to be very disruptive and it's going to be painful for a lot of people. And again, as a society, this is a conversation that we have to have. And this is a thing that we have to figure out together.
So, for folks hearing this that want to succeed and, you know, make it in this crazy turmoil we're entering, any advice? Is it, you know, play with the AI tools, get really proficient at the latest stuff? Is there anything else that you recommend to help people stay ahead?
Yeah, I think that's pretty much it. Experiment with the tools, get to know them, don't be scared of them. Just, you know, dive in, try them, be on the bleeding edge, be on the frontier.
Maybe the second piece of advice is try to be a generalist more than you have in the past. For example, in school, a lot of people that study CS, they learn to code and they don't really learn much else. Maybe they learn a little bit of systems architecture or something like this. But some of the most effective engineers that I work with every day, and some of the most effective, you know, product managers and so on, they cross over disciplines. So on the Claude Code team, everyone codes. You know, our product manager codes, our engineering manager codes, our designer codes, our finance guy codes, our data scientist codes. Like everyone
on the team codes. And then if I look at particular engineers, people often cross different disciplines. So, some of the strongest engineers are hybrid product and infrastructure engineers. Or product engineers with really great design sense and they're able to do design also. Or an engineer that has a really good sense of the business and can use that to figure out what to do next. Or an engineer that also loves talking to users and can just really channel what users want to figure out what's next.
So, I think a lot of the people that will be rewarded most over the next few years, they won't just be AI native and they don't just know how to use these tools really well, but also they're curious and they're generalists and they cross over multiple disciplines and can think about the broader problem they're solving rather than just the engineering part of it.
Do you find these three separate disciplines still useful as a way to think about the team? They're, you know, engineering, design, product management. Do you find, even though they are now coding and contributing to thinking about what to build, do you feel like those are three roles that will persist long-term, at least at this point?
I think in the short term it will persist, but one thing that we're starting to see is there's maybe a 50% overlap in these roles where a lot of people are actually just doing the same thing and some people have specialties. For example, I code a little bit more, or Cat, our PM, does a little bit more, you know, coordination or planning or, you know, forecasting or things like this.
Stakeholder alignment.
Stakeholder alignment. Exactly. I do think that there is a future where I think by the end of the year what we're going to start to see is these start to get even murkier, where I think in some places the title software engineer is going to start to go away and it's just going to be replaced by builder, or maybe it's just everyone's going to be a product manager and everyone codes or something like this.
Who says hiring has to be fair? Every founder and hiring manager I've been speaking with these days is feeling the same pressure. Hire the best people as fast as possible, but recruiting is time consuming, alignment is hard, and competition for great talent keeps getting tighter. That's why teams like ElevenLabs, Brex, Replit, Deel, and 5,000 other organizations use Metaview, the AI company giving high-performance teams a real unfair advantage in hiring.
They give you a suite of AI agents that behave like recruiting co-workers. They find candidates for you based on your exact criteria, take interview notes automatically, gather insights across your hiring process, and help you identify the best candidates in your pipeline. AI handles the recruiting toil and gives you a real source of truth. That means hours saved per hire and a team focused on what matters most, winning the right candidates. Don't let your competitors out-hire you. Metaview customers close roles 30% faster. Try Metaview today for free and get an extra month of sourcing at metaview.ai/lenny. That's m-e-t-a-v-i-e-w.ai/lenny.
You talked about how you're enjoying coding more. I actually did this little informal survey on Twitter. I don't know if you saw this, where I did three different polls. I asked engineers, are you enjoying your job more or less since adopting AI tools? And then I did a separate one for PMs and one for designers. And both engineers and PMs, 70% of people said they're enjoying their job more. And about 10% said they're enjoying their job less. Designers, interestingly, only 55% said they're enjoying their job more and 20% said they're enjoying their job less. Thought that was really interesting.
That's super interesting. I'd love to talk to these people, you know, both in the more bucket and the less bucket, just to understand. Did you get to follow up with any of them?
A few people replied, and we're actually doing a follow-up poll that we'll link to in the show notes, going deeper into some of this stuff. But there's, you know, the factors that make it more fun and less fun. The designers, they didn't share a lot actually, of just, like, why are you enjoying your job less? I didn't hear a lot. So I'm curious what's going on there.
Yeah, I'm seeing this a little bit at Anthropic. I think everyone is fairly technical. This is something that we screen for, you know, when people join. There's a lot of technical interviews that people go through even for non-technical functions. And, you know, our designers virtually all code. So I think for them this is something that they have enjoyed from what I've seen, because now instead of bugging engineers they can just go in and code, and even some designers that didn't code before have just started to do it, and for them it's great because they can unblock themselves. But I'd be really interested just to hear more people's experiences, because I bet it's not uniform like that.
Yeah, so maybe if you're listening to this, leave a comment if you're finding your job less fun and you're enjoying your job less, because from what you're saying and what I'm hearing from most people, 70% of PMs and engineers are loving their job more. So if you're not in that bucket, something's going on.
Yeah, yeah. We do see that people also use different tools. So for example, our designers use the Claude desktop app a lot more to do their coding. So you just download the desktop app, there's a Code tab, it's right next to Cowork, and it's actually the same as Claude Code, so it's the same agent and everything. We've had this for many, many months. And so you can use this to code in a way that you don't have to open a bunch of terminals, but you still get the power of Claude Code, and the biggest thing is you can just run as many Claude sessions in parallel as you want. We call this multi-Clauding.
So it's a little more native, I think, for folks that are not engineers, and really this is back to bringing the product to where the people are. You don't want to make people use a different workflow. You don't want to make them go out of their way to learn a new thing. Whatever people are doing, if you can make that a little bit easier, then that's just going to be a much better product that people enjoy more, and this is just this principle of latent demand, which I think is just the single most important principle in product.
Can you talk about that actually, because I was going to go there. Explain what this principle is and just what happens when you unlock this latent demand?
Latent demand is this idea that if you build a product in a way that can be hacked or can be kind of misused by people in a way it wasn't really designed for, to do something that they want to do, then this helps you as the product builder learn where to take the product next.
So an example of this is Facebook Marketplace. So the manager for the team, Fiona, was actually the founding manager for the Marketplace team, and she talks about this a lot. Facebook Marketplace started based on the observation back in, this must have been like 2016 or something like this, that 40% of posts in Facebook groups are buying and selling stuff. So this is crazy. It's like people are abusing the Facebook groups product to buy and sell, and it's not abuse in a security sense, it's abuse in that no one designed the product for this, but they're kind of figuring it out because it is just so useful for this. And so it was pretty obvious if you build a better product to let people buy and sell, they're going to like it. And it was just very obvious that Marketplace would be a hit from this. And so the first thing was buy and sell groups, so kind of special purpose groups to let people do that, and the second product was Marketplace.
Facebook Dating, I think, started in a pretty similar place. And I think the observation was if you look at profile views, so people looking at each other's profiles on Facebook, 60% of profile views were people that are not friends with each other, that are opposite gender. And so this is kind of like, you know, a traditional dating setup, but people are just creeping on each other. So maybe if you can build a product for this, it might work.
And so this idea of latent demand, I think it's just so powerful. And for example, this is also where Cowork came from. We saw that for the last 6 months or so, a lot of people using Claude Code were not using it to code. There was someone on Twitter using it to grow tomato plants, there was someone else using it to analyze their genome. Someone was using it to recover photos from a corrupted hard drive, it was wedding photos. There was someone that was using it, I think, to analyze an MRI. So there's just all these different use cases that are not technical at all. And it was just really obvious, like, people are jumping through hoops to use a terminal to do this thing. Maybe we should just build a product for them.
And we saw this actually pretty early. Back in maybe May of last year, I remember walking into the office and our data scientist, Brandon, had Claude Code on his computer. He just had a terminal up. And I was shocked. I was like, "Brandon, what are you doing? You figured out how to open the terminal," which is, you know, a very engineering product. Even a lot of engineers don't want to use a terminal. It's just the lowest level way to do your work, just really in the weeds of the computer. And so he figured out how to use the terminal. He downloaded Node.js. He downloaded Claude Code. And he was doing SQL analysis in the terminal. And it was crazy. And then the next week all the data scientists were doing the same thing.
So when you see people abusing the product in this way, using it in a way that it wasn't designed, in order to do something that is useful for them, it's just such a strong indicator that you should just build a product, and people are going to like that, something that's special purpose for that.
I think now there's also this kind of interesting second dimension to latent demand. This is sort of the traditional framing: look at what people are doing, make that a little bit easier, empower them. The modern framing that I've been seeing in the last 6 months is a little bit different, and it's look at what the model is trying to do and make that a little bit easier.
And so when we first started building Claude Code, I think a lot of the way that people approached designing things with LLMs is they kind of put the model in a box. And they were like, here's this application that I want to build, here's what I want it to do. Model, you're going to do this one component of it. Here's the way that you're going to interact with these tools and APIs and whatever. And for Claude Code, we inverted that. We said the product is the model. We want to expose it. We want to put the minimal scaffolding around it, give it the minimal set of tools, so it can do the things. It can decide which tools to run, it can decide in what order to run them in, and so on.
And I think a lot of this was just based on latent demand of what the model wanted to do. And so in research, we call this being on distribution. You want to see what the model is trying to do. In product terms, latent demand is just the same exact concept, but applied to the model.
You talked about Cowork. Something that I saw you talk about when you launched that initially is your team built that in 10 days. That's insane. I think that it came out and was used by millions of people pretty quickly. Something like that being built in 10 days. Any stories there, other than just, you know, we used Claude Code to build it, that's it?
Yeah, it's funny. Claude Code, like I said, when we released it, it was not immediately a hit. It became a hit over time and there were a few inflection points. So one was, you know, Opus 4. It just really, really inflected. And then in November, it inflected. And it just keeps inflecting. The growth just keeps getting steeper and steeper and steeper every day. But, you know, for the first few months, it wasn't a hit. People used it, but a lot of people couldn't figure out how to use it. They didn't know what it was for. The model still wasn't very good.
Cowork, when we released it, was just immediately a hit, much more so than Claude Code was early on. I think a lot of the credit, honestly, just goes to Felix and Sam and Jenny and the team that built this. It's just an incredibly strong team.
And again, the place Cowork came from is just this latent demand. We saw people using Claude Code for these non-technical things, and we were trying to figure out what to do. And so for a few months, the team was exploring. They were trying all sorts of different options. And in the end, someone was just like, "Okay, what if we just take Claude Code and put it in the desktop app?" And that's essentially the thing that worked. And so over 10 days, they just completely used Claude Code to build it.
And, you know, Cowork actually has this very sophisticated security system that's built in, essentially these guardrails to make sure that the model does the right thing and doesn't go off the rails. So for example, we ship an entire virtual machine with it. And Claude Code just wrote all of this code. So we just had to think about, all right, how do we make this a little bit safer, a little more self-guided for people that are not engineers. It was fully implemented with Claude Code. Took about 10 days.
We launched it early. You know, it was still pretty rough and it's still pretty rough around the edges. But this is kind of the way that we learn, both on the product side and on the safety side: we have to release things a little bit earlier than we think, so that we can get the feedback, so that we can talk to users. We can understand what people want, and then that will shape where the product goes in the future.
Yeah, I think that point is so interesting and it's so unique. There's always been this idea: release early, learn from users, get feedback, iterate. The fact that it's hard to even know what the AI is capable of and how people will try to use it is a unique reason to start releasing things early. That will help you, as you exactly describe, with this idea of what is the latent demand in this thing that we didn't really know. Let's put it out there and see what people do with it.
Yeah, and at Anthropic, as a safety lab, the other dimension of that is safety. Because, you know, when you think about model safety, there's a bunch of different ways to study it. Sort of the lowest level is alignment and mechanistic interpretability. So this is when we train the model, we want to make sure that it's safe. We at this point have pretty sophisticated technology to understand what's happening in the neurons, to trace it. And so, for example, if there's a neuron related to deception, we're starting to get to the point where we can monitor it and understand that it's activating. And so this is alignment. This is mechanistic interpretability. It's the lowest layer.
The second layer is evals. And this is essentially a laboratory setting. The model is in a petri dish and you study it. You put it in a synthetic situation and just say, "Okay, model, what do you do? And are you doing the right thing? Is it aligned? Is it safe?"
And then the third layer is seeing how the model behaves in the wild. And as the model gets more sophisticated, this becomes so important, because it might look very good on these first two layers, but not great on the third one.
We released Claude Code really early
because we wanted to study safety. And we actually used it within Anthropic for, I think, 4 or 5 months or something before we released it because we weren't really sure, like, this is the first agent that, you know, the first big agent that I think folks had released at that point. It was definitely the first, you know, coding agent that became broadly used. And so we weren't sure if it was safe. And so we actually had to study it internally for a long time before we felt good about that. And even since, you know, there's a lot that we've learned about alignment, there's a lot that we've learned about safety that we've been able to put back into the model, back into the product.
And for Cowork it's pretty similar. The model's in this new setting, it's, you know, doing these tasks that are not engineering tasks. It's an agent that's acting on your behalf. It looks good on alignment, it looks good on evals. We tried it internally, it looks good. We tried it with a few customers, it looks good. Now we have to make sure it's safe in the real world. And so that's why we released a little early, that's why we call it a research preview. But yeah, it's just constantly improving. And this is really the only way to make sure that over the long term the model is aligned and it's doing the right things.
It's such a wild space that you work in where there's this insane competition and pace. At the same time, there's this fear that if you get some, if that, like, you know, the god can escape and cause damage. And just finding that balance must be so challenging. What I'm hearing is there's kind of these three layers, and I know this could be a whole podcast conversation, how you all think about the safety piece. But just what I'm hearing is there's these three layers you work with. There's kind of like observing the model thinking and operating. There's tests, evals that tell you this is doing bad things, and then releasing it early. I haven't actually heard a ton about that first piece. That is so cool. So you guys can, there's an observability tool that can let you peek inside the model's brain and see how it's thinking and where it's heading.
Yeah, you should at some point have Chris Olah on the podcast because he's just the industry expert on this. He invented this field of, we call it mechanistic interpretability. And the idea is, you know, like, I did this core, like, what is your brain? Like, what is it? It's like a bunch of neurons that are connected. And so what you can do is, like in a human brain or an animal brain, you can study it at this kind of mechanistic level to understand what the neurons are doing. It turns out, surprisingly, a lot of this does translate to models also. So model neurons are not the same as animal neurons, but they behave similarly in a lot of ways.
And so we've been able to learn just a ton about the way these neurons work, about, you know, this layer or this neuron maps to this concept. How particular concepts are encoded, how the model does planning, how it thinks ahead. You know, like, a long time ago we weren't sure if the model was just predicting the next token or is doing something a little bit deeper. Now I think there's actually quite strong evidence that it is doing something a little bit deeper. And then the structures that allow it to do this are pretty sophisticated now. Where, as the models get bigger, it's not just like a single neuron that corresponds to a concept. A single neuron might correspond to a dozen concepts. And if it's activated together with other neurons, this is called superposition. And together it represents this more sophisticated concept. And it is just something we're learning about all the time.
You know, and for Anthropic, as we think about the way this space evolves, doing this in a way that is safe and good for the world is just, this is the reason that we exist. And this is the reason that everyone is at Anthropic. Everyone that is here, this is the reason why they're here.
So a lot of this work we actually open source. We publish it a lot. And you know, we publish very freely to talk about this. Just so we can inspire other labs that are working on similar things to do it in a way that's safe. And this is something that we've been doing for Claude Code also. We call this the race to the top internally.
And so for Claude Code, for example, we released an open source sandbox. And this is a sandbox they can run the agent in. And it just makes sure that there's certain boundaries and it can't access, like, everything on your system. And we made that open source and it actually works with any agent, not just Claude Code. Because we wanted to make it really easy for others to do the same thing. So this is just the same principle of race to the top. We want to make sure this thing goes well, and this is the lever that we have.
Incredible. Okay. I definitely want to spend more time on that. I will follow up with this suggestion. Something else that I've been noticing in the field across engineers, product managers, others that work with agents is there's this kind of anxiety people feel when their agents aren't working. There's a sense that, like, oh man, it needs to, has a question and answer, or it's like blocked on something, or I'm like, there's all this productivity I'm losing, I need to wake up and get it going again. Is that something you feel? Is that something your team feels? Do you feel like this is a problem we need to track and think about?
I always have a bunch of agents running. So like at the moment I have like five agents running. And at any moment, like, you know, I wake up and I start a bunch of agents. Like the first thing I did when I woke up was like, oh man, I want everybody want to check this thing. So I opened up my phone, Claude iOS app, code tab, you know, like, agent do blah blah blah. Because I wrote some code yesterday and I was like, wait, did I do this right? I was kind of double guessing something, and it was correct. But now it's just like so easy to do this.
So I don't know, there is this little bit of anxiety maybe. I personally haven't really felt it just because I have agents running all the time. And I'm also just not locked into a terminal anymore. Maybe a third of my code now is in the terminal, but also a third is using the desktop app, and then a third is the iOS app, which is just so surprising because I did not think that this would be the way that I code, even in 2026.
I love that you just describe it as coding still, which is just talking to Claude Code to code for you essentially. And it's interesting that this is now coding. Coding now is describing what you want, not writing actual code.
I kind of wonder if the people that used to code using punch cards or whatever, if you show them software, what they would have said.
Isn't that crazy?
I remember reading something. This was maybe like very early versions of, like, ACM magazine or something. Where people were saying, "No, it's not the same thing. This isn't really coding." And then, you know, they called it programming. I think coding is kind of a new word.
But I kind of think about those, like, back in the, you know, my family's from the Soviet Union. I was born in Ukraine. And my grandpa was actually one of the first programmers in the Soviet Union. And he programmed using punch cards.
And, you know, he told my mom growing up, or she told these stories of when she was growing up, he would bring these punch cards home and there was just these big stacks of punch cards. And for her, she would draw all over them with crayons, and that was her childhood memory. But for him, that was his experience of programming, and he actually never saw the software transition. But at some point it did transition to software, and I think there's probably this older generation of programmers that just didn't take software very seriously. And then they would have been like, "Well, you know, it's not really coding." But I think this is a field that just has always been changing in this way.
I don't think you know this, but I was born in Ukraine also.
Oh, I don't know that. Yeah, which town?
I'm from Odessa.
Oh, me too.
You what? [laughter] Yeah, that's crazy. Wow, incredible. Wait a moment. Maybe we're related in some small way. What year did you leave, and your family leave?
We came in '95. Okay, we left in '88. A little earlier. Yeah. What a different life that would have been to not leave, huh?
Yeah, I just feel so lucky every day that I get to grow up here.
Yeah, my family, anytime there's like a toast at a meal, they're just like, "To America."
Yeah, it's like, okay, enough about that, but you get it, you know, once you start really thinking about what life could have been.
Yeah, yeah, exactly. Yeah, we do the same toast, but it's still vodka.
Still vodka, absolutely. [laughter]
Oh man. Okay, let me ask you a couple more things here. You shared some really cool tips for how to get the most out of AI, how to build on AI, how to build great products on AI. One tip you shared is give your team as many tokens as they want, just let them experiment. You also shared just advice generally of just build towards where the model's going, not to where it is today. What other advice do you have for folks that are trying to build AI products?
I'd probably share a few more things. So, one is don't try to box the model in. I think a lot of people's instinct when they build on the model is they try to make it behave a very particular way. They're like, you know, this is a component of a bigger system. I think some examples of this are people layering very strict workflows on the model, for example. You know, to say, like, you must do step one, then step two, then step three, and you have this very fancy orchestrator doing this. But actually almost always you get better results if you just give the model tools, you give it a goal, and you let it figure it out. I think a year ago you actually needed a lot of the scaffolding, but nowadays you don't really need it.
So, you know, I don't know what to call this principle, but it's like, you know, ask not what the model can do for you. Maybe it's something like this. Just think about how do you give the model the tools to do things? Don't try to over-curate it. Don't try to put it into a box. Don't try to give it a bunch of context up front. Give it a tool so that it can get the context it needs. You're just going to get better results.
I think a second one is maybe actually an even more general version of this principle, is just the bitter lesson. And actually for the Claude Code team we have a, you know, hopefully listeners have read this, but Rich Sutton had this blog post maybe 10 years ago called the bitter lesson. And it's actually a really simple idea. His idea was that the more general model will always outperform the more specific model.
And I think for him he was talking about self-driving cars and other domains like this. But actually there's just so many corollaries to the bitter lesson. And for me the biggest one is just always bet on the more general model. And you know, over the long term, don't try to use tiny models for stuff. Don't try to fine-tune. Don't try to do any of this stuff. There's some applications, you know, there's some reasons to do this, but almost always try to bet on the more general model if you can, if you have that flexibility.
And so these workflows are essentially a way that, you know, it's not a general model. It's putting the scaffolding around it. And in general, what we see is maybe scaffolding can improve performance maybe 10, 20%, something like this. But often these gains just get wiped out with the next model. So it's almost better to just wait for the next one.
And I think maybe this is a final principle, and something that Claude Code, I think, got right in hindsight. From the very beginning, we bet on building for the model 6 months from now. Not for the model of today. And for the very early versions of the product, I just wrote so little of my code because I didn't trust it. Because, you know, it was like Sonnet 3.5, then it was like 3.6 or, I forget, 3.5 New, whatever name we gave it. These models just weren't very good at coding yet. They were getting there, but it was still pretty early.
So back then, the model did, you used to get for me. It automated some things, but it really wasn't doing a huge amount of my coding. And so the bet with Claude Code was at some point the model gets good enough that it can just write a lot of the code. And this is the thing that we first started seeing with Opus 4 and Sonnet 4. And Opus 4 was our first kind of ASL-3 class model that we released back in May. And we just saw this inflection because everyone started to use Claude Code for the first time. And that was kind of when our growth really went exponential. And like I said, it's kind of stayed there.
So I think this is advice that I actually give to a lot of folks, especially people building startups. It's going to be uncomfortable because your product market fit won't be very good for the first 6 months. But if you build for the model 6 months out, when that model comes out, you're just going to hit the ground running, and the product is going to click and start to work.
And when you say build for the model 6 months out, what is it that you think people can assume will happen? Is it just generally it will get better at things? Is it just like, okay, it's almost good enough, and that's a sign that it'll probably get better at that thing? Is there any advice there?
I think that's a good way to do it. Like, you know, obviously within an AI lab, we get to see the specific ways that it gets better. [laughter] So, it's a little unfair. But we also try to talk about this. So, you know, one of the ways that it's going to get better is it's going to get better and better using tools and using computers. This is a bet that I would make.
Another one is it's going to get better and better at running for long periods of time. And this is a place, you know, there's all sorts of studies about this. But if you just trace the trajectory, or, you know, maybe even for my own experience, when I used Sonnet 3.5 back, you know, a year ago, it could run for maybe 15 or 30 seconds before it started going off the rails, and you just really had to hold its hand through any kind of complicated task. But nowadays with Opus 4.6, you know, on average, it'll run maybe 10, 20, 30 minutes unattended, and I'll just start another Claude and have it do something else. And, you know, like I said, I always have a bunch of Claudes running. And they can also run for hours or even days at a time. I think there's some examples where they ran for many weeks. And so, I think over time this is going to become more and more normal, where the models are running for a very, very long period of time, and you don't have to sit there and babysit them anymore.
So, you just talked about tips for building AI products. Any tips for someone just using Claude Code, say for the first time, or just someone already using Claude Code that wants to get better? What are a couple pro tips that you could share?
I will give a caveat, which is there's no one right way to use Claude Code. So, I can share some tips, but honestly, this is a dev tool. Developers are all different. Developers have different preferences. They have different environments. So, there's just so many ways to use these tools. There's no one right way. You sort of have to find your own path. Luckily, you can ask Claude Code. It's able to make recommendations. It can edit your settings. It kind of knows about itself, so it can help with that.
A few tips that generally I find pretty useful is number one is just use the most capable model. Currently, that's Opus 4.6. I have maximum effort enabled always. The thing that happens is sometimes people try to use a less expensive model like Sonnet or something like this. But because it's less intelligent, it actually takes more tokens in the end to do the same task. And so, it's actually not obvious that it's cheaper if you use a less expensive model. Often, it's actually cheaper and less token intensive if you use the most capable model cuz it can just do the same thing much faster with less correction, less hand-holding, and so on. So, that's the first tip is just use the best model.
The second one is use plan mode. I start almost all of my tasks in plan mode, maybe like 80%. And plan mode is actually really simple. All it is is we inject one sentence into the model's prompt to say, "Please don't write any code yet." That's it. Like there's actually like nothing fancy going on. It's just the simplest thing. And so, for people that are in the terminal, it's just shift tab twice, and that gets you into plan mode. For people in the desktop app, there's a little button. On web, there's a little button. It's coming pretty soon to mobile also. And we just launched it for the Slack integration, too.
So, plan mode is the second one. And essentially, the model will just go back and forth with you. Once the plan works good, then you let the model execute. I auto-accept edits after that cuz if the plan works good, it's just going to one-shot it. It'll get it right the first time almost every time with Opus 4.6.
And then maybe the third tip is just play around with different interfaces. I think a lot of people when they think about Claude Code, they think about a terminal. And you know, of course, we support every terminal. We support like Mac, Windows, you know, like whatever terminal you might use, it works perfectly. But we actually support a lot of other form factors, too. Like, you know, we have like iOS and Android apps, we have a desktop app. There's the Slack integration. There's all sorts of things that we support. So, I would just like play around with these. And again, it's like every engineer is different. Everyone that's building is different. Just find the thing that feels right to you and use that. You don't have to use the terminal. It's the same Claude agent running everywhere.
Amazing. Okay, just a couple more questions to round things out. What's your take on Codex? How do you feel about that product? How do you feel about where they're going and just kind of competing in this very competitive space in coding agents?
Yeah, I actually haven't really used it. But I think I did use it maybe when it came out. It looked a lot like Claude Code to me, so that was kind of flattering. I think it's actually good, you know, to have more competition cuz people should get to choose and hopefully it forces all of us to like do an even better job. Honestly for our team though, we're just focused on solving the problems that users have. So, for us, you know, we don't spend a lot of time looking at competing products. We don't really try the other products. You know, you kind of want to be aware of them. You want to know they exist. But for me, I just love talking to users. I love making the product better. I love just acting on feedback. So, it's really just about building a good product.
Maybe a last question. So, I talked to Ben Mann, co-founder of Anthropic, about what to talk to you about here, just suggestions, which I've integrated throughout our chat. One question he had for you is what's your plan post-AGI? What do you think you're going to be doing? What's your life like once we hit AGI, whatever that means?
So, before I joined Anthropic, I was actually living in rural Japan and it was like a totally different lifestyle. I was like the only engineer in the town. I was the only English speaker in the town. It was just like a totally different vibe. Like a couple times a week I would like bike to the farmers market. And you know, you like bike by like rice paddies and stuff. It was just like totally different, just the complete opposite of San Francisco.
One of the things that I really liked is a way that we got to know our neighbors and we kind of built friendships is by trading like pickles. So, in the town where we lived, it was actually like everyone made like miso, everyone made pickles. And so I actually got like decently good at making miso. And you know, I made a bunch of batches and this is something that I still make. Miso is this interesting thing where it teaches you to think on these long time scales. That's just very different than engineering. Cuz like, you know, like a batch of white miso takes like at least 3 months to make. And red miso is like, you know, two, three, four years. You just have to be very patient. You kind of mix it up and then you just like let it sit. You have to be very, very patient. So, the thing that I love about it is just thinking in these long time scales. And yeah, I think post-AGI or if I wasn't at Anthropic, I'd probably be making miso.
I love this answer. Ben asked me to ask you about what's the deal with you and miso. And so I love that you answered it. Okay, so the future might be just going deep into miso. Getting really good at making miso. Amazing.
Boris, this was incredible. I feel like we're brothers now from Ukraine. Before we get to our very exciting lightning round, is there anything else that you wanted to share? Is there anything you want to leave listeners with? Anything you want to double down on?
Yeah, I think I would just like underscore, you know, like for Anthropic since the beginning, this idea of like starting at coding, then getting to tool use, then getting to computer use has just been the way that we think about things. And this is the way that we know the models are going to develop or, you know, the way that we want to build our models. And it's also the way that we get to learn about safety, study it, and improve it the most.
So, you know, everything that's happening right now around, you know, just like Claude Code becoming this huge, you know, multi-billion dollar business. And, you know, like now all my friends use Claude Code and they just text me about it all the time. So, just like, you know, this thing getting kind of big. In some ways it's a total surprise. Because we didn't know that it would be this product. We didn't know that it would start in a terminal or anything like this. But, in some ways it's just totally unsurprising because this has been our belief as a company for a long time. At the same time it just feels still very early. You know, like most of the world still does not use Claude Code. Most of the world still does not use AI. So, it just feels like this is 1% done and there's so much more to go.
Yeah, man. That's insane to think, seeing the numbers that are coming out. You guys just raised a bazillion dollars. I think Claude Code alone is making $2 billion in revenue. Anthropic, I think the number you guys put out, you're making 15 billion in revenue. It's insane to just think this is how early it still is and just the numbers we're seeing.
Yeah, yeah, yeah. It's crazy. And I mean like the way that Claude Code has kept growing is honestly just the users. So many people use it. They're so passionate about it. They fall in love with the product. And then they tell us about stuff that doesn't work, stuff that they want. And so, like the only reason that it keeps improving is because everyone is using it. Everyone is talking about it. Everyone keeps giving feedback. And this is just the single most important thing. And you know, for me this is the way that I love to spend my days, just talking to users and making it better for them.
And making miso.
And making miso. Well, you know, the miso's like not super involved. Just got to wait.
Just got to wait.
Well, Boris, with that we've reached our very exciting lightning round. I've got five questions for you. Are you ready?
Let's do it.
First question, what are two or three books that you find yourself recommending most to other people?
I'm a big reader. I would start with a technical book. One is Functional Programming in Scala. This is the single best technical book I've ever read. It's very weird because you're not going to use Scala and I don't know how much this matters in the future now, but there's this just elegance to functional programming and thinking in types and this is just the way that I code and the way that I can't stop thinking about coding. So, you know, you could think of it as a historical artifact. You could think of it as something that will level you up.
I love this. Never before mentioned book, my favorite.
Oh, amazing, amazing.
Okay, second one is Accelerando by Stross. This is probably, you know, like my big genre is sci-fi. Like probably sci-fi and fiction. Accelerando is just this incredible book and it's just so fast-paced. The pace gets faster and faster and faster and I just feel like it captures the essence of this moment that we're in more than any other book that I've read. Just the speed of it. And it starts as lift-off is starting to happen and, you know, we're starting to approach the singularity. And it ends with like this collective lobster consciousness orbiting Jupiter. And, you know, this happens over like the span of a few decades or something. So, the pace is just incredible. I really love it.
Maybe I'll do one more book. The Wandering Earth by Cixin Liu. So, he's the guy that did Three-Body Problem. I think a lot of people know him for that. I think Three-Body Problem was awesome, but I actually like his short stories even more. So, Wandering Earth is one of the short story collections and he just has some really, really amazing stories. And it's also just quite interesting to see Chinese sci-fi because it has a very different perspective than Western sci-fi and kind of the way that at least he as a writer thinks and it's just really, really interesting to read and just beautifully written.
It's so interesting how sci-fi has prepared us to think about where things are going. Just like crazy amounts of models of like, "Okay, I see. I've read about this sort of world."
Yeah, I think for me this is like the reason that I joined Anthropic actually. Cuz, you know, like I said, I was living in this rural place. I was thinking in these long time scales because everything is just so slow out there. At least compared to SF. And just like all the things that you do are based around the seasons and it's based around this food that takes many, many months. That's the way that kind of like social events were organized. That's the way you kind of organize your time.
Like you go to the farmers market and it's like it's persimmon season and you know that because there's like 20 persimmon vendors. And then the next week the season is done and it's like grape season and you kind of see this. So it's like these kind of long time scales. And I was also reading a bunch of sci-fi at the time. And just like being in this moment I was like, you know, just thinking about these long time scales. I know how this thing can go and I felt like I had to contribute to it going a little bit better. And that's actually why I ended up at Anthropic. Ben Mann was also a big part of that, too.
I feel like I want to do a whole podcast just talking about your time in Japan and the journey of Boris through Japan to Anthropic, but we'll keep it short. I'll quickly recommend a sci-fi book to you if you haven't read it. Have you read A Fire Upon the Deep?
This is Vinge, right? Yeah, it's great.
Yes. Okay. That one's like so interesting from an AI, AGI perspective. So few people have read that. So I read it myself. Yeah. It's one I like a lot.
Yeah, yeah, yeah. I like A Deepness in the Sky also. I think those parts are the greatest.
The sequel is greater. Yeah, yeah, yeah. I think so.
Yeah. It's very long and like complex to get into, but so good. Okay, we'll keep going through our lightning round. Do you have a favorite recent movie or TV show you've really enjoyed?
So I actually don't really watch TV or movies. I just don't really have time these days. I did watch, I'm going to bring up another Cixin Liu, but The Three-Body Problem series on Netflix I really loved. I thought that was like a great rendition of the book series.
It's a common pattern across AI leaders, no time to watch TV or movies, which I completely understand. Is there a favorite product you've recently discovered that you really love?
I'm going to like shill a little bit and just say Cowork. Cuz this is legitimately the one product that's been pretty life-changing for me, just cuz I have it running all the time and the Chrome integration in particular is just really excellent. So it's like paid a traffic fine for me, it like canceled a couple subscriptions for me. Just like the amount of tedious work it gets out of the way is awesome. I also don't know if it's a product, but maybe I'll also have another podcast that I really love. Obviously besides Lenny's, is...
Obviously.
Yeah, it's the Acquired podcast by Ben and David. It's just like super awesome. I feel like the way that they get into like business history and bring it alive is really, really good. And I would start with the Nintendo episode if you haven't listened to it.
Great tip. With Cowork, just so people understand if they haven't tried this, basically you type something you want to get done and it can launch Chrome and just do things for you. I saw someone went on pat leave from Anthropic and had it fill out these like medical forms for him, these like really annoying PDFs where it just like loads up the browser, logs in, fills them out, submits them.
Yeah, exactly, exactly. And it actually just kind of works. Like we tried this experiment like a year ago and it didn't really work cuz the model wasn't ready, but now it actually just works and it's amazing. I think a lot of people just don't really understand what this is because they haven't used the agent before. And it just feels very, very similar to me to Claude Code a year ago. But like I said, it's just growing much faster than Claude Code did in the early days. So I think it's starting to break through a bit.
And there's also this Chrome extension that you mentioned that you could just use standalone that sits in Chrome and you could just talk to Claude looking at your screen, at your browser, and have it do stuff, have it tell you about what you're looking at, summarize what you're looking at, things like that.
Exactly, exactly. For people that are like just running to use Cowork, the thing I recommend is, so you download the Claude desktop app, you go to the Cowork tab, it's right next to the code tab. The thing that I recommend doing is like start by having it use a tool. So like clean up your desktop or like summarize your email or something like this or, you know, like respond to the top three emails. Like it actually just responds to emails for me now, too.
The second thing is connect tools. So, like if you say, "Look at my top emails and then send Slack messages." Or, you know, like put them in a spreadsheet or something. Or, for example, like I use it for all my project management. So, we have a single spreadsheet for the whole team. There's like a row per engineer. Every week everyone fills out a status. And every Monday Cowork just goes through and it messages every engineer on Slack that hasn't filled out their status. And so, I don't have to do this anymore. And this is just one problem. It will do
everything. And then the third thing is just run a bunch of Claudes in parallel. So, with Cowork you can have as many tasks running as you want. So, it's like start one task, you know, I have this project management thing running. Then I'll have to do something else, then something else, and then I'll kick these off. And then I just go get a coffee while it runs.
There's a post I'll link to that shares a bunch of ways people use what was previously Claude Code or now just you could do through Cowork. Cuz a lot of this is just like, "Oh, wow. I hadn't thought I could use it for that." And once you see like these examples I think are where people need to hear of just like, "Oh, wow. I didn't know I could do that."
Yeah, I think a lot of this was also, some of this was also inspired by you, Lenny. You had this post about, it was like 50 non-technical use cases for Claude Code or something like this. So, we actually, one of our PMs used that as a way to evaluate Cowork before we released it. And I think at the point where we hit where Cowork was able to do like 48 out of the 50, that we're like, "Okay, it's pretty good."
Wow, I did not know that. That [laughter] is awesome. It's, I'm becoming an eval.
Yeah? How does that feel?
Amazing. I feel like I'm valuable to the future of AI. This is like reverse breaking through. [laughter] Wow, that is so cool. Wow, okay. I wonder what those last two are. Anyway, okay. Two more questions. Do you have a favorite life motto that you often come back to in work or in life?
Use common sense. I think a lot of the failures that I see, especially in a work environment, is people just failing to use common sense. Like, they follow a process without thinking about it. They just do a thing without thinking about it or they're working on a product that's like not a good product or not a good idea. And they're just following the momentum and not thinking about it. I think the best results that I see are people thinking from first principles and just developing their own common sense. Like if something smells weird then, you know, it's probably not a good idea. So I think just this is the single advice that I give, you know, to co-workers more than anything too.
And I feel like that alone could be its own podcast conversation. What is common sense? How do you build? But we'll keep this short. Final question. So you've gotten more active on Twitter/X. I'm curious just why and just what's your experience been with Twitter, the world of Twitter, because you get a lot of engagement on Twitter/X.
So for a long time I used Threads exclusively because I actually helped build Threads a little bit back in the day. And I also just like the design. It's like a very clean product. I just really like that. I started using Threads cuz actually I was bored. So in December I was in Europe.
Twitter, you mean?
Oh yeah, yeah, yeah. I started using Twitter cuz I was bored. So my wife and I were traveling around in Europe for December. We're just kind of nomading around. We went to like Copenhagen, went to like a few different countries. And for me it was just like a coding vacation. So every day I was coding and that's like my favorite kind of vacation. It's just like code all day. It's the best.
And at some point I just kind of got bored and like I ran out of ideas for, you know, like a few hours. I was like, "Okay, what do I want to do next?" And so I opened Twitter and I saw people tweeting about Claude Code and then I just started responding and then I was like, "Okay, maybe actually a thing I should do is just like look for bugs that people have. Maybe people have like bugs or any feedback they have." And so kind of introduced myself, asked if people had a bunch of bugs and feedback. And I think they were kind of surprised by like the pace at which we're able to address feedback nowadays.
For me it's just like so normal. Like if someone has a bug, like I can probably fix it within a few minutes. Cuz I just write to Claude and as long as the description is good, it would just go and do it and then I'll go do something else and answer the next thing. But I think for a lot of people it was pretty surprising. So it's really cool. And yeah, the experience on Twitter has been pretty great. It's been awesome just engaging with people and seeing what people want, hearing about bugs, hearing about features.
I saw a complaint in the GitHub beer the other day on Twitter just so you could, you're like posting many threads and it was breaking and just like, "Oh man, what's going on here?"
Yeah, yeah, there was a bug. I hope it's fixed now.
Amazing. Oh man, Boris, I could chat with you for hours. I'll let you go. Thank you so much for doing this. You're wonderful. Where can folks find you online? How can listeners be useful to you?
Yeah, find me on Threads or on Twitter. That's the easiest place. And please just tag me on stuff. Send bugs, send feature requests. What's missing? What can we do to make the products better? Like what do you want? I love hearing.
Amazing. Boris, thank you so much for being here.
Cool. Thanks, Lenny. Bye, everyone.
Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at lennyspodcast.com. See you in the next episode.
Article published · Updated