2.20.2026

Paul Mauriat: Keeper of the "Joie de Vivre"

 


People often say "Tell me what books you read, and I'll tell you what kind of person you are." I often think about that saying, and usually define my musical taste as "Tell me what music you listen to, and I'll guess whether you're an introverted or extroverted type." For nearly a year now, I've been listening frequently to Paul Mauriat's music, especially from the 1965-1980 period.

http://www.grandorchestras.com/mauriat/albums/discography-visual.html




Early Discoveries

Before discovering the website mentioned above, I had made two other remarkable discoveries about two Paul Mauriat fans: BoyFromParis and another person from Taiwan with the alias o1160507. These two individuals had uploaded nearly all the songs Paul arranged from 1965-1971, and scattered masterpieces from 1972 onward.

Having heard so many new and wonderful Paul Mauriat songs lately, I'm now torn—do I love Paul Mauriat or Raymond Lefèvre more? Previously, a distant cousin had "enlightened" me about Raymond Lefèvre, recording about 6-7 cassette tapes from his CDs for me. I listened to those tapes until they wore out. Later I traveled to France and bought 9 Raymond compilation CDs at the exorbitant price of $30 each (in 1996). But lately I find that during 1965-1975, Paul's music sounds much better than Raymond's arrangements from the same period.





My History with Paul's Music

My history of listening to Paul's music actually goes back much further than Raymond's. Perhaps it began with faintly hearing "Love Story" or "A Time For Us" before 1975? Hearing music drifting from somewhere while strolling the streets with my father, or visiting family friends and catching some music?

Growing up, my first real "impression" of Paul came from "Alla Figaro," the background music for World Cup '86. At the time I didn't know the title—I just knew that whenever I turned on the TV and heard that music, the match was about to start :-)

Additionally, in documentaries about the Mekong Delta, Saigon television often played background music without crediting who performed it. Only later when I heard Paul again did I learn the origin—pieces Paul himself composed and arranged, like "Minuetto," "Adieu l'Été Adieu la Plage," and especially "Nocturne" and "Petite Melodie."

Classics In The Air

Later (1986-1990), I still didn't pay much attention to Paul's music, but I knew and listened to songs from his "Classics In The Air" trilogy. Thanks to that trilogy, I came to know and love many classical pieces like Bach's "Prelude in C." I still admire and thank Paul for introducing classical music to young people through this "classics made easy" approach.

The Rediscovery

Since I started blogging in Vietnamese regularly, especially after discovering the webpage created by Paul Mauriat super fans, I've become truly passionate about his music, particularly from 1965 to 1975. Each year, according to the discography, he regularly released five to six LPs. His creative output was truly astounding—unprecedented.

What I love most is that he found the best French and Euro-American songs and re-arranged them, thereby supplementing my knowledge of French and American music from that period.

To discuss his arranging artistry during this period could go on forever, but I want to emphasize one point: the clarity and modernity of his arrangements. When listening, no one would think these songs were written in the 60s. Some later Beatles songs (66-70) don't have arrangements noticeably superior to Paul's from the same period.

For each song, Paul extracted its essence, then infused his Paul quality, arranging and orchestrating to make it more splendid, more refined. For example, in "Même si tu revenais," the deep piano carrying the main melody makes it more alluring, while the arpeggiated piano sweep in section 2 makes the main melody beautiful in a different way. His string writing is also fantastic—sometimes sighing, sometimes harmonizing with the main melody.


French Music and "Joie de Vivre"

In the previous section, I mentioned the talented, versatile musician of French music: the conductor of the grand orchestra bearing his name, Le Grand Orchestre de Paul Mauriat. In his catalog of over 1,000 arrangements, a significant portion—nearly two hundred songs—are French songs from the 1940s-50s like "Comme d'habitude" and "La vie en rose," and especially songs that have become immortal from 1965 to 1980.



From the 1930s-50s, French music continued to perfect its own pop style, recognized worldwide as "la chanson française," with iconic songs like "La vie en rose" performed by the legendary Édith Piaf. In this genre, one sees emotions that are both elevated and simple, melodies that are captivating, and song development that is straightforward.

Sad sentiments exist but aren't the majority. Listeners perceive small joys, romantic love, love of nature. Upon reflection, the music reflects an attitude, a way of living very famous among the French: "joie de vivre" (joy of living).

This is clearly expressed in how Paul Mauriat chose to present to listeners, with songs like:

  • "Le ciel, le soleil et la mer"
  • "Un homme et une femme"
  • "Que je t'aime"
  • "Je t'aime... moi non plus"
  • "Et bonjour à toi l'artiste"

Listening to his music, one feels happy, the day passes quickly, one feels eager to live along with the captivating rhythm of melody and tempo.

Les Matins d'Hiver (Winter Mornings)

Recently I tried finding French songs Paul arranged in the 70s, and found many outstanding ones beyond those I already knew. Among the lesser-known ones was "Les matins d'hiver." Seeing how beautifully he arranged it, I checked who performed the original—it turned out to be Gérard Lenorman.

As soon as the music starts, there's excitement, with a fast-tempo piano intro. Then comes the verse with gentle strings, but with a syncopated bass line and many rests. Then a string "hook" creates a "flashback" effect.

The drums casually keep time with the bass, barely playing the first half of the verse, only the second half, and when playing fills, that's when it really gets lively. The chorus becomes an anthem of ultimate elation—it can't get more joyful.




Most Famous French Arrangements (1971-1977)

Here's a list of the most famous songs Paul arranged—anyone who knows French music must know these:

  • Tombe la neige
  • Après toi
  • Ce n'est rien
  • La décadanse
  • L'avventura
  • Summer of '42
  • Une belle histoire
  • La maladie d'amour
  • Rien qu'une larme
  • Tu te reconnaîtras
  • Viens viens (Rain rain)
  • Le premier pas
  • Emmanuelle
  • Et bonjour à toi l'artiste
  • L'été indien (Africa)
  • Il a neigé sur Yesterday
  • L'oiseau et l'enfant
  • Michèle

Paul particularly favored music from artists like Stone et Charden, Gérard Lenorman, Michel Fugain, and Julien Clerc.



The Cooling of French Music

Suddenly, around 1977-1978, Paul stopped arranging many French songs. Why? Two main reasons:

  1. The rise of disco music - The mid-70s saw disco's coronation with Donna Summer, The Bee Gees, ABBA, Boney M. French music followed the trend but lost the charm and lyricism. Where were those smooth melodies over syncopated drum rhythms? Replaced by monotonous disco beats.
  2. The Japanese market - Paul's orchestral music became an indispensable spiritual nourishment for the Japanese. He performed thousands of concerts in Japan, from 1968 until his farewell Sayonara Concert in Osaka in 1998. Japanese audiences were indifferent to French music, preferring American hits, so French songs gradually disappeared from his albums.

Dutton Vocalion CDs

Only recently has the Japanese music industry's monopoly been broken by Dutton Vocalion, a small company specializing in remastering old LPs at reasonable prices.

http://www.duttonvocalion.co.uk








If you're in Europe or the USA, you can buy these CDs for about $20 each. This is a rare opportunity not to be missed.

Did We Fall in Love Through the Japanese?

For middle-aged people over 40 like us, we probably only know a few representative Paul Mauriat songs like: "Love Is Blue," "El Bimbo," "Minuetto," "Penelope," "Toccata," "La Reine de Saba," "La chanson pour Anna."







These CDs were made by the Japanese, who held the monopoly on remixing Paul's arrangements. We kept hearing those same songs, not knowing that Paul had many other wonderful arrangements, especially during French music's prime from 1970-77.

If possible, try to buy one or two of the original Dutton Vocalion CDs. Truly, listening from CD is 10 times better than YouTube!

♫

at
Labels:

Claude Code 1st Birthday!!!

 
















at

Claude Code And Its Creator Boris Cherny

Table of Contents

Introduction

"At Anthropic, the way that we thought about it is we don't build for the model of today. We build for the model six months from now." — "All of Claude Code has just been written and rewritten and rewritten and rewritten over and over and over. There is no part of Claude Code that was around 6 months ago." — "Maybe in a month, no more need for plan mode in a month. Oh my god."

HOST: Welcome to another episode of the Lightcone and today we have an extremely special guest, Boris Cherny, the creator engineer of Claude Code. Boris, thanks for joining us.

BORIS: Thanks for having me.

HOST: Thanks for creating a thing that has taken away my sleep for about 3 weeks straight. I am very addicted to Claude Code and it feels like rocket boosters. Has it felt like this for people — like for you know months at this point?

BORIS: I think it was like end of November is where a lot of my friends said like something changed. I remember for me I felt this way when I first created Claude Code and I didn't yet know if I was on to something. I kind of felt like I was on to something and then that's when I wasn't sleeping. Yeah. And that was just like three straight months. This was September 2024. It was like three straight months. I didn't take a single day vacation. Worked through the weekends. Worked every single night. I was just like, "Oh my god, this is — I think this is going to be a thing. I don't know if it's useful yet because it couldn't actually code yet."





I. The Most Surprising Moment in the Rise of Claude Code

HOST: If you look back on those moments to now, like what would be the most surprising thing about this moment right now?

BORIS: It's unbelievable that we're still using a terminal. That was supposed to be the starting point. I didn't think that would be the ending point. And then the second one is that it's even useful because at the beginning it didn't really write code. Even in February when we GA'd it wrote maybe like 10% of my code or something like that. I didn't really use it to write code. It wasn't very good at it. I still wrote most of my code by hand. So the fact that our bets paid off and it got good at the thing that we thought it was going to get good at because it wasn't obvious. At Anthropic, the way that we thought about it is we don't build for the model of today. We build for the model 6 months from now. And that's actually like still my advice to founders that are building on LLMs — just try to think about what is that frontier where the model is not very good at today because it's going to get good at it and you just have to wait.

II. How Boris Came Up with the Idea for Claude Code

HOST: Going back though, do you remember when you first got the idea? Can you just talk us through that? Like was it some spark or what was even the first version of it in your mind?

BORIS: You know, it's funny. It was so accidental that it just kind of evolved into this. As Anthropic I think for Anthropic the bet has been coding for a long time and the bet has been the path to safe AGI is through coding and this has kind of always been the idea and the way you get there is you teach the model how to code then you teach it how to use tools then you teach it how to use computers. And you can kind of see that because the first team that I joined at Anthropic it was called the Anthropic Labs team and it produced three products — it was Claude Code, MCP, and the desktop app. So you can kind of see how these weave together.

The particular product that we built — no one asked me to build a CLI. We kind of knew maybe it was time to build some kind of coding product because it seemed like the model was ready, but no one had yet really built the product that harnessed this capability. So like still there's this insane feeling of product overhang. But at the time it was just even crazier because no one had built this yet. And so I started hacking around and I was like, "Okay, we build a coding product. What do I have to do first? I have to understand how to use the API because I hadn't used the Anthropic API at that point." And so I just built a little terminal app to use the API. That's all that I did. And it was a little chat app because you know like you think about the AI applications of the time and for non-coders today what are most people using is just a chat app. So that's what I built. And it was in a terminal. I can ask questions. I give answers. Then I think tool use came out. I just wanted to try out tool use because I don't really understand what this is. I was like tool use is cool. Is this actually useful? Probably not. Let me just try it.

HOST: You built it in terminal just because it was the easiest way to get something up and running.

BORIS: Yes. Because I didn't have to build a UI.

HOST: Okay. It was just me at that point. The IDEs, Cursor, Windsurf taking off. Were you under any pressure or getting lots of suggestions of, hey, we should build this out as a plugin or as a fully featured IDE itself?

BORIS: There was no pressure because we didn't even know what we wanted to build. Like the team was just in explore mode. We knew vaguely we wanted to do something in coding, but it wasn't obvious what. No one was high confidence enough. That was my job to figure out. And so I gave the model the bash tool. That was the first tool that I gave it just because I think that was literally the example in our docs. I just took the example. It was in Python. I just ported it to TypeScript because that's how I wrote it. I didn't know what the model could do with bash. So I asked it to read a file. It could cat the file. So that was cool. And then I was like, "Okay, what can you actually do?" And I asked, "What music am I listening to?" It wrote some AppleScript to script my Mac and look up the music in my music player.

HOST: Oh my god.

BORIS: And this was Sonnet 3.5. And I didn't think the model could do that. And that was my first — I think ever — feel-the-AGI moment where I was just like, "Oh my god, the model — it just wants to use tools. That's all it wants."

III. The Elegant Simplicity of Terminals

HOST: That's kind of fascinating. I mean it's very contrarian that Claude Code works so well in such an elegant simple form factor. Terminals have been around for a really long time and that seemed to be like a good design constraint that allowed a lot of interesting developer experiences. It doesn't feel like working. It just feels fun as a developer. I don't think about files where everything is and that came by accident almost.

BORIS: Yeah, it was an accident. I remember after the terminal started to take off internally — and honestly after building this thing I think like 2 days after the first prototype I started giving it to my team just for dogfooding because if you come up with an idea and it seems useful the first thing you want to do is give it to people to see how they use it. And then I came in the next day and then Robert who sits across from me who's another engineer he just had Claude Code on his computer and he was using it to code. I was like, "What are you doing? This thing isn't ready. It's just a prototype." But yeah, it was already useful in that form factor.

And I remember when we did our launch review to kind of launch Claude Code externally, this was in December, November, something like that in 2024. Dario asked and he was like, "The usage chart internally like the DAU chart is vertical. Are you forcing engineers to use it? Why are you mandating them?" And I was just like, "No, no, we didn't. I just posted about it and they've just been telling each other about it." Honestly, it was just accidental. We started with the CLI because it was the cheapest thing and it just kind of stayed there for a bit.

IV. The First Use Cases

HOST: So in that 2024 period, how were the engineers using it? Were they sort of shipping code with it yet or were they using it in a different way?

BORIS: The model was not very good at coding yet. I was using it personally for automating git. I think at this point I've probably forgotten most of my git because Claude Code has just been doing it for so long. But yeah, automating bash commands — that was a very early use case and like operating Kubernetes and things like this. People were using it for coding. There were some early signs of this. I think the first use case was actually writing unit tests because it's a little bit lower risk and the model was still pretty bad at it but people were figuring it out and they were figuring out how to use this thing.

And one thing that we saw is people started writing these markdown files for themselves and then having the model read that markdown file. And this is where CLAUDE.md came from. Probably the single for me biggest principle in product is latent demand. And just every bit of this product is built through latent demand after the initial CLI. And so CLAUDE.md is an example of that.

There's this other general principle that I think is maybe interesting where you can build for the model and then you can build scaffolding around the model in order to improve performance a little bit and depending on the domain you can improve performance maybe 10, 20% something like that and then essentially the gain is wiped out with the next model. So either you can build the scaffolding and then get some performance gain and then rebuild it again or you just wait for the next model and then you kind of get it for free. The CLAUDE.md and kind of the scaffolding is an example of that and really I think that's why we stayed in the CLI is because we felt there is no UI we could build that would still be relevant in 6 months because the model was improving so quickly.

V. What's in Boris' CLAUDE.md?

HOST: Earlier we were saying like we should compare CLAUDE.md's but you said something very profound which is yours is actually very short which is almost like the opposite of what people might expect. Why is that? What's in your CLAUDE.md?

BORIS: Okay so I checked this before we came. So my CLAUDE.md has two lines. The first line is whenever you put up a PR, enable automerge. So as soon as someone accepts it, it's merged. That's just so I can code and I don't have to kind of go back and forth with code review or whatever. And then the second one is whenever I put up a PR, post it in our internal team stamps channel. Just so someone can stamp it and I can get unblocked. And the idea is every other instruction is in our CLAUDE.md that's checked into the codebase and it's something our entire team contributes to multiple times a week. And very often I'll see someone's PR and they make some mistake that's totally preventable and I'll just literally tag Claude on the PR. I'll just do like add Claude, you know, add this to the CLAUDE.md and I'll do this many times a week.

HOST: Do you have to compact the CLAUDE.md? Like I definitely reached a point where I got the message at the top saying your CLAUDE.md is like thousands of tokens now. What do you do when you guys hit that?

BORIS: So our CLAUDE.md is actually pretty short. I think it's like a couple thousand tokens maybe something like that. If you hit this my recommendation would be delete your CLAUDE.md and just start fresh.

HOST: Interesting.

BORIS: I think a lot of people try to over-engineer this and really the capability changes with every model. And so the thing that you want is do the minimal possible thing in order to get the model on track. And so if you delete your CLAUDE.md and then the model is getting off track, it does the wrong thing. That's when you kind of add back a little bit at a time. And what you're probably going to find is with every model, you have to add less and less.

For me, I consider myself a pretty average engineer to be honest. I don't use a lot of fancy tools. I don't use Vim. I use VS Code because it's simpler.

HOST: Wait, really? I would have assumed that because you built this in the terminal that you were sort of like a diehard terminal Vim-only person. You know, screw those VS Code people.

BORIS: Well we have people like that on the team. There's Adam Wolf for example, he's on the team, he's like "you will never take Vim from my cold dead hands." So there's definitely a lot of people like that on the team and this is one of the things that I learned early on is every engineer likes to hold their dev tools differently. They like to use different tools. There's just no one tool that works for everyone. But I think also this is one of the things that makes it possible for Claude Code to be so good because I kind of think about it as what is the product that I would use that makes sense to me and so to use Claude Code you don't have to understand Vim you don't have to understand tmux you don't have to know how to SSH you don't have to know all the stuff you just have to open up the tool and it'll guide you it'll do all this stuff.

VI. How Do You Decide the Terminal's Verbosity?

HOST: How do you decide how verbose you want the terminal to be? Like sometimes you have to go Control-O and check it out and is it like internal bikeshed battles around longer, shorter? I mean every user probably has an opinion. How do you make those sorts of decisions?

HOST: What's your opinion? Is it too verbose right now?

HOST: Oh, I love the verbosity because basically sometimes it just goes off the deep end and I'm watching and then I can just read very quickly and it's like, "Oh, no, no, it's not that." And then I escape and then just stop it and then it just stops an entire bug farm as it's happening. I mean, that's usually when I didn't do plan mode properly.

BORIS: This is something that we probably change pretty often. I remember early on, this is maybe six months ago, I tried to get rid of bash output just internally just to summarize it because I was like these giant long bash commands, I don't actually care. And then I gave it to Anthropic employees for a day and everyone just revolted. "I want to see my bash" because it actually is quite useful for, you know, like for something like git output, maybe it's not useful, but if you're running Kubernetes jobs or something like this, you actually do want to see it.

We recently hid the file reads and file searches. So you'll notice instead of saying, you know, read foo.md it says, you know, read one file, searched one pattern. And this is something I think we could not have shipped six months ago because the model just was not ready. It would have, you know, it still read the wrong thing pretty often. As a user, you still had to be there and kind of catch it and debug it. But nowadays, I just noticed it's on the right track almost every time. And because it's using tools so much, it's actually a lot better just to summarize it.

But then we shipped it. We dogfooded it for like a month and then people on GitHub didn't like it. So there was a big issue where people were like "no, I want to see the details" and that was really great feedback. And so we added a new verbose mode and so that's just in slash config you can enable verbose mode and if you want to see all the file outputs you can continue to do that. And then I posted on the issue and people still didn't like it which is again awesome because my favorite thing in the world is just hearing people's feedback and hearing how they actually want to use it. And so we just iterated more and more and more to get that really good and to make it the thing that people want.

HOST: I'm amazed how much I enjoy fixing bugs now. And then all you have to do is have really good logging and then even just say like hey check out this particular object it messed up in this way and it searches the log. It figures everything out. It can go into your — you can make a production tunnel and it'll look at your production DB for you. It's like this is insane. Bug fixing is just going to Sentry, copy markdown. Pretty soon it's just going to be straight MCP. It's like an auto-bug-fixing and test-making sort of — what's the new term they call it, like a making a startup factory.

HOST: Oh yeah. Right. There's all these concepts now of rather than having to review the code — I'm old school, so I like the verbosity. I like to say, "Oh, well, you're doing this, but I want you to do that." Right? But there's a totally different school of thought now that says anytime a real human being has to look at code, that's bad.

BORIS: Yeah. Yeah. Which is fascinating. I think Dan Shipper talks about this a lot as kind of whenever you see the model make a mistake try to put it in the CLAUDE.md, try to put it in skills or something like that so it's reusable. But I think there's this meta point that I actually struggle with a lot. And people talk about agents can do this, agents can do that, but actually what agents can do, it changes with every single model. And so sometimes there's a new person that joins the team and they actually use Claude Code more than I would have used it. And I'm just constantly surprised by this.

Like for example, we had a memory leak and we were trying to debug it. And by the way, Jared Sumner has just been on this crusade killing all the memory leaks and it's just been amazing. But before Jared was on the team, I had to do this and there was this memory leak. I was trying to debug it. And so I took a heap dump. I opened it in DevTools. I was looking through the profile. Then I was looking through the code and I was just trying to figure this out. And then another engineer on the team, Chris, he just asked Claude Code. He was like, "Hey, I think there's a memory leak. Can you run this?" And then try to figure it out. And Claude Code took the heap dump. It wrote a little tool for itself to analyze the heap dump. And then it found the leak faster than I did. And this is just something I have to constantly relearn because my brain is still stuck somewhere six months ago at times.

VII. Beginner's Mindset Is Key as the Models Improve

HOST: So what would be some advice for technical founders to really become maximalists at the latest model release? It sounds like people fresh off of school or that don't have any assumptions might be better suited than maybe sometimes engineers who have been working at it for a long time. And how do the experts get better?

BORIS: I think for yourself it's kind of beginner mindset and I don't know maybe just like humility. I feel like engineers as a discipline we've learned to have very strong opinions and senior engineers are kind of rewarded for this. In my old job at a big company when I hired architects and this type of engineer you look for people that have a lot of experience and really strong opinions. But it actually turns out a lot of this stuff just isn't relevant anymore and a lot of these opinions should change because the model is getting better. So I think actually the biggest skill is people that can think scientifically and can just think from first principles.

HOST: How do you screen for that when you try to hire someone now for your team?

BORIS: I sometimes ask about what's an example of when you're wrong. It's a really good one. Some of these classic behavioral questions — not even coding questions — I think are quite useful because you can see if people can recognize their mistake in hindsight, if they can claim credit for the mistake and if they learned something from it. And I think a lot of these very senior people especially — there are some founder types like this but I think founders in particular are actually quite good at it. But other people sometimes will never really take the blame for a mistake. But I don't know, for me personally I'm wrong probably half the time. Like half my ideas are bad and you just have to try stuff and you try a thing, you give it to users, you talk to users, you learn, and then eventually you might end up at a good idea. Sometimes you don't. And this is the skill that I think in the past was very important for founders, but now I think it's very important for every engineer.

HOST: Do you think you would ever hire someone based on the Claude Code transcript of them working with the agent? Because we're actively doing that right now. We just added as a test — you can upload a transcript of you coding a feature with Claude Code or Codex or whatever it is. Personally, I think it's going to work. I mean, you can figure out how someone thinks, like whether they're looking at the logs or not, can they correct the agent if it goes off the rails? Do they use plan mode? When they use plan mode, do they make sure that there are tests? All of these different things — do they think about systems? Do they even understand systems? There's just so much that's embedded in that. I just want a spider web graph, you know, like in those video games like NBA 2K. It's like, oh, this person's really good at shooting or defense. You could imagine a spiderweb graph of someone's Claude Code skill level.

HOST: What would the skills be? What would those be?

HOST: I mean, I think it's like systems, testing, user behavior. There's got to be a design part, product sense, maybe also just automating stuff.

BORIS: My favorite thing in CLAUDE.md for me is I have a thing that says for every plan decide whether it's overengineered, underengineered, or perfectly engineered and why. I think this is something that we're trying to figure out too.

VIII. Hyper Specialists vs Hyper Generalists

BORIS: When I look at engineers on the team that I think are the most effective, there's essentially two — it's very bimodal. There's one side where it's extreme specialists. And so I named Jared before, he's a really good example of this and kind of the Bun team is a really good example. Just hyper specialist. They understand dev tools better than anyone else. They understand JavaScript runtime systems better than anyone else. And then there's the flip side of kind of hyper generalists and that's the rest of the team. And a lot of people they span product and infra or product and design or product and user research, product and business. I really like to see people that just do weird stuff. I think that's one of these things that was kind of a warning sign in the past because it's like can these people actually build something useful?

HOST: That's the litmus test.

BORIS: Yeah, that's what it must be. But nowadays — for example an engineer on the team Daisy, she was on a different team and then she transferred onto our team and the reason that I wanted her to transfer is she put up a PR for Claude Code a couple weeks after she joined or something and the PR was to add a new feature to Claude Code and then instead of just adding the feature what she did is first she put up a PR to give Claude Code a tool so that it can test an arbitrary tool and verify that that works. And then she put up that PR and then she had Claude write its own tool instead of herself implementing it. And I think it's this kind of out of the box thinking that is just so interesting because not a lot of people get it yet.

We use the Claude Agents SDK to automate pretty much every part of development. It automates code review, security review. It labels all of our issues. It shepherds things to production. It does pretty much everything for us. But I think externally I'm seeing a lot of people start to figure this out, but it's actually taken a while to figure out how do you use LLMs in this way? How do you use this new kind of automation? So it's kind of a new skill.

HOST: I guess one of the funnier things that I've been having office hours with various founders about is you have sort of the visionary founder who has the idea, they've built this crystal palace of the product that they want to build. They've totally loaded in their brain who the user is and what they feel and what they're motivated by and then they're sitting in Claude Code and they can do like 50x work and then but they have engineers who work for them who don't have the crystal memory palace of the platonic ideal of the product that the founder has and they can only do like 5x work. Are you hearing stories like that?

BORIS: There's usually a person who's the core designer of a thing and they're just trying to blast it out of their brain.

HOST: What's the nature of teams like that? It seems like that's almost a stable configuration. You're going to have the visionary who now is unleashed, but maybe going back to the top of it, I'm experiencing this right now. I was like, "Oh, well, I'm only a solo person and I need to eat and sleep and I have a whole job. How am I going to do this?"

IX. The Vision for Claude Teams

HOST: We just launched Claude Teams. What's the vision for Claude Teams?

BORIS: Just collaboration. There's this whole new field of agent topologies that people are exploring. What are the ways that you can configure agents? There's this one sub-idea which is uncorrelated context windows. And the idea is just multiple agents, they have fresh context windows that aren't essentially polluted with each other's context or their own previous context. And if you throw more context at a problem, that's like a form of test-time compute. And so you just get more capability that way. And then if you have the right topology on top of it, so the agents can communicate in the right way, they're laid out in the right way, then they can just build bigger stuff.

And so Teams is kind of one idea. There's a few more that are coming pretty soon. And the idea is just maybe it can build a little bit more. I think the first kind of big example where it worked is our plugins feature was entirely built by a swarm over a weekend. It just ran for a few days. There wasn't really human intervention. And plugins is pretty much in the form that it was when it came out.

HOST: How did you set that up? Did you spec out the outcome that you were hoping for and then let it figure out the details and let it run?

BORIS: Yeah. An engineer on the team just gave Claude a spec and told Claude to use an Asana board and then Claude just put up a bunch of tickets on Asana and then spawned a bunch of agents and the agents started picking up tasks. The main Claude just gave instructions and they all just figured it out — independent agents that didn't have the context of the bigger spec.

X. Subagents

BORIS: If you think about the way that our agents actually work nowadays — and I haven't pulled the data on this but I would bet the majority of agents are actually prompted by Claude today in the form of sub-agents because a sub-agent is just a recursive Claude Code. That's all it is in the code. And it's just prompted by — we call her mama Claude — and that's all it is. And I think probably if you look at most agents they're launched in this way.

HOST: My Claude Insights just told me to do this more for debugging. So I spend a lot of time on debugging and it would just be better to have multiple sub-agents spin up and debug something in parallel. And so then I just added that to my CLAUDE.md to be like, hey, next time you try and fix a bug, have one agent that looks in the log, one that looks in the code path. That just seems sort of inevitable.

HOST: For weird scary bugs, I try to fix bugs in plan mode and then it seems to use the agents to sort of search everything. Whereas when you're just trying to do it inline, it's like, okay, I'm going to do this one task instead of search wide.

BORIS: This is something I do all the time too. I just say — if the test seems kind of hard, this kind of research task, I'll calibrate the number of sub-agents I ask it to use based on the difficulty of the task. So if it's really hard, I'll say use three or maybe five or even 10 sub-agents, research in parallel and then see what they come up with.

HOST: I'm curious. So then why don't you put that in your CLAUDE.md file?

BORIS: It's kind of case by case. CLAUDE.md — what is it? It's just a shortcut. If you find yourself repeating the same thing over and over, you put it in the CLAUDE.md. But otherwise, you don't have to put everything there. You can just prompt Claude.

XI. A World Without Plan Mode?

HOST: Are you also in the back of your mind thinking that maybe in six months, you won't need to prompt that explicitly? Like the model will just be good enough to figure out on its own.

BORIS: Maybe in a month.

HOST: No more need for plan mode in a month. Oh my god.

BORIS: I think plan mode probably has a limited lifespan.

HOST: Interesting. That's some alpha for everyone here. What would the world look like without plan mode? Do you just describe it at the prompt level and it would just do it? One-shot it?

BORIS: Yeah, we've started experimenting with this because Claude Code can now enter plan mode by itself. I don't know if you guys have seen that. So, we're trying to get this experience really good. So, it would enter plan mode at the same point where a human would have wanted to enter it. So, I think it's something like this, but actually plan mode — there's no big secret to it. All it does is it adds one sentence to the prompt that's like "please don't code." That's all it is. You can actually just say that.

HOST: Yeah. So it sounds like a lot of the feature development for Claude Code is very much what we talk about at YC — talk to your users and then you come and implement it. It wasn't the other way that you had this master plan and then implemented all the features.

BORIS: Yeah. Yeah. I mean that's all it was. Plan mode was — we saw users that were like "hey Claude come up with an idea, plan this out but don't write any code yet." And there were various versions of this. Sometimes it was just talking through an idea. Sometimes it was these very sophisticated specs that they were asking Claude to write, but the common dimension was do a thing without coding yet. And so literally this was like Sunday night at 10 p.m. I was just looking at GitHub issues and kind of seeing what people were talking about and looking at our internal Slack feedback channel and I just wrote this thing in like 30 minutes and then shipped it that night. It went out Monday morning. That was plan mode.

HOST: So do you mean that there will be no need for plan mode in the sense of "I'm worried that the model's going to do the wrong thing or head off in the wrong direction" but there will still be a need for that — you need to think through the idea and figure out exactly what it is that you want and you have to do that somewhere.

BORIS: I kind of think about it in terms of increasing model capabilities. So maybe 6 months ago a plan was insufficient. So you get Claude to make a plan. Let's say even with plan mode you still have to kind of sit there and babysit because it can go off track. Nowadays what I do is probably 80% of my sessions I start in plan mode — I say plan mode has a limited lifespan but I'm a heavy plan mode user. Probably 80% of my sessions I start in plan mode and Claude will start making a plan. I'll move on to my second terminal tab and then I'll have it make another plan and then when I run out of tabs I open the desktop app and then I go to the code tab and then I just start a bunch of tabs there and they all start in plan mode probably 80% of the time. Once the plan is good, and sometimes it takes a little back and forth, I just get Claude to execute. And nowadays, what I find with Opus 4.5, I think it started with 4.6 it got really good. Once the plan is good, it just stays on track and it'll just do the thing exactly right almost every time.

And so before you had to babysit after the plan and before the plan, now it's just before the plan. So, maybe the next thing is you just won't have to babysit. You can just give a prompt and Claude will figure it out.

HOST: The next step is Claude just speaks to your users directly.

BORIS: Yeah, it just bypasses you entirely. It's funny. This is actually the current stuff for us. Our Claudes actually talk to each other. They talk to our users on Slack, at least internally pretty often. My Claude will tweet once in a while.

HOST: No way.

BORIS: But I actually delete it. It's just a little cheesy. I don't love the tone.

HOST: What does it want to tweet about?

BORIS: Sometimes it'll just respond to someone because I always have Cowork in the background and it's the Cowork that really loves to do that because it likes using a browser.

HOST: That's funny.

BORIS: A really common pattern is I ask Claude to build something. It'll look in the codebase. It'll see some engineer touched something in the git blame and then it'll message that engineer on Slack. Just asking a clarifying question and then once it gets an answer back, it'll keep going.

XII. Tips for Founders to Build for the Future

HOST: What are some tips for founders now on how to build for the future? Sounds like everything is really changing. What are some principles that will stay on and what will change?

BORIS: So I think some of these are pretty basic, but I think they're even more important now than they were before. So one example is latent demand. I mentioned it a thousand times. For me it's just the single biggest idea in product. It's a thing that no one understands. It's a thing I certainly did not understand my first few startups. And the idea is people will only do a thing that they already do. You can't get people to do a new thing. If people are trying to do a thing and you make it easier, that's a good idea. But if people are doing a thing and you try to make them do a different thing, they're not going to do that. And so you just have to make the thing that they're trying to do easier. And I think Claude is going to get increasingly good at figuring out these product ideas for you just because it can look at feedback, it can look at debug logs, it can kind of figure this out.

HOST: That's what you mean by plan mode was latent demand — that people were already like, I don't know, had their Claude chat window open in a browser and were talking to it to figure out the spec and what it should do. And now plan mode just became that — you just do it in Claude Code.

BORIS: Yeah. Yeah, that's it. Sometimes what I'll do is I'll just walk around the office on our floor and I'll just kind of stand behind people — I'll say hi so it's not creepy — and then I'll just see how they're using Claude Code. And this is also just something I saw a lot but it also came up in GitHub issues, like people were talking about it.

XIII. How Much Life Does the Terminal Still Have?

HOST: It seems like you're surprised how far the terminal has gone and how far it's been pushed. How far do you think it has left to go just given this world of swarm, multiple agents? Do you think there's going to be a need for a different UI on top of it?

BORIS: It's funny. If you asked me this a year ago I would have said the terminal has like a three-month lifespan and then we're going to move on to the next thing. And you can see us experimenting with this right because Claude Code started in a terminal but now it's on web, Claude Code is in the desktop app — we've had that for three months or six months or something just in the code tab. It's in the iOS and Android apps just in the code tab. It's in Slack. It's in GitHub. There's VS Code extensions. There's JetBrains extensions. So we're always experimenting with different form factors for this thing to figure out what's the next thing. I've been wrong so far about the lifespan of the CLI. So, I'm probably not the person to forecast that.

XIV. Advice for Dev Tool Founders

HOST: What about your advice to dev tool founders? Someone's building a dev tool company today. Should they be building for engineers and humans or should they be thinking more about what Claude is going to think and want and build for the agent?

BORIS: The way I would frame it is think about the thing that the model wants to do and figure out how do you make that easier. And that's something that we saw — when I first started hacking on Claude Code, I realized this thing just wants to use tools. It just wants to interact with the world. And how do you enable that? Well, the way you don't do it is you put it in a box and you're like, here's the API, here's how you interact with me, and here's how you interact with the world. The way you do it is you see what tools it wants to use. You see what it's trying to do, and you enable that the same way that you do for your users. And so if you're building a dev tool startup, I would think about what is the problem you want to solve for the user? And then when you apply the model to solving this problem, what is the thing the model wants to do? And then what is the technical and product solution that serves the latent demand of both?

XV. Claude Code and TypeScript Parallels

HOST: Back in the day, more than 10 years ago, you were a very heavy user and you wrote a book about TypeScript, right? Before TypeScript was cool. This is when everyone was deep in JavaScript. This is back in the early 2010s, right?

BORIS: Yeah, something like that. Before TypeScript was a thing because back then it was a very weird language. It's not supposed to do a lot of things with being typed in JavaScript and now it's the right thing and it feels like Claude Code in the terminal has a lot of parallels with TypeScript at the beginning.

HOST: TypeScript makes a lot of really weird language decisions. So if you look at the type system pretty much anything can be a literal type for example and this is super weird because even Haskell doesn't even do this. It's just too extreme. Or it has conditional types which I don't think any language thought of at all. It was very strongly typed.

BORIS: Yeah, it was very strongly typed and the idea was — when Joe Pamer and Anders and the early team was building this thing, the way they built it is okay, we have these teams with these big untyped JavaScript code bases. We have to get types in there, but we're not going to get engineers to change the way that they code. You're not going to get JavaScript people to have 15 layers of class inheritance like you would a Java programmer, right? They're going to write code the way they're going to write it. They're going to use reflection and they're going to use mutation and they're going to use all these features that traditionally are very very difficult to type.

HOST: They're very unsafe to type to any strong functional programmer.

BORIS: That's right. And so the thing that they did instead of getting people to change the way that they code, they built a type system around this. And it was just brilliant because there's all these ideas that no one was thinking about even in academia. No one thought of a bunch of these ideas. It purely came out of the practice of observing people and seeing how JavaScript programmers want to write code.

And so for Claude Code there are some ideas that are kind of similar in that you can use it like a Unix utility. You can pipe into it. You can pipe out of it. In some ways it is kind of rigorous in this way but in almost every other way it's just the tool that we wanted. I build a tool for myself and then the team builds the tool for themselves and then for Anthropic employees and then for users and it just ends up being really useful. It's not this principled and academic thing which I think the proof is actually in the results.

HOST: Now fast forward more than 15 years later not many codebases are in Haskell which is more academic and there's tons of them now on TypeScript because it's way more practical, right? Which is interesting.

BORIS: Yeah, it is interesting. It's like TypeScript solves a problem.

XVI. Designing for the Terminal Was Hard

HOST: I guess one thing that's cool — I don't know how many people know, but the terminal is actually one of the most beautiful terminal apps out there and is actually written with React terminal.

BORIS: When I first started building it, I did front-end engineering for a while. And I was also sort of a hybrid — I do design and user research and write code and all this stuff. And we love hiring engineers that are like this. We just love generalists. So for me it's like okay, I'm building a thing for the terminal. I'm actually kind of a shitty Vim user. So how do I build a thing for people like me that are going to be working in a terminal. And I think just the delight is so important. And I feel like at YC this is something you talk about a lot, right? It's build a thing that people love. If the product is useful but you don't fall in love with it, that's not great. So it kind of has to do both.

Designing for the terminal honestly has been hard, right? It's like 80 by 100 characters or whatever. You have 256 colors, you have one font size, you don't have mouse interactions, there's all this stuff you can't do, and there's all these very hard trade-offs. So, a little-known thing, for example, is you can actually enable mouse interactions in a terminal. So, you can enable clicking and stuff.

HOST: Oh, how do you do that in Claude Code? I've been trying to figure out how to do this.

BORIS: We don't have it in Claude Code because we actually prototyped it a few times and it felt really bad because the trade-off is you have to virtualize scrolling and there's all these weird trade-offs because the way terminals work is there's no DOM, right? It's like there's ANSI escape codes and these kind of weird organically evolved specs since the 1960s or whatever.

HOST: Yeah. It feels like BBSes. It's like a BBS door game.

BORIS: Oh my god. That's like a great compliment. It should feel like you're discovering Lord of the Red Dragon. It's fantastic.

But we've had to discover all these UX principles for building the terminal because no one really writes about this stuff. And if you look at the big terminal apps of the 80s or 90s or 2000s or whatever, they use ncurses and they have all these windows and things like this. And it just looks kind of janky by modern standards. It just looks too heavy and complicated. And so we had to reinvent a lot. And for example, something like the terminal spinner, the spinner words, it's gone through probably I want to say like 50 maybe 100 iterations at this point. And probably 80% of those didn't ship. So we tried it, it didn't feel good, move on to the next one. Try it, didn't feel good, move on to the next one.

And this was sort of one of the amazing things about Claude Code — you can write these prototypes and you can do like 20 prototypes back to back, see which one you like, and then ship that and the whole thing takes maybe a couple hours. Whereas in the past, what you would have had to do is use Origami or Framer or something like this. You built maybe three prototypes, it took two weeks. It just took much longer. And so we have this luxury of we have to discover this new thing. We have to build a thing. We don't know what the right endpoint is, but we can iterate there so quickly and that's what makes it really easy and that's what lets us build a product that's joyous and that people like to use.

XVII. Other Advice for Builders

HOST: Boris, you had other advice for builders and we kept interrupting you because we have so many questions. I would say —

BORIS: So okay, maybe two pieces of advice that are kind of weird because it's about building for the model. So one is don't build for the model of today, build for the model of 6 months from now. This is sort of weird, right? Because you can't find PMF if the product doesn't work. But actually this is the thing that you should do because otherwise what will happen is you spend a bunch of work, you find PMF for the product right now and then you're just going to get leapfrogged by someone else because they're building for the next model and a new model comes out every few months. Use the model, feel out the boundary of what it can do and then build for the model that you think will be the model maybe 6 months from now.

I think the second thing is — actually in the Claude Code area where we sit we have a framed copy of the bitter lesson on the wall. And this is Rich Sutton — everyone should read it if you haven't — and the idea is the more general model will always beat the more specific model and there's a lot of corollaries to this but essentially what it boils down to is never bet against the model. And so this is just a thing that we always think about where we could build a feature into Claude Code. We could make it better as a product and we call this scaffolding. That's all the code that's not the model itself. But we could also just wait a couple months and the model can probably just do the thing instead.

And there's always this trade-off. It's like engineering work now and you can extend the capability a little bit, maybe 10, 20% or whatever in whatever domain on the spider chart of what you're trying to extend. Or you can just wait and the next model will do it. So just always think in terms of this trade-off — where do you actually want to invest and assume that whatever the scaffolding is, it's just temporary.

HOST: How often do you rewrite the code base of Claude Code? Is it every six months? Is there scaffolding that you've deleted because you don't need it anymore because the model just improved?

BORIS: Oh so much. Yeah. All of Claude Code has just been written and rewritten and rewritten and rewritten over and over and over. We unship tools every couple weeks. We add new tools every couple weeks. There is no part of Claude Code that was around six months ago. It's just constantly rewritten.

HOST: Would you say most of the code base for current Claude Code — is only say 80% of it only less than a couple months old?

BORIS: Yeah, definitely. It might even be less. Maybe a couple months. That feels about right.

HOST: So the life cycle of code now. That's another alpha — expecting the shelf life to be just a couple months.

BORIS: Yeah. For the best founders.

XVIII. Productivity per Engineer

HOST: Do you see Steve Yegge's post about how awesome working at Anthropic is? And I think there's a line in there that says that an Anthropic engineer currently averages 1,000x more productivity than a Google engineer at Google's peak which is really an insane number honestly. Like 1,000x — three years ago we were still talking about 10x engineers. Now we're talking about 1,000x on top of a Google engineer in their prime. This is unbelievable honestly.

BORIS: Yeah, I mean internally if you look at technical employees, they all use Claude Code every day. And even non-technical employees — I think like half the sales team uses Claude Code. They've started switching to Cowork because it's a little easier to use. It has a VM, so it's a little bit safer. But yeah, we actually just pulled a stat and I think the team doubled in size last year, but productivity per engineer grew something like 70%. It's measured by just the simplest stupidest measure — pull requests. But we also cross-check that against commits and the lifetime of commits and things like this. And since Claude Code came out, productivity per engineer at Anthropic has grown 150%.

And this is crazy because in my old life I was responsible for code quality at Meta. I was responsible for the quality of all of our code bases across every product — Facebook, Instagram, WhatsApp, whatever. And one of the things that the team worked on was improving productivity. And back then seeing a gain of something like 2% in productivity — that was a year of work by hundreds of people. And so this 100%+ — this is just unheard of. Completely unheard of.

XIX. Why Boris Chose to Join Anthropic

HOST: What drove you to come over to Anthropic? I mean basically as a builder you could go anywhere. What was the moment that made you say this is the set of people or this is the approach?

BORIS: I was living in rural Japan and I was opening up Hacker News every morning and I was reading the news and it was all — it just started to be AI stuff at some point and I started to use some of these early products and I remember the first couple times that I used it I was just — it just took my breath away. That's very cheesy to say, but that was actually the feeling. It was just amazing. As a builder, I've just never kind of felt this feeling using these very early products. That was in the Claude 2 days or something like that.

And so I just started talking to friends at labs just to kind of see what was going on. And I met Ben Mann who's one of the founders at Anthropic and he just immediately won me over. And as soon as I met the rest of the team at Anthropic it just won me over and I think probably in two ways. So one is it operates as a research lab. The product was teeny teeny tiny. It's really all about building a safe model. That's all that matters. And so this idea of just being very close to the model and being very close to development and being not the most important thing because the product isn't anymore. It's just the model is the thing that's the most important. That really resonated with me after building product for many years.

And then the second thing was just how mission-driven it is. I'm a huge sci-fi reader. My bookshelf is just filled with sci-fi. And so I just know how bad this can go. And when I kind of think about what's going to happen this year, it's going to be totally insane. And in the worst case it can go very very bad. And so I just wanted to be at a place that really understood that and kind of really internalized that. And at Anthropic, if you overhear conversations in the lunchroom or in the hallway, people are talking about AI safety. This is really the thing that everyone cares about more than anything. And so I just wanted to be in a place like that. I know for me personally the mission is just so important.

XX. How Coding Will Change

HOST: What is going to happen this year?

BORIS: Okay. So if you think back like six months ago and kind of what are the predictions that people are making? So Dario predicted that 90% of the code at Anthropic would be written by Claude. This is true. For me personally it's been 100% since Opus 4.5. I uninstalled my IDE. I don't edit a single line of code by hand. It's just 100% Claude Code and Opus. And I land like 20 PRs a day every day. If you look at Anthropic overall it ranges between 70 to 90% depending on the team. For a lot of teams it's also 100%. For a lot of people it's 100%.

And I remember making this prediction back in May when we GA'd Claude Code that you wouldn't need an IDE to code anymore. And it was totally crazy to say. I feel like people in the audience gasped because it was such a silly prediction at the time. But really all it is is you just trace the exponential and this is just so deep in the DNA at Anthropic because three of our founders were co-authors of the scaling laws paper. They kind of saw this very early and so this is just tracing the exponential — this is what's going to happen and yes that happened.

So continuing to trace the exponential I think what will happen is coding will be generally solved for everyone. And I think today coding is practically solved for me and I think it'll be the case for everyone. Regardless of domain, I think we're going to start to see the title software engineer go away. And I think it's just going to be maybe builder, maybe product manager, maybe we'll keep the title as kind of a vestigial thing, but the work that people do, it's not just going to be coding. Software engineers are also going to be writing specs. They're going to be talking to users. This thing that we're starting to see right now in our team where engineers are very much generalists and every single function on our team codes — our PMs code, our designers code, our EM codes, our finance guy codes, everyone on our team codes. We're going to start to see this everywhere.

So this is sort of the lower bound if we just continue the trend. The upper bound I think is a lot scarier. And this is something like we hit ASL-4. At Anthropic, we talk about these safety levels. ASL-3 is where the models are right now. ASL-4 is the model is recursively self-improving. And so if this happens, essentially, we have to meet a bunch of criteria before we can release a model. And so the extreme is that this happens or there's some kind of catastrophic misuse like people are using the model to design bioviruses, design zero-days, stuff like this. And this is something that we're really really actively working on so that doesn't happen.

I think it's just been honestly so exciting and humbling seeing how people are using Claude Code. I just wanted to build a cool thing and it ended up being really useful and that was so surprising and so exciting.

XXI. Outro

HOST: My impression from Twitter or just the outside is basically everyone went away over the holidays and then found out about Claude Code and it's just been crazy ever since. Is that how it was for you internally? Were you having a nice Christmas break and then came back and like what happened?

BORIS: Well, actually for all of December, I was traveling around. And I took a coding vacation. So, we were kind of traveling around and I was just coding every day. So, that was really nice. And then I also started to use Twitter at the time because I worked on Threads back then, way back when. So, I've been a Threads user for a while. So, I just tried to see other platforms where people are. Yeah. I think for a lot of people they kind of discovered — that was the moment where they discovered Opus 4.5. I kind of already knew. And internally Claude Code's just been on this exponential tear for many many months now. So that just became even more steep. That's what we saw.

And if you look at Claude Code now, there was some stat from Mercury that 70% of startups are choosing Claude as their model of choice. There was some other stat from Semi Analysis that 4% of all public commits are made by Claude Code — of all code written everywhere. All the companies use Claude Code from the biggest companies to the smallest startups. It wrote — it plotted the course for Perseverance, the Mars rover. This is just the coolest thing for me. And we even printed posters because the team was like, "Wow, this is just so cool that NASA chooses to use this thing." So, yeah, it's just humbling. But it also feels like the very beginning.

HOST: What's the interaction between Claude Code and then Cowork? Was it a fork of Claude Code? Was it like you had Claude Code look at the Claude Code and say let's make a new spec for non-technical people that keeps all the lessons and then it went off for a couple days and did that? What's the genesis of that and where do you think that goes?

BORIS: This is going to be like my fifth time using the word latent demand. It was just that. We were looking at Twitter and there was that one guy that was using Claude Code to monitor his tomato plants. There was this other person that was using it to recover wedding photos off of a corrupted hard drive. There were people using it for finance. When we looked internally at Anthropic, every designer is using it. The entire finance team at this point is using it. The entire data science team is using it — not for coding. People are jumping over hoops to install a thing in the terminal so that they could use this. So we knew for a while that we wanted to build something and so we were experimenting with a bunch of different ideas and the thing that took off was just a little Claude Code wrapper in a GUI in the desktop app and that's all it is. It's just Claude Code under the hood. It's the same agent.

HOST: Oh wow.

BORIS: And Felix and the team — Felix was an early Electron contributor. He kind of knows that stack really well and he was hacking on various ideas and they built it in I think something like 10 days. It was just 100% written by Claude Code. And it just felt ready to release. There was a lot of stuff that we had to build for non-technical users. So it's a little bit different than a technical audience. It runs in a — all the code runs in a virtual machine. There's a lot of deletion protections and things like this. There's a lot of permission prompting and other guardrails for users. Yeah, it was honestly pretty obvious.

HOST: Boris, thank you so much for making something that is taking away all my sleep, but in return, it's making me feel creator mode again, sort of founder mode again. It's been an exhilarating 3 weeks. I can't believe I waited that long since November to actually get into it. Thank you so much for being with us. Thank you for building what you're building.

BORIS: Yeah, thanks for having me. And send bugs.

HOST: Sounds good.

Transcript source: "The Lightcone" (Y Combinator) — Inside Claude Code With Its Creator Boris Cherny. YouTube. Formatted for readability.

at
Labels: ,

Boris Cherny: What Happens After Coding Is Solved

Boris Cherny is the creator and head of Claude Code at Anthropic. What began as a simple terminal-based prototype just a year ago has transformed the role of software engineering and is increasingly transforming all professional work.

From "Lenny's Podcast" — hosted by Lenny Rachitsky.
Guest: Boris Cherny, Head of Claude Code at Anthropic.
Published: 2026

Table of Contents

Introduction to Boris and Claude Code

"100% of my code is written by Claude Code. I have not edited a single line by hand since November." — "Productivity per engineer has increased 200%." — "Coding is largely solved." — "I imagine a world where everyone is able to program. Anyone can just build software anytime."

LENNY: 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 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 discover 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.


I. Why Boris Briefly Left Anthropic for Cursor (and What Brought Him Back)

LENNY: Boris, thank you so much for being here and welcome to the podcast.

BORIS: Yeah, thanks for having me on.

LENNY: 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 two weeks later, you went back to Anthropic. What happened there? I don't think I've ever heard the actual story.

BORIS: 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 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 drove me to Anthropic also because before I joined Anthropic, 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 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.

II. One Year of Claude Code

LENNY: 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'm going 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 Semi Analysis 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.

BORIS: 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.

III. The Origin Story of Claude Code

BORIS: 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 AI 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 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 for 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 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 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 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, I have like a there's like a video recording of the demo because 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? Because it's like there's no — 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 figured out how to use it to answer this question that I had that I wasn't even sure if it 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 it got two likes. That was the extent of the reaction at the time because I think people internally you know like when you think of coding tools you think of IDE 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 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 — 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 felt 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 is 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 be open-minded and you had to learn to use it.

And of course now Claude Code is available 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 small startups to the biggest FAANG companies started using it and they started giving feedback and I think just reflecting back it's been such a humbling experience because we just keep learning from our users and just the most exciting thing is like none of us really know what we're doing. And we're just trying to figure 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.

IV. How Fast AI Is Transforming Software Development

LENNY: 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 AI is going to be written — 100% of code is going to be written by AI. Everyone's like no that's crazy what are you talking about. Now it's like of course it's happening exactly as they said. It's just — things move so fast and change so fast now.

BORIS: Yeah it's really fast. Back at Code with Claude back in May that was like our first 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 like at Anthropic like this is just the way we think about things is exponentials and this is like very deep in the DNA. Like if you look at our co-founders like 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 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.

V. The Importance of Experimentation in AI Innovation

LENNY: I thought was really interesting what you just shared there about kind of the journey is this idea of just playing around and seeing what happens. This came up with OpenAI 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.

BORIS: I mean this is the thing about innovation right like you can't force it. There's no road map 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. Because even in February when we released it, 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 on to something. And I was just spending like every night, every weekend hacking on this. And luckily my wife was very supportive. But it just felt like it was on to something. It wasn't obvious what. And sometimes, you know, you find a thread, you just have to pull on it.

VI. Boris's Current Coding Workflow (100% AI-Written)

LENNY: So at this point, 100% of your code is written by Claude Code. Is that kind of the current state of your coding?

BORIS: Yeah. So 100% of my code is written by Claude Code. I am a fairly prolific coder. And this has been the case even when I worked back at Instagram. I was like one of the top few most productive engineers. And that's actually that's still the case here at Anthropic.

LENNY: Wow. Even as head of the team.

BORIS: 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.

LENNY: Every day.

BORIS: 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 kind of at the point yet 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 kind of like you still do want some of these checkpoints like you still want a human looking at the code. Unless it's like pure prototype code that you know it's not going to run anywhere, it's just a prototype.

VII. The Next Frontier

LENNY: 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 the next big shift to how software is written that either your team's already operating in or you think will head towards?

BORIS: 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 largely solved. At least for the kind 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 like 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, like 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. Like 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 like 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 codebase every tech stack that people work on.

LENNY: 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?

BORIS: Honestly, the simplest thing is like open Claude Code or Cowork and point it at a Slack thread. You know, like for us, we have this channel that's all the internal feedback about Claude Code. Since we first released it, even in like 2024 internally, it's just been this fire hose of feedback. And it's the best. And like 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 like within a minute, within 5 minutes or whatever. And this just really fast feedback cycle, it encourages people to give more and more feedback. It's just so important because it makes them feel heard because 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 pointed 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."

LENNY: 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 we need — 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 like say Opus 4.6 or what's been the trajectory there?

BORIS: Yeah. Yeah, it's improved a lot. I think some of it is kind of like training that we do specific to coding. So you know obviously best coding model in the world and it's getting better and better like 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 like transfer where you teach the model to do X and it kind of gets better at Y. And the gains have just been insane. Like at Anthropic over the last year since we introduced Claude Code we probably — I don't know the exact number — we probably like 4x the engineering team or something like this but productivity per engineer has increased 200%. In terms of like pull requests and like this number is just crazy for anyone that actually works in the space and works on dev productivity because back in a previous life I was at Meta and one of my responsibilities was code quality for the company. So this is like all of our code bases — that was 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 like 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.

LENNY: What's also insane is just how normalized this has all been. Like 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 like so easy to get used to it. But it's important to recognize this is crazy.

VIII. The Downside of Rapid Innovation

BORIS: This is something like I have to remind myself once in a while. There's sort of like a downside of this because the model changes so — well there's actually like there's many kind 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 like old way of thinking about it and I even find that like new people on the team or even new grads that join do stuff in a more kind of like AGI-forward way than I do. So like sometimes for example I had this case like a couple months ago where there was a memory leak and so like what this is is you know like Claude Code the memory usage is going up and at some point it crashes. This is like 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 know use these special tools to see what's happening. And I was doing this and I was kind of like 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 was like, "Hey Claude, it seems like there's a leak. Can you figure it out?" And so like 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 like analyze it itself. It was sort of like 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 like 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.

IX. Principles for the Claude Code Team

LENNY: 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 describe 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.

BORIS: There's this interesting thing that happens also when you underfund everything a little bit because then people are kind of forced to Claude-ify and this is something that we see. So for work where sometimes we just put like one engineer on a project and the way that they're able to ship really quickly because they want to ship quickly. This is like an intrinsic motivation that comes from within — just wanting 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 kind of like one principle is 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.

LENNY: 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 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 you will get more out of the AI tooling if you have fewer people working on something.

BORIS: Yeah. If you hire great engineers, they'll figure out how to do it. And especially if you empower them to do it. This is something I actually talk a lot about with CTOs and kind of 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.

X. Why You Should Give Engineers Unlimited Tokens

BORIS: And now you're starting to see companies — like at Anthropic we have everyone can use a lot of tokens. We're starting to see this come up as like a perk at some companies. Like if you join you get unlimited tokens. This is a thing 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 like 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.

LENNY: So the advice here is just be loose with your tokens with the cost on using these models. People hearing this may be like of course he works at Anthropic. He wants 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.

BORIS: Yeah. And I think the reality is like at small scale you're not going to get like a giant bill or anything like this. Like 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's actually not a huge cost. As the thing scales up — so let's say they build 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.

LENNY: 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?

BORIS: 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 we're starting to see similar things. Yeah.

XI. Will Coding Skills Still Matter in the Future?

LENNY: Going back to coding, do you miss writing code? Is that something you're kind of sad about that this is no longer a thing you will do as a software engineer?

BORIS: It's funny for me, you know, like 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, like 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 like I learned to code so that I can cheat on a math test. That was like the first thing we had these like graphing calculators and I just programmed the answer into TI-83.

LENNY: TI-83 plus.

BORIS: Yeah. Exactly. Plus. Yeah. So I programmed the answers in and then the next math test whatever the next year that was just like too hard. I couldn't program all the answers in because I didn't know what the questions were. And so I had to write like a little solver so that it was a program that would just solve 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 like the beauty of programming. So like I wrote a book about TypeScript. I started what was at the time the world's biggest TypeScript meetup just because I fell in love with the language itself. And I kind of got in deep into like functional programming and all this stuff. I think a lot of coders they get distracted by this. For me, it was always sort of — 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 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 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 do things by hand if you want.

LENNY: 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 the way it's going to go?

BORIS: I think it's just the way that it happens. I don't worry about it too much personally. I think for me like programming is on a continuum and way back in the day software actually is like relatively new right. If you look at the way programs are written today like 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 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 literally pen and paper. It was like a room full of people that were doing math on paper. And so 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's just going to be kind of like the assembly code running under the programmer or something like this.

At an emotional level, I feel like I've always had to learn new things. And as a programmer, it's actually not — 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, this isn't true for everyone. And I think for some people, they're going to feel a greater sense of, I don't know, maybe like loss or nostalgia or atrophy or something like this.

LENNY: I don't know if you saw this, but Elon was saying that why isn't the AI just writing binary straight to binary? Because what's the point of all this programming abstraction in the end?

BORIS: Yeah, it's a good question. I mean, it totally can do that if you wanted to.

XII. The Printing Press Analogy for AI's Impact

LENNY: Oh, man. So, what I'm hearing here is in terms — 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.

BORIS: 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 analog for this because like 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 mental model for this? I think the thing that's come closest for me is the printing press. And so 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 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 it was their job of this very tiny percent of the population to do this. And at some point 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 100x over the next 50 years.

And if you look at literacy, it actually took a while because learning to read and write is quite hard. It takes an education system. It takes free time. It takes like 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 is 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 like 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. It's like this is sort of how I feel where I don't have to do the tedious work anymore of coding because this has always been sort of the detail of it. It's always been the tedious part of it and kind of like 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 coming up with ideas. It's talking to users. It's thinking about these big systems. It's thinking about the future. It's collaborating with other people on the team. And that's what I get to do more of now.

LENNY: 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. Like I've been doing a bunch of random little projects and anytime you get stuck just like help me figure this out and you get unblocked. Like I used to — I was an engineer early in my career for 10 years and I just remember spending so much time on like libraries and dependencies and 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 one two three four okay we got this.

BORIS: Yeah exactly exactly. I was talking to an engineer earlier today they're like they're writing some service in Go and it's been like a month already and they built up the service like it's working quite well and then I was like okay so like how do you feel writing it? He was like, you know, like I still don't really know Go, but — and I think we're going to start to see more and more of this. It's like if you know that it works correctly and efficiently, then you don't actually have to know all the details.

XIII. Which Roles Will AI Transform Next?

LENNY: 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 within either within tech like product managers, designers or even outside tech — where do you think AI is going next?

BORIS: I think it's going to be a lot of the roles that are adjacent to engineering. So yeah it could be like 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 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 starting just to get a sense of it for the first time. When I think back to 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 we do our work.

And then when I look at non-technical work today — or maybe semi-technical like product work and data science and things like this — when you look at the kinds of AI that people are using it's all these conversational AI, it's like 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 this means like 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 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.

LENNY: 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 of 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? Just are you hiring more than if you didn't have AI and just thoughts on jobs?

BORIS: 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, 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 minutia. 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 I again I just have to reach for these historical analogies. 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 — 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 it was about knowledge spreading. It was about written records that people used to communicate. There were no phones or anything like this. There was 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, like 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, 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 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.

XIV. Tips for Succeeding in the AI Era

LENNY: So, for folks hearing this that want to succeed and make it in this crazy turmoil we're entering, any advice? Is it play with AI tools, get really proficient at the latest stuff? Is there anything else that you recommend to help people stay ahead?

BORIS: Yeah, I think that's pretty much it. Experiment with the tools, get to know them, don't be scared of them. Just dive in, try them, be on the bleeding edge, beyond 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 product managers and so on, they cross over disciplines. So on the Claude Code team, everyone codes. 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 the 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.

LENNY: Do you find these three separate disciplines still useful as a way to think about the team? They're engineering, design, product management. Do you find like those, 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?

BORIS: I think in the short term it'll 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 versus our RPM does a little bit more coordination or planning or forecasting or things like this. Stakeholder alignment.

LENNY: Stakeholder alignment. Exactly.

BORIS: I do think that there's 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.

XV. Poll: Which Roles Are Enjoying Their Jobs More with 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 just asked — 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 are enjoying their job more and about 10% said they're enjoying their job less. Designers, interestingly, only 55% said they are enjoying their job more and 20% said they're enjoying their job less. Thought that was really interesting.

BORIS: That's super interesting. I'd love to talk to these people, both in the more bucket and the less bucket just to understand. Did you get to follow up with any of them?

LENNY: A few people replied and we're actually doing a follow-up poll that we'll link to in the show notes of going deeper into some of the stuff, but a lot of — there's like, you know, the factors that make it more fun and less fun. The designers, they didn't share a lot actually of just like the people that actually said why are you enjoying your job less? And I didn't hear a lot. So, I'm curious what's going on there.

BORIS: Yeah, I'm seeing this a little bit at Anthropic. I think everyone is fairly technical. This is something that we screen for when people join. We have a lot of technical interviews that people go through even for non-technical functions. And our designers largely 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.

LENNY: Yeah. So maybe if you're listening to this, leave a comment if you're finding your jobs less fun and enjoying your job less because what you're saying and what I'm hearing from most people, 70% of PMs and engineers are loving their job more. That's like if you're not in that bucket, something's going on.

XVI. The Principle of Latent Demand in Product Development

BORIS: Yeah. We do see that people use also different tools. So for example, our designers, they 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 exact Claude Code. So it's like the same agent and everything. We've had this for 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 this is 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. It's 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.

LENNY: Can you talk about that actually because I was going to go there. Explain what this principle is and what happens when you unlock this latent demand.

BORIS: 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 — she 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 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 kind of 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's 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 — 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 a traditional dating setup but people are just like 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 is 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 that was 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 like wedding photos. There was someone that was using it for — I think they were using it 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 Brendan had Claude Code on his computer. He just had a terminal up and I was shocked. I was like Brendan what are you doing? Like you figured out how to open the terminal which is — it's a very engineering product. Even a lot of engineers don't want to use a terminal. It's just like the lowest level way to do your work. Just really 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 a 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 the thing that I wanted 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 kind of 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 a model.

XVII. How Cowork Was Built in Just 10 Days

LENNY: 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. It came out I think it was used by millions of people pretty quickly — something like that being built in 10 days. Anything there, any stories there other than just it was you know we used Claude Code to build it and that's it?

BORIS: Yeah it's funny. Claude Code like I said when we released it was not immediately a hit. It became a hit over time and there was a few inflection points. So one was 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 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. Like we saw people using Claude Code for these non-technical things and we were trying to figure out what do we 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 Cowork — there's this very sophisticated security system that's built in and essentially these guardrails to make sure that the model does the right thing. It 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. 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 that will shape where the product goes in the future.

XVIII. The Three Layers of AI Safety at Anthropic

LENNY: 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 like a unique reason to start releasing things early that'll help you as you exactly describe 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.

BORIS: Yeah. And at Anthropic as a safety lab, the other dimension of that is safety because 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 can start — 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 and 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 four or 5 months or something before we released it because we weren't really sure — this is the first agent that, the first big agent that I think folks had released at that point. It was definitely the first 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 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 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 try it internally, it looks good, we try 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 release 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.

LENNY: 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 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 there's like this could be a whole podcast conversation is 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 and 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.

BORIS: 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 mechanistic interpretability. And the idea is at its core like what is your brain? What is it? It's a bunch of neurons that are connected. And so what you can do is like in a human brain or 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 this layer or this neuron maps to this concept, how particular concepts are encoded, how the model does planning, how it thinks ahead. A long time ago, we weren't sure if the model is 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 used 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's just something we're learning about all the time.

And at 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 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 just the lever that we have.

XIX. Anxiety When AI Agents Aren't Working

LENNY: 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, the agent has a question, I need to answer or it's blocked on something or I just — there's all this productivity I'm losing. I can't — 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?

BORIS: I always have a bunch of agents running. So at the moment I have like five agents running and at any moment like I wake up and I start a bunch of agents. Like the first thing I did when I woke up is like oh man I really want to check this thing. So I opened up my phone, Claude iOS app, code tab, 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 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.

LENNY: I love that you 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 — this is now coding. Coding now is describing what you want, not writing actual code.

BORIS: 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? And I remember reading something — this was maybe very early versions of ACM magazine or something — where people were saying no it's not the same thing, this isn't really coding.

XX. Boris's Ukrainian Roots

BORIS: And I kind of think about this like in the back — my family is 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 he told my mom growing up, told these stories of — or she told these stories that when she was growing up he would bring these punch cards home and there were 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 they would have been like well it's not really coding. But I think this is a field that just has always been changing in this way.

LENNY: I don't know if you know this, but I was born in Ukraine also.

BORIS: Oh, I don't know. Yeah. Which city?

LENNY: I'm from Odessa.

BORIS: Oh, me too.

LENNY: What? Yeah, that's crazy. Wow. Incredible. What a moment. Maybe related in some small way. What year did your family leave?

BORIS: We came in '95.

LENNY: Okay. We left in '88. A little earlier.

BORIS: Oh, yeah.

LENNY: What a different life that would have been to not leave, huh?

BORIS: Yeah. I just feel so lucky every day that I get to grow up here.

LENNY: Yeah. My family anytime there's like a toaster or a meal, they're just like "to America." It's like, okay, enough about that. But you get it, you know, once you start really thinking about what life could have been.

BORIS: Yeah. Exactly. We do the same toast, but it's still vodka.

LENNY: It's still vodka. Absolutely.

XXI. Advice for Building AI Products

LENNY: 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 like let them experiment. You also shared just advice generally of just build towards the model where the model is going, not to where it is today. What other advice do you have for folks that are trying to build AI products?

BORIS: 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 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 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 I don't know what to call this principle, but it's like 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 — just the bitter lesson. And actually for the Claude Code team we have this — 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 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, 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 — 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 six months from now, not for the model of today. And for the very early versions of the product, it just wrote so little of my code because I didn't trust it because it was like Sonnet 3.5, then it was like 3.6 or 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 — it used git 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 a 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.

LENNY: 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?

BORIS: I think that's a good way to do it. Like, obviously within an AI lab, we get to see the specific ways that it gets better. So, it's a little unfair, but we also try to talk about this. So, one of the ways that it's going to get better is it's going to get better and better at using tools and using computers. This is a bet that I would make. Another one is it's going to get better and better for running for long periods of time. And this is a place, like there's all sorts of studies about this, but if you just trace the trajectory or even for my own experience when I used Sonnet 3.5 back 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, 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 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 are 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.

XXII. Pro Tips for Using Claude Code Effectively

LENNY: So we 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 like a couple pro tips that you could share?

BORIS: 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. So, 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 because it can just do the same thing much faster with less correction, less handholding and so on. So that's the first tip — 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 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. And essentially the model would just go back and forth with you. Once the plan looks good, then you let the model execute. I auto-accept edits after that because if the plan looks 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 of course, we support every terminal. We support Mac, Windows, whatever terminal you might use, it works perfectly. But we actually support a lot of other form factors too 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 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 a terminal. It's the same Claude agent running everywhere.

XXIII. Thoughts on Codex

LENNY: 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? Just kind of competing in this very competitive space in coding agents.

BORIS: 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 to have more competition because people should get to choose and hopefully it forces all of us to do an even better job. Honestly, for our team though, we're just focused on solving the problems that users have. So for us, we don't spend a lot of time looking at competing products. We don't really try the other products. You kind of want to be aware of them. You want to know they exist but for me I just I 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.

XXIV. Boris's Post-AGI Plans

LENNY: Maybe a last question. So I talked to Ben Mann co-founder of Anthropic — what to talk to you about. He had a bunch of 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.

BORIS: 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 bike to the farmers market. And you know you bike by rice paddies and stuff. It was just a totally different speed than — 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 pickles. So in the town where we lived, it was actually like everyone made miso. Everyone made pickles. And so I actually got decently good at making miso. 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 because a batch of white miso takes like at least three months to make and a red miso is like 2, 3, 4 years. You just have to be very patient. You kind of mix it up and then you just 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.

LENNY: 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 — the future might be just going deep into miso, getting really good at making miso. Amazing.

XXV. Lightning Round and Final Thoughts

LENNY: Boris, this was incredible. I feel like we're brothers now from Ukraine. Before we get to a 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?

BORIS: Yeah, I think I would just underscore, for Anthropic since the beginning, this idea of 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 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, everything that's happening right now around Claude Code becoming this huge multi-billion dollar business and now all of my friends use Claude Code and they just text me about it all the time. So this thing getting kind of big and in some ways it's a total surprise because this isn't kind of the — 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, 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.

LENNY: 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 dollars in revenue. You think 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.

BORIS: Yeah. Yeah. It's crazy. And I mean the way that Claude Code has kept growing is honestly just the users. Like 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 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 for me this is the way that I love to spend my day is just talking to users and making it better for them.

Lightning Round — Books

LENNY: Well, Boris, with that we've reached our very exciting lightning round. I've got five questions for you. Are you ready?

BORIS: Let's do it.

LENNY: First question — what are two or three books that you find yourself recommending most to other people?

BORIS: I'm a reader. I would start with the 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 probably 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 could think of it as a historical artifact. You could think of it as something that will level you up.

LENNY: I love this never-before-mentioned book. My favorite.

BORIS: Oh, amazing. Okay. Second one is Accelerando by Charles Stross. This is probably — 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 a liftoff is starting to happen and starting to approach the singularity and it ends with this collective lobster consciousness orbiting Jupiter. And this happens over 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 Liu Cixin. So he's the guy that did Three Body Problem. I think a lot of people know him for that. I actually — I think Three Body Problem was awesome, but I actually liked his short stories even more. So, Wandering Earth is one of the short story collections and it 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 about it. So, it's just really really interesting to read and just beautifully written.

LENNY: It's so interesting how sci-fi has prepared us to think about where things are going. Just like it creates these mental models of like okay I see, I've read about this sort of world.

BORIS: Yeah. I think for me this is like the reason that I joined Anthropic actually because I was living in this rural place. I was thinking on these long time scales because everything is just so slow out there at least compared to SF. And just all the things that you do are based around the seasons and it's based around this food that takes many months. That's the way that social events are organized. That's the way you kind of organize your time. You go to the farmers market and it's like it's pimiento season and you know that because there's 20 pimiento vendors and then the next week the season is done and it's grape season and you kind of see this. So it's these long time scales and I was also reading a bunch of sci-fi at the time and just being in this moment I was like — just thinking about these long time scales. I know how this thing can go and I just felt like I had to contribute to it going a little bit better and that's actually why I ended up at Anthropic and Ben Mann was also a big part of that too.

LENNY: 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?

BORIS: This is Vernor Vinge, right?

LENNY: Yeah. It's great.

BORIS: Yes. Okay. That one's like so interesting from an AI AGI perspective. So few people have read that.

LENNY: Yeah. It's like a lot. Yeah. I like A Deepness in the Sky also. I think those are sequels, right?

BORIS: Yeah. Yeah. Yeah. I think so. Yeah. It's very long and complex to get into but so good.

Lightning Round — Movies, Products, Motto

LENNY: Okay. We'll keep going through the lightning round. Do you have a favorite recent movie or TV show you really enjoyed?

BORIS: 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 Liu Cixin, but the Three Body Problem series on Netflix I really loved. I thought that was a great rendition of the book series.

LENNY: So, the common pattern across AI leaders is no time to watch TV or movies, which I completely understand. Is there a favorite product you've recently discovered that you really love?

BORIS: I'm going to chill a little bit and just say Cowork because this is legitimately the one product that's been pretty life-changing for me. Just because I have it running all the time and the Chrome integration in particular is just really excellent. So it's been like it paid a traffic fine for me. It canceled a couple subscriptions for me. Just 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 — another podcast that I really love obviously besides Lenny is the Acquired podcast by Ben and David. It's just super awesome. I feel like the way that they get into 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.

Using Cowork — Practical Tips

LENNY: 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 one of the — someone went on paternity leave from Anthropic and he had it fill out these medical forms for him. These really annoying PDFs where it just loads up the browser, logs in, fills them out, and submits them.

BORIS: Yeah, exactly. And it actually just kind of works. Like we tried this experiment a year ago and it didn't really work because 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 an 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.

LENNY: 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.

BORIS: Exactly. For people that are just starting 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 start by having it use a tool. So like clean up your desktop or summarize your email or something like this or respond to the top three emails — like it actually just responds to emails for me now too. The second thing is connect tools. So if you say look at my top emails and then send Slack messages or put them in a spreadsheet or something or for example I use it for all my project management. So we have a single spreadsheet for the whole team. There's 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 prompt. It'll 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 start one task — I have this project management thing running, then I'll have it do something else, then something else and I'll kick these off and then I just go get a coffee while it runs.

LENNY: There's a post I'll link to that shares a bunch of ways people use what was previously Claude Code and now just you could do through Cowork because a lot of this is just like oh wow I hadn't thought I could use it for that. And I think a lot of this was also some of this was also inspired by you. You had this post about 50 non-technical use cases for Claude or something like this.

BORIS: 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, they were like, "Okay, it's pretty good."

LENNY: Wow. I did not know that. That is awesome. I've become an eval. Yeah. How does that feel?

LENNY: Amazing. I feel like I'm valuable to the future of AI.

Life Motto and Twitter

LENNY: Okay, two more questions. Do you have a favorite life motto that you often come back to in work or in life?

BORIS: 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 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 it's probably not a good idea. So I think this is the single advice that I give to co-workers more than anything too.

LENNY: And I feel like that alone could be its own podcast conversation. What is common sense? How do you build it? 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.

BORIS: 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 a very clean product. I really like that. I started using Twitter because I was bored. So my wife and I were traveling around in Europe for December. We were just kind of nomading around. We went to Copenhagen, went to a few different countries. And for me it was just like a coding vacation. So every day I was coding and that's my favorite kind of vacation just to code all day. It's the best. And at some point I just kind of got bored and I ran out of ideas for a few hours. I was like okay what do I want to do next? And so I opened Twitter. I saw some people tweeting about Claude Code and then I just started responding and then I was like okay maybe actually what I should do is just look for people — look for bugs that people have, maybe people have bugs or feedback they have and so kind of introduce myself, ask for — if people had a bunch of bugs and feedback and I think they were kind of surprised by the pace at which we're able to address feedback nowadays. For me it's just so normal like if someone has a bug I can probably fix it within a few minutes because I just start Claude and as long as the description is good it'll 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 that was 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.

LENNY: I saw complaints to Nikita Beer the other day on Twitter of just — they're posting many threads and it was breaking and just like oh man what's going on here.

BORIS: Yeah. Yeah. There was a bug. I hope it's fixed now.

Farewell

LENNY: 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?

BORIS: 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? What do you like? What do you want? I love hearing it.

LENNY: Amazing. Boris, thank you so much for being here.

BORIS: Cool. Thanks, Lenny.

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 lennispodcast.com. See you in the next episode.

Transcript source: "Lenny's Podcast" — Head of Claude Code: What happens after coding is solved | Boris Cherny. Formatted for readability.

at
Labels: ,
Subscribe to: Comments (Atom)