The engineer who built Claude Code on accidental origins, latent demand, the Bitter Lesson, and why he has not edited a single line of code by hand since Opus 4.5.
Posted
5 months ago
Duration
Format
Interview
educational
Views
222.6K
4.3K likes
57 · 43
Big Idea
The argument in one line.
Claude Code succeeded by building for the model six months out, reading latent demand instead of guessing features, and accepting that every scaffold you ship is temporary tech debt waiting to be erased by the next model release.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
A technical founder or solo builder who wants to understand how to work with LLMs as a force multiplier rather than a code autocomplete.
An engineer trying to calibrate when to scaffold around a model vs. wait for the next model to make the scaffolding obsolete.
A hiring manager rethinking what skills actually matter in an AI-native team -- strong opinions are now a warning sign.
Anyone building a developer tool today who needs a framework for what the model wants to do rather than what users say they want.
SKIP IF…
You want a step-by-step tutorial on using Claude Code -- this is a product philosophy conversation, not a how-to.
You are completely new to Claude Code and need context on what it is before hearing the creator discuss its design internals.
TL;DR
The full version, fast.
Claude Code started as a two-day terminal hack to understand the Anthropic API -- no grand plan, no UI ambition -- and only stayed in the terminal because every UI Boris could have built would have been obsolete in six months. The product philosophy that drove every subsequent feature (CLAUDE.md, plan mode, Teams, Cowork) is a single idea: latent demand. Watch what users are already trying to do; remove the friction; never ask them to do something new. The interview closes with a data point that has become a benchmark -- productivity per engineer at Anthropic grew 150% since Claude Code shipped -- and a prediction that the software engineer title itself will be the next thing to become obsolete.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Teaser clips from the interview; plan mode alpha drop before the formal intro.
01:45 – 02:38
02 · The most surprising moment
The terminal is still the primary interface; it was supposed to be the starting point, not the ending point. The fact that it actually got useful at coding was also not obvious.
02:38 – 05:38
03 · Origin story
Accidental CLI built to understand the Anthropic API; giving the model a bash tool from the docs was the spark; 'I felt this thing just wants to use tools.'
05:38 – 07:09
04 · Elegant simplicity of the terminal
No UI to go stale in six months. Organic internal adoption; Dario asked if engineers were being forced to use it because the usage chart was vertical.
07:09 – 09:00
05 · First use cases
Git automation, bash commands, Kubernetes ops, early unit test writing. Engineers started writing markdown files for themselves -- the latent demand origin of CLAUDE.md.
09:00 – 11:29
06 · What's in Boris' CLAUDE.md
Two lines: auto-merge approved PRs; post PRs to team Slack. Everything else is in the repo CLAUDE.md, updated many times per week. Recommendation: delete and start fresh when it gets bloated.
11:29 – 13:30
07 · Verbosity decisions
Tried removing bash output once; Anthropic employees revolted within a day. Verbose mode now in /config. Iterating on file read/search summarization -- some users still want the details.
13:30 – 15:44
08 · Beginner's mindset + hiring
Senior engineers rewarded for strong opinions now face a liability. Screen: 'tell me about a time you were wrong.' The engineer who asked Claude to debug a heap dump found the leak faster than Boris did manually.
15:44 – 19:31
09 · Hyper specialists vs generalists
Bimodal effective team structure. Daisy's story: gave Claude a testing harness before adding the feature, then had Claude write the feature. Quad Agent SDK automates code review, security review, issue labeling, production shepherding.
19:31 – 23:48
10 · Claude Teams + sub-agents
Uncorrelated context windows as test-time compute. Plugins built by a swarm over a weekend. Most agents today are sub-agents prompted by Claude. Parallel debugging agents calibrated by task difficulty.
23:48 – 28:38
11 · A world without plan mode
Plan mode is already entering itself automatically. The mechanism: one sentence added to the prompt. Boris uses plan mode in 80% of sessions, multiple tabs in parallel. With Opus 4.5+ once the plan is good it executes correctly almost every time.
28:38 – 32:07
12 · Tips for founders
Build for the model 6 months out not today. Read the Bitter Lesson. Scaffolding captures ~20% gain then gets erased. Claude Code has been entirely rewritten over and over; nothing from 6 months ago remains.
32:07 – 34:50
13 · Terminal lifespan + dev tool advice
Predicted a 3-month CLI lifespan; has been wrong every time. Claude Code is now web, desktop, iOS, Android, Slack, GitHub. Dev tool founders: figure out what the model wants to do and enable that.
34:50 – 37:50
14 · Claude Code and TypeScript parallels
TypeScript built around how JS devs actually wrote code. Claude Code built the same way. Terminal is written in React (Ink).
37:50 – 40:30
15 · Designing for the terminal
No DOM, 256 colors, one font size. Spinner went through ~100 iterations, 80 discarded. The luxury: 20 prototypes in a couple of hours vs. two weeks in Framer.
40:30 – 42:00
16 · Builder advice recap
Don't build for today's model; build for the model 6 months from now. The Bitter Lesson: never bet against the model. Scaffolding is always tech debt.
42:00 – 43:56
17 · Productivity per engineer
Anthropic team doubled; productivity per engineer grew 150% since Claude Code launched. Boris: 20 PRs/day, IDE uninstalled. Anthropic-wide: 70-90% of code written by Claude, 100% for many teams.
43:56 – 45:46
18 · Why Boris joined Anthropic
Living in rural Japan, Hacker News turned to AI. Drawn to being close to the model, not the product. Mission: wanted to be at the place that took AI safety seriously when ASL-4 happens.
45:46 – 48:30
19 · How coding will change
'Software engineer' title will disappear -- replaced by builder or product manager. Lower bound: coding solved for everyone. Upper bound: ASL-4 recursive self-improvement.
48:30 – 50:10
20 · Cowork origin + outro
Latent demand from designers, finance, data science all using Claude Code despite it being a CLI. Cowork built in 10 days, 100% written by Claude Code. Runs in a VM with guardrails.
Atomic Insights
Lines worth screenshotting.
The terminal form factor was supposed to be the cheapest possible starting point, not the destination -- it just never became obsolete.
CLAUDE.md should be as short as possible; delete it entirely when it gets bloated and add back only when the model actually goes off track.
Plan mode adds exactly one sentence to the system prompt: 'please don't code' -- there is no architectural magic behind it.
The first tool given to the Claude Code prototype was bash, copied verbatim from Anthropic's own documentation examples.
Productivity per engineer at Anthropic grew 150% since Claude Code launched, measured by pull request volume and commit lifetime.
The Claude Code plugins feature was built entirely by a multi-agent swarm over a weekend with no human intervention after the spec was handed off.
Most Claude agents running today were not launched by humans -- they were spawned by Claude itself as sub-agents.
A junior engineer asked Claude Code to debug a memory leak; it wrote its own heap dump analysis tool and found the leak faster than the senior engineer doing it manually.
Scaffolding around a model captures roughly 20% performance improvement, then gets erased by the next model -- it is always temporary tech debt.
TypeScript succeeded by modeling the type system around how JavaScript developers actually wrote code, not how type theorists thought they should; Claude Code followed the same design principle.
The terminal spinner in Claude Code went through approximately 100 iterations before shipping, 80 of which were discarded.
Boris personally lands 20 pull requests a day and has uninstalled his IDE entirely -- zero lines of code written by hand since Opus 4.5.
Cowork was built in 10 days, 100% written by Claude Code itself, after observing non-technical teams jumping through hoops to use the CLI.
The hiring screen that matters most now: 'tell me about a time you were wrong' -- strong opinions held rigidly are the modern red flag.
Never bet against the model: the more general model always beats the more specific one, which means scaffolding is a trade-off, not an investment.
Takeaway
Build for where the model is going, not where it is.
WHAT TO LEARN
Every scaffold you build today is temporary -- the discipline is knowing which scaffolds are worth the trade-off and which ones you should just wait out.
03Origin story
The fastest path to a product insight is often to build the cheapest possible version to understand the capability -- not to plan the right architecture first.
Giving a model a general tool and watching what it chooses to do with it reveals the capability boundary faster than targeted evals.
06What's in Boris' CLAUDE.md
A minimal CLAUDE.md outperforms an elaborate one -- delete it when it gets bloated, add back only when the model demonstrably goes off track.
Repo-level CLAUDE.md updated by the whole team catches preventable mistakes faster than any code review process.
07Verbosity decisions
Removing information that users 'don't need' often removes the signal they use for fast error detection -- test any summarization change with real users before shipping.
Offering a verbose mode as an opt-in satisfies power users without imposing noise on casual ones.
08Beginner's mindset + hiring
The skill that matters most for working with LLMs is beginner's mindset: the ability to recognize when a held opinion is no longer valid and to update it without ego.
A behavioral interview question about being wrong reveals more about AI-era fit than any coding assessment.
09Hyper specialists vs generalists
Before implementing a feature, consider whether you can first give the agent a tool to verify the feature works -- then let the agent implement it.
The most effective teams are bimodal: extreme specialists and extreme generalists; the undifferentiated middle is weak.
10Claude Teams + sub-agents
Parallel agents with uncorrelated context windows are a practical form of test-time compute that scales capability without scaling the model.
For complex tasks, calibrate the number of sub-agents by difficulty rather than trying to prompt a single instance harder.
12Tips for founders
Features built around a model's current weakness capture roughly 20% improvement then get erased by the next model release; treat scaffolding as short-term debt.
Build for the capability boundary the model will cross in the near future, not its current capability -- otherwise you risk finding PMF then being leapfrogged.
18Productivity per engineer
Productivity metrics can now move 150% in a year; teams that measure output by commits or PRs rather than headcount will notice this signal first.
The ceiling is 100% AI-generated code with zero lines written by hand -- that is not a hypothetical; it is the current state for some engineers.
19How coding will change
When coding is a solved capability, the differentiating skills become product sense, user empathy, and systems thinking -- not syntax fluency.
The software engineer title dissolving into 'builder' is not a demotion; it is an expansion of what the role can do.
Glossary
Terms worth knowing.
Latent demand
A product principle holding that people will only adopt behavior they already exhibit in some form; good products identify what users are already trying to do and remove friction, rather than asking them to do something entirely new.
Scaffolding
Code or product features built around a model to boost its performance in a specific domain, distinct from the model itself; considered temporary because model improvements typically erase the gains within months.
The Bitter Lesson
A 2019 essay by Richard Sutton arguing that general methods leveraging computation always outperform approaches encoding human domain knowledge; a framed print of it hangs on the Claude Code team wall.
Uncorrelated context windows
A multi-agent architecture where each agent starts with a fresh context, preventing earlier reasoning from polluting later reasoning; described as a form of test-time compute that scales capability.
Plan mode
A Claude Code mode that instructs the model to reason and plan without executing any code; mechanically implemented as a single added sentence in the system prompt.
Sub-agent
In the Claude Code context, a recursively spawned Claude Code instance prompted by a parent Claude (called 'mama Claude') rather than by a human; the dominant form of agent launch in practice.
ASL-4
Anthropic Safety Level 4 -- an internal safety threshold defined by the model being capable of recursive self-improvement; reaching it triggers mandatory safety criteria before a model can be released.
CLAUDE.md
A markdown file read by Claude Code at session start, containing project-specific or personal instructions; Boris keeps his personal file to two lines and puts everything else in the repo-level file.
42:00 – 50:10denseProductivity data, joining Anthropic, future of coding
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
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. That's actually, like, still my advice to to founders that are building on LLMs.
Just try to think about, like, what is that frontier where the model is not very good at today? Because it's gonna get good at it. All of quad code has just been written and rewritten and rewritten and rewritten over and over and over.
There is no part of quad code that was around six months ago. 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. Are you also in the back of your mind thinking that maybe, like, 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? Maybe in a month.
No more need for plan mode in a month? Oh my god.
Welcome to another episode of the Light Cone. And today, we have an extremely special guest, Boris Czerny, the creator, engineer of Claude Code.
Boris, thanks for joining us. Thanks for having me. Thanks for creating a thing that has taken away my sleep for about three 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?
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 quad code, and I didn't yet know if I was onto something, I kinda felt like I was onto something.
And then that's when I wasn't sleeping. Okay. And I was just like When was that?
Three straight months. This was September 2024.
Yeah. It was like three straight months. I 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 gonna be a thing. I don't know if it's useful yet because it it couldn't actually code yet.
If you look back on those moments to now, like, what would be, like, the most surprising thing about this moment right now? 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, you know, at the beginning, it didn't really write code.
Even in February when we GA'd it, 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 it it actually, like, our bets paid off, and it got good at the thing that we thought it was gonna 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 six months from now, and that's actually, like, still my advice to to founders that are building on LLMs is, you know, just try to think about, like, what is that frontier where the model is not very good at today?
Because it's gonna get good at it, and you just have to wait. Going back, but when do you remember when you first got the idea? Can you just talk us through that?
Like, was there something like a spark, or what was even the first version of it in your mind? You know, it's funny. It was like, it was so accidental that it it just kinda evolved into this.
You know, I I as Anthropic, I think for Ant, the bet has been coding for a long time, and the bet has been the path to save to save AGI is through coding. And this is this is kinda always been the idea.
And the way you get there is you 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 kinda see that because the the first team that I joined at Anthropic is called Anthropic Labs team, and it produced three products.
It was QuadCode, MCP, and the desktop app.
So you can kinda see how these, like, weave together. The particular product that we built, you know, like, no one 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, like, even crazier because like no one had built this yet.
And so I I started like hacking around and the the 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 I just feel like 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, you know, AI applications at the time, and you know, for non coders today, what what are most people using is just a chat app, so that's what I built. And, you know, it was in a terminal.
I can ask questions. I gave answers. Then I think tool use came out.
I just wanna try out tool use because I I don't really understand what this is. I was like, tool use, this is cool. Is this actually useful?
Probably not. Let me just try it. You put it in terminal just because it was the easiest way to get something up and running?
Yes. Because I didn't have to build a UI. Okay.
So it was just me. At that point, it was like the IDEs, cursor, windsurf were the things that were really taking off where you sort of under any pressure or getting lots of suggestions of, hey, like, we should build this out as a plug in or as a as a fully featured IDE itself? There was no pressure because we didn't even know what we wanted to build.
Like, the the team was just in explore mode. You like, know, we we didn't we know vaguely we wanted to do something in coding, but it wasn't obvious what no one was high confidence enough. That was, like, my job to figure out.
And so I gave I gave the model the bash tool. That was the first tool that that I gave it. Just because I think that was literally the example in our docs.
Docs. It just, like, took the examples in Python. I just ported it to TypeScript because that that's how I wrote it.
You know, I didn't know, like, what the model could do with batch, so I asked it to, like, read a file. It could, like, cap the files. Like, that was cool.
And then I was like, okay. Like, what can you actually do? And I and I asked it, what music am I listening to?
You wrote some, like, Apple script to script my my Mac and look up the music in my music player. Oh my god.
And this was Son of 3.5. And, you know, like, I I didn't think the model could do that.
And that was my first, I think, ever fuel the AGI moment. Whereas it's like, oh my god. The model, it it just wants to use tools.
That that's all it wants. That's kind of fascinating. I mean, it's very kinda
contrarian that Clockroach works so well in such a elegant, simple form factor.
I mean, 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. Like, it doesn't feel like working.
It just feels fun as a developer. I don't didn't give a files where everything is,
and that came by accident almost. Yeah. It was an accident.
I remember so after the terminal started to take off internally, and honestly, like, after building this thing, think, like, two days after the first prototype, I started giving it to my team just for dog fitting. Because, you know, like, you know, if you come up with an idea and it seems useful, the first thing you wanna do is you wanna give it to people to see how they use And then I came in the next day, and then Robert, sits across from me, he's another engineer, he he just, like, had quad code on his computer, and he was, like, using it to code.
I was like I was like, what? What are you what are you doing? Like, this thing isn't ready.
It's just a prototype. But, yeah, it it was already useful in that form factor. And I remember when we did our launch review to kinda launch quad code externally, this was in December, November, or something like that in 2024.
Dario asked, and he was like, the Ushis chart internally, like, the Dow chart is, like, vertical. Are you, like, forcing engineers to use it? Like, why are you mandating them?
And I was just like, no. No. We didn't.
We I just, like, posted about it, and they they've just been, like, telling each other about it. Honestly, it was it was just accidental. We we started with the CLI because it was the cheapest thing, and it just kinda stayed there for a bit.
So in that 2024
period, what how were the engineers using it? Were they shipping code with it yet, or were they using it in a different way?
The model is not very good at coding yet.
I I was using it personally for automating Git. I think at this point, I I probably forgotten most of my git because Glatico has just been doing it for so long.
But, yeah, like automating bash commands, that that was a very early use case and, like, operating, like, Kubernetes and kinda things like this. People were using it for coding, so 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, the model was still pretty bad at it.
But people were were were kind of figuring it out, and they 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 QuadMD 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 their initial CLI.
And so QuadMD 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 20%, something like that.
And then, essentially, the gain is wiped out with the next model. So either you can build build the scaffolding and then, you know, get some performance gain and then rebuild it again, or you just wait for the next model and then you kinda get it for free.
The QUADMD 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 six months because the model was improving so quickly. Earlier, we were saying, like, we should compare Cloud MDs, but you said something very profound, is, you know, yours is actually very short, which is almost like the opposite of what, you know, people might expect.
Why is that? What's in your CloudMD? Okay.
So I I checked this before we came. So my my CloudMD has two things. One is there it it it's just two lines.
So the first line is whenever you put up a PR, enable auto merge. So as soon as someone accepts it, it's merged. That's just so I can, like, code, and I don't have to kinda go back and forth with CR or whatever.
And then the second one is whenever I put up a PR, post it in our internal team's stamps channel just so someone can stamp it, and I can get unblocked. And the idea is every other instruction is in our QuadMD that's checked into the code base, and it's something our entire team contributes to multiple times a week. And very often, I'll see someone's PR, and they they make some, like, mistake that's totally preventable.
And I'll just literally tag Claude on the PR. I'll just do, like, add Claude, you know, like, add this to the ClaudeMD, and I'll do this, you know, like, many times a week.
Do you have to, like, compact the ClaudeMD? Like, I definitely reached the point where I got the message at the top saying, your CLODMD is, like, thousands of tokens now. What do you do when you guys hit that?
So our CLODMD is actually pretty short. I think it's, like, couple thousand tokens, maybe something like that. If you if you hit this, my recommendation would be delete your CLODMD and just start fresh.
Interesting. I think a lot of people, like, they try to overengineer this. Right?
And and really, like, 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 QuadMD and then, you know, the model is getting off track, it does the wrong thing, that's when you kinda add back a little bit at a time.
And you what you're probably gonna find is with every model, have to add less and less. For me, I consider myself a pretty average engineer, to be honest. Like, I don't use a lot of fancy tools.
Like, I I don't use, like, VIM. I use, you know, Versus Code because it's some port.
I don't really Really? I would have assumed that because you built this in the terminal that you were sort of like a diehard terminal,
like, VIM VIM only person, you know, Screw those Versus code code people. You know? Well, we have people like that on the team.
There's, you know, like Adam Wolf, for example, he's on he's on the team. He's like, you will never take VIM for my cold, dead hands. Yeah.
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 quad 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 quad code, you don't have to understand BIM. You don't have to understand TMX.
You don't have to know how to, like, 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 it'll do all the stuff. How do you decide how verbose you want, like, sort of the terminal to be? Like, sometimes you have to go, you know, control o and check it out.
And is it, like, internal bike shed battles around, like, longer or shorter? I mean, every every user probably has a different opinion. Like, how do you make those sorts of decisions?
What what's your opinion? Is it is it too verbose right now? Oh, I love the verbosity because, basically, sometimes it just, like, 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, like, stops an entire bug farm, like, as it's happening. I mean, that's usually when I didn't do plan mode properly.
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, like, 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 wanna see my dash because it it actually is quite useful for, you know, like, for something like git output, maybe it's not useful. But if you're running, you know, like, Kubernetes jobs or something like this, you actually do wanna see it.
We recently hit the hit the file reads and file searches. So you'll notice instead of saying, you know, like, read food dot m d, it'll said, you know, like, read one file search search 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 you know, it still read the wrong thing pretty often. As a user, you still have to be there and kinda 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. Like, I wanna see the details, and that was really great feedback. And so we added a new verbose mode, and so that's just like in slash config, you can enable verbose mode.
And if you wanna see all the file uploads, can continue to do that. And then I posted on the issue, and people still still didn't like it, which is, again, awesome because, like, my favorite thing in the world is just hearing people's feedback and hearing how they actually wanna use it. And so we just, like, iterated more and more and more to get that really good and to make it the thing that people want.
I'm amazed, like, 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 that, you know, this particular object. It messed up in this way, and it, like, searches the log. It figures everything out.
It can, like, go into your you can make a production tunnel and look at your production DB for you. Like, this is insane. Bug fixing is just going to Sentry copy markdown.
You know? Pretty soon, it's just gonna be straight MCP. It's like an auto bug fixing, like, end test making sort of what's the new term they call it?
Like, making a startup factory. Oh, yeah. Right?
There's, like, all these concepts now of rather than having to review the code. You know? I'm 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, like, anytime an a real human being has to look at code,
that's bad. Yeah. Yeah.
Yeah. It's fascinating. I think, like, Dan Chipper talks about this a lot as kind of whenever you see the model make a mistake, try to put in a QuadMD, try to put it in skills or something like this so it's reasonable.
But I I think there's this meta point that I actually struggle with a lot. And I people talk about, like, 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, they actually use quad code more than I would have used it.
And I'm just constantly surprised by this. Like, for example, there was a we had, like, a memory leak, and we were trying to debug it. And by the way, like, 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 I was trying to debug it, and so I 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 I was just trying to figure this out. And then another engineer on the team, Chris, he just, like, asked QuadCode.
He was like, hey. I think there's a memory leak. Can you, like, run this and then, like, try to figure it out?
And QuadCode, like, took the heap dump, threw it, wrote a little tool for itself to, like, 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. So what would be some advice for technical founders to really become maximalists at the latest model release?
It sounds like people off of fresh off of school or that 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? I think for yourself, it's kinda beginner mindset. And I don't know.
Maybe just, like, humility. Like, I I feel like engineers as a discipline, we've learned to have very strong opinions, and senior engineers are kinda rewarded for this. In my old job at a big company when I hired, like, architects and this kind of 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 the biggest skill is people that can think scientifically and can just think from first principles. How do you screen for that when you try to hire someone now for for your team?
I sometimes ask about what's an example of when you're wrong. It's a really good one. You know, some of these, like, classic behavioral questions, like, 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 learn something from it. And I think a lot of these, like, very senior people, especially there 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 they'll never take the blame for a mistake. But I don't know.
Like, 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 know, you try a thing, you give it to users, you talk to users, you learn. And then eventually, might end up at a good idea.
Sometimes you don't. And this is the skill that I think in in the past was very important for founders. But now I think it's very important for every engineer.
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. Yeah.
We just added just as a test, like, you can upload a transcript of you coding a feature with Claude code or codex or whatever it is. Personally, I think that, like, it's gonna work.
I mean, you could figure out how someone thinks, like, they're looking at their logs or not. Like, can they correct the agent if it goes off off the rails? Like, do do they use plan mode?
You know, when they use plan mode, do they make sure that there are tests or you know, all of these different things that, you know, do they think about systems? Do they even understand systems? Like, there's just so much that's sort of embedded in that that I imagine.
I just want, like, a spider a spider web graph, you know, like in those video games like NBA two k. It's like, oh, this person's really good at shooting or defense. It's like, you can imagine a spider web graph of, like, you know, someone's Claude code skill level.
Yeah. What would what would the skills be? What would those assets?
I think it's like systems testing. Must be like user behave.
I mean, there's gotta be a design part. For sure. Like product sense.
Maybe maybe also just like automating stuff. Mhmm. My favorite thing in CloudMD for me is I have a thing that says, for every plan, decide whether it's overengineered, underengineered,
or perfectly engineered, and why. I this is something that we're trying to figure out too because I I think 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, like, I named Jared before. Like, he's a really good example of this, and kind of the Bund 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 generalist, and that's kind of the rest of the team.
And a lot of people, they span, like, product and info or product and design or, you know, like, 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? Mhmm. That's the limits test.
Yeah. That's the limits test. But but nowadays, like, 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 QuadCode, like, a couple weeks after she joined or something, and the PR was to add a new feature to QuadCode.
And then instead of just adding the feature, what she did is first, she put up a PR to give QuadCode 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 Quad write its own tool instead of herself implementing it. And I think it's this kind of out of the box thinking that is is just so interesting because not a lot of people get it yet.
You know, like, we use the Quad Agent 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 LMs in this way.
How do you use this new kind of automation?
So it's kind of a new skill. I guess one of the funnier things that I've been having office hours with various founders about is you you have, like, sort of the visionary founder who has, like, the idea.
They've, like, built this, like, crystal palace of the product that they wanna build. They've totally loaded in their brain, you know, 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, you know, 50 x work. And then but they have engineers who work for them who, like, don't have the, you know, crystal memory palace of, like, the platonic ideal of the product that the product founder has, and they can only do, like, five x work. Are you hearing stories like that?
There's usually a person who's, like, the core, like, designer of a thing, and they're just, like, you know, trying to blast it out of their brain.
What's the nature of, like, teams like that? You know, it it seems like that's almost a stable configuration. Like, you're gonna have the visionary who, like, now is unleashed.
But, you know, maybe going back to the top of it, like, I'm experiencing this right now. It's like, oh, well, I'm only a solo person,
and, you know, I need to eat and sleep, and I have, you know, a whole job. And it's like, how am I gonna do this? You know?
You know, like, we just launched QuadTeams. And, you know, this is a way to do it, but you can also just build your own way to do it. It's pretty easy.
What's the vision for Cloud Teams? Just collaboration. It's like there's this whole new field of, like, agent topologies that people are exploring.
Like, what are the ways they 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 just actually 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 like 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 plug ins feature was entirely built by a swarm over over a weekend. It just ran for, like, a few days.
There wasn't really human intervention,
and plug ins is pretty much in the form that it was when when it came out. How did you set that up? Like, did you spec out sort of the outcome that you were hoping for and then let it sort of figure out the details and then, like, let it run?
Yeah. An engineer on the team just gave
gave Quad a spec and told Quad to use Asana board. And then Quad just put up a bunch of tickets on Asana and then spawned a bunch of agents, and the agents started picking up tasks.
I mean, Quad just gave it instructions, and they all just figured it out. The independent
agents that didn't have the context of the bigger spec. Right? Right.
If you if you think about the way that
you know, like, how our agents actually started nowadays and, you know, 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 like a sub agent is just like 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 that's all it is. And I I think probably if you look at most agents that are launched in this way. My Claude Insights just told me to do this more for debugging.
So that I get like, I spend a lot of time on debugging, and it would just be better to have, like, multiple sub agents spin up and, like, debug something in parallel. And so then I just, added that to my Claude MD to just be, hey, like, next time you try and fix a bug, like, have one agent that, like, looks in the log, like, one that looks in the code path.
That just seems sort of inevitable. For weird, scary bugs, I try to fix bugs in plan mode, and then it seems to use the agents to sort of Yep. Search everything.
Whereas, like, when you're just trying to do it in line, it's like, okay. I'm gonna do, like, this one task instead of search wide. This is something I do all the time too.
I I just say, if the if the task seems kinda 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, like, really hard, I'll say, like, use three or maybe five or even 10 sub agents. Research in parallel, and then see what they come up with.
I'm curious. So then why don't you put that in your ClaudMD file? It's kinda case by case.
You know? Like,
ClaudMD, like, what is it? It's just a it's a shortcut.
Like, if you find yourself repeating the same thing over and over, you put in the ClaudMD.
But, otherwise, you don't have to put everything there. You can just prompt Quad. Are you also in the back of your mind thinking that maybe, like, in six months, you won't need to prompt that explicitly?
Like, the model should be good enough to go out on its own. Maybe in a month.
No money for plan mode in a month? Oh my god. I think plan mode probably has a limited lifespan.
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? Yeah. We've we've started experimenting with this because quad code can now enter plan mode by itself.
I don't know if you've you guys have seen that. Yeah. So we're we're trying to kind of 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 like I think it's something like this. But actually, plan mode, there's no 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 you can actually just say that. Yeah.
So it sounds like a lot of the feature development for Cloud Code is very much
when we talk about OIC. Talk to your users Mhmm. 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. Yeah. Yeah.
I mean, that that's all it was. Like, plan mode was we saw users that that were like, hey, Claude. Come up with an idea.
Plan this out, but don't write any code yet. And there was kind of various versions of this. Sometimes it was just talking through an idea.
Sometimes it was these very sophisticated specs that that they were asking Claude to write. But the common dimension was do a thing without coding yet. And so literally, like this was, like, Sunday night at 10PM.
I was I was just, like, looking at GitHub issues and kinda seeing what people were talking about and looking at our internal Slack feedback channel. And I just wrote this thing in, like, thirty minutes and then shipped it that night. It went out Monday morning.
Those plan modes. So do mean that there'll be no need for plan mode to in the sense of I'm worried that the model's gonna do like, it's gonna do, like, 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. I kinda think about it in terms of, like, kinda increasing model capabilities.
So maybe six 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 kinda sit there and babysit because it can go off Nowadays, I do is probably 80% of my sessions I say I say plan mode has a limited way of spend, but I'm I'm a heavy plan mode user.
I probably 80% of my sessions, I start in plan mode, and Claude will, you know, little story. He'll 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, 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, you know, like, 80% of the time. Once the plan is good and sometimes it takes a little back and forth, they just get quad to execute.
And nowadays, what I find with Opus 4.5, I think it started with 4.6 that 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, you know, 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 kinda give a prompt, and Claude will figure it out. The next step is Claude just speaks to your users directly. Yeah.
It just bypasses you entirely. It's funny. This is actually the current stuff for us.
Our quads actually, like, they talk to each other. They talk to our users on Slack, at least internally pretty often. My quad will, like, tweet once in a while.
No way. But I actually, like, delete it. It's just like it's a little, like, cheesy.
Yeah. It like, I don't love the tongue. What does it want to tweet about?
Sometimes it'll just, like, respond to someone. Because I always have, like, coworker running in the background, and it's, it's the coworker Claude that really loves to do that because it likes using a browser. That's funny.
A really common pattern is I ask Claude to build something. It'll look in the code base. It'll see some engineer touch something in the Git plane, and then it'll message that engineer on Slack just like asking a clarifying question.
And then once it gets the answer back, it'll keep going. What are some tips for founders now on how to build for the future? Sounds like everything is really changing.
What are, like, some principles that will stay on and what will change? So I think some of these are pretty are pretty basic, but I think they're even more important now than they were before. So one example is latent demand.
Like, I mentioned it a thousand times for me. It's just like the single biggest idea in product. It's a it's a thing that no one understands.
It's a thing I certainly did not understand my first few startups. And and the idea is, like, 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 if people are doing a thing and you try to make them do a different thing, they're not gonna do that. And so you just have to make the thing that they're trying to do easier.
And I think Quad is gonna get increasingly good at kind of figuring out these kind of product ideas for you just because it can look at feedback. It can look at debug logs. It can kinda figure this out.
That's what you mean by plan mode was latent demand that people already, like, kinda had their clawed chat window open in the browser and were, like, talking to it to figure out, like, the spec and and what it should do.
And
now it's they're, like, plan mode just became that. You just do it in clawed code. Yeah.
Yeah. That's it. Some sometimes what I'll do is I'll just walk around the office on on our floor, and I'll just kind of stand behind people.
I I'll say, like, hi. So it's not great.
And then I'll I'll just see kind of, like, how they're using quad 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. It seems like you're surprised how far the terminal
has gone and how far it's been pushed. Like, how far do you think it has left to go? Just given with this world of swore multiple agents, like, do you think there's gonna be a new
a need for a different UI on top of it? 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 gonna move on to the next thing.
And you can see us experimenting with this. Right? Because QuadCode started in a terminal, but now it's in you know, it's on web.
You can like, Quad AI slash code. It's in the desktop app. You know, we've had that for, you know, like, three months or six months or something just in the code tab.
It's in the iOS and the Android apps just like in the code tab. It's in Slack. It's in GitHub.
There's Versus Code extensions. There's JetBrains extensions. So we're just like 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.
What about, like, your advice to DevTool founders? Like, someone's building a DevTool company today. Should they just, like, be building for engineers and humans, or should they be thinking more about, like, what Claude's
gonna think and want and build for sort of, like, the agent? 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, you know, like, when I first started hacking on quad code, I I realized, this like, thing just wants to use tools.
It just wants to interact with the world. And how how do you 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, like, for if you're building a dev tool startup, I would think about, like, what is the problem you wanna solve for the user?
And then when you use 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 weight and demand of both? YC's next batch is now taking applications.
Got a startup in you? Apply at ycombinator.com/apply. It's never too early, and filling out the app will level up your idea.
Okay. Back to the video.
Back in the day, more than ten 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 early twenty tens. Right? Yeah.
Something like that. Before TypeScript was a thing because back then is 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 ClotCode in the terminal has a lot of parallels with TypeScript at the beginning.
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, like, this is super weird because, like, even though, like like, Haskell doesn't even do this. It's just, like, it's too extreme Or it has like conditional types, which I don't think any language thought of at all.
It was like very strongly typed. Yeah. It was very strongly that.
And and the the idea was like when, you know, like when Joe Paymer and Anders and the early team was like building this thing. The way they built it is we okay. We have these teams with these big untyped JavaScript code bases.
We have to get types in there, but we're not gonna get engineers to change that the the way that they code. You're not gonna get JavaScript people to have, like, you know, 15 layers of class inheritance like you would a Java programmer. Right.
They're gonna write code the way they're gonna write it. They're they're gonna use reflection, and they're gonna use mutation. And they're gonna use all these features that traditionally are very, very difficult to type.
They're a very unsafe type to any strong functional programmer, really. That's right. That's right.
That's right. And so the thing that they did, instead of getting people to kinda change the way that they code, they they built a type system around us. And it was just it's brilliant because there's all these ideas that no one was thinking about.
Even in academia, like, 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, you know, for for quad code, there there are some ideas that are kinda similar in that, you like, you can use it like a Unix utility.
You can pipe into it. You can pipe out of it. In in some ways, is kinda rigorous in this way, but in in almost every other way, it's just the tool that we wanted.
Like, I I built a tool for myself, and then the team built the tool for themselves, and then for Anthropic employees, and then for users. And it just ends up being really useful.
It's not it's not this, like, principled and academic thing. Which I think the
the proof is actually in the results now. Fast forward more than fifteen years later, not many code bases are in Haskell, which is more academic.
And there's tons of them now in TypeScript because it's way more practical Right. Which is interesting. Yeah.
It is interesting. Right? It's like TypeScript solves a problem.
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. When I first started building it, you know, like, I I did front end engineering for for a while. So and I was also, like, a you know, I'm I'm sort of like a hybrid, like, I I do like design and user research and, you know, write code and all the stuff.
And we love hiring engineers that are like this. So we just we 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, like, how do I build a thing for people like me that, you know, are are gonna 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 like 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 kinda has to do both. Designing for the terminal, honestly, has been hard.
Right? It's like a it's like 80 by a 100 characters or whatever. You have, like, 256 colors.
You have one font size. You You don't have, like, mouse interactions. There's all this stuff you can't do, and there's all these very hard trade offs.
So, like, a little known thing, for example, is you can actually enable mouse interactions in a terminal. So you can enable, like, clicking and stuff. Oh, how do you do that in Cloud Code?
I've been trying to figure out to do this. We don't we don't have it in Cloud 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 so there's all these weird trade offs because, like, the way terminals work is, like, there's no DOM. Right? It's like there's, like, anti escape codes and these kind of weird organically evolved specs since, the nineteen sixties or whatever.
Yeah. It feels like BBSs. It's like a BBS door game.
Yeah. Yeah. Yeah.
Oh my gosh. That's like that that's like a great compliment. Yeah.
Yeah. Like, it should feel like you're discovering Lord of the Red Dragons. Fantastic.
Oh my god. Yeah. But we have we've had to just, like, discover all these kind of UX principles for building the terminal because no one really writes about this stuff.
And if you look at the big terminal apps of, you know, like, the eighties or nineties or February or whatever, These, like, Ed Curses, and they have all these, like, windows and things like this. And it just looks kinda, like, janky by modern standards. It just looks too heavy and complicated.
And so we had to, like, reinvent a lot. And, you know, for example, something like the terminal spinner, like, just like the spinner words, it's gone through probably, I wanna say, like, 50, maybe a 100 iterations at this point, and probably 80 of those didn't chip.
So we tried it. It didn't feel good. Move on to the next one.
Try it. It didn't feel good. Move on to the next one.
And this was, like, sort of one of the amazing things about quad code. Right? It's like, you can write these prototypes so you can just 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, like, learn to use Origami or Framer or something like this. You built, like, maybe three prototypes. It took, like, two weeks.
It just took much, 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, like, joyous and that people like to use. Boris, you had other advice for for builders, and we kept interrupting you because we have so many questions.
But I would say so okay. So maybe two pieces of advice that are kinda weird because it's, like, about building for the model.
So one is don't build for the model of today. Build for the model of six months from now. This is, like, sort of weird.
Right? Because, like, 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 gonna 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, fill out the boundary of what it can do, and then build for the model that you think will be the model maybe six months from now. I think the second thing is, know, you actually, in the in the quad code we're in the quad code area where we sit.
We have a framed copy of the bitter lesson on the wall, and this is this, like, rich Sutton focus that, like, everyone should read it if 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 like a thing to that that we always think about where we could build a feature into quad code. We could make it better as a product, and we call this scaffolding.
It's all this code that's not the model itself. But we could also just wait, like, a couple months, and the model can probably just do the thing instead. And there's a way to straight off.
Right? It's like engineering work now, and you can kinda extend the capability a little bit, maybe 20% or whatever in whatever domain on this, like, you know, like, the spider chart of what you're trying to extend.
Or you can just wait, the next model will do it. So just always always think in terms of this trade off. Where where do you actually wanna invest and assume that whatever the scaffolding is, it's just tech debt.
How often do you rewrite the code ways of clock code? Is this every six months with this with this first physical scaffolding that you've deleted because you don't need it anymore because the model just improved? Oh, so much.
Yeah. Like, all of ClockCode 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's no part of Cloud Code that was around six months ago. It's just constantly rewritten.
But you say that most of the code base for current Cloud Code is only
say 80% of it is only less than a couple months old? Yeah. Definitely.
It might it might even be, like, less than yeah. Maybe, like, a couple months. That that feels about right.
Just like the life cycle of code now, that's another alpha is expecting it to be the shelf life to be just a couple months Yeah. For the best founders. Do you see Steve Yegi'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,000 x more productivity than a Google engineer at Google's peak, which is really an insane number, honestly.
Like, 1,000 x. Like, you know, we're three years ago, we were still talking about 10 x engineers. Now we're talking about a thousand x on top of a Google engineer in the prime.
Like, this is unbelievable, honestly. Yeah. I mean, internally, if you if you look at, like, technical employees, they all use quad code every day.
And even nontechnical employees, I think, like, half the sales team uses quad code. They they've started switching to co work because it's a little easier to use. It has, a VM, so it's a little bit safer.
But, yeah, we actually we just pulled the stat, and the the I think the team doubled in size last year, but productivity per engineer grew something like 70%. As measured by Just like the simplest, stupidest measure, pull requests. Okay.
But we also kind of cross check that against, like, commits and, like, the lifetime of commits and things like this. And since QuadCode came out, productivity per engineer at Anthropic has grown a 150%. Oh my god.
And this is crazy because I in my old life, I was responsible for code quality at Meta. And I was responsible for the quality of all of our code bases across every product, across, like, you know, 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 like a year of work by hundreds of people.
And so this, like, a 100%, this is just like unheard of, just completely unheard of. What drew you to come over to Anthropic? I mean, basically, as a builder, you could go anywhere.
What was the moment that made you say, like, this is the set of people or this is the approach? 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 like AI stuff at some point.
And I started to use some of these early products, and I remember, like, the first couple times that I used it, I was just like it just took my breath away. That was, like, very cheesy to say, but that was actually that was actually the feeling.
Like, it it was just, like, it was amazing. Like, as a as as a builder, I've just never kinda felt felt this feeling like using these very, early products.
That was like in the quad two days or, you know, something like that. And so I I just talking started talking to friends at labs just to kinda see what was going on. And I met Ben Mann, who's one of the founders at at Anthropic, and he just immediately won me over.
And as soon as I met kind of the rest of the team at end, it just won me over. And I think I think probably in two ways. So one is it operates as a research lab.
So the product work 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.
Like, I'm I'm a huge sci fi reader. My bookshelf is just, like, filled with sci fi. And so, like, I just know how bad this can go.
Mhmm. And when I kinda think about what's gonna happen this year, you know, it's gonna 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 kinda really internalize that. And at end, you know, like, you overhear conversations in the lunch room 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 I know I know for me personally, mission is just so important. What is gonna happen this year?
Okay. So if you think back, like, six months ago and kinda what are their predictions that people are making? So Dario predicted that 90% of the code at Anthropic would be would be written by Quad.
This is true. For me personally, it's been a 100% for, like, since Opus 4.5. I just I uninstalled my IDE.
I don't edit a single line of code by hand. It's just a 100% quad code in OPUS. And, you know, I land, you know, like, 20 PRs a day every day.
If you look at Anthropic overall, it ranges between, like, 70 to 90%, you know, depending on the team. For a lot of teams, it's also, like, a 100%.
For a lot of people, it's a 100%. And I remember making this prediction back in May when we GA'd quad code that you wouldn't need an ID to code anymore. And it was totally crazy to say.
I feel like people in the audience gasped because it was such, like, a silly prediction at the time. But really, all it is is, like, you just, like, trace the, you know, the exponential. And this is just, like, so deep in, you know, the DNA at the end because, like, you know, three of our founders were coauthors of the scaling laws paper.
They kinda they saw this very early. And so this is just like tracing the exponential. This is what's gonna 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, is practically solved, you know, for me, and I think it'll be the case for everyone, you know, regardless of domain.
I think we're gonna start to see the title software engineer go away, and I think it's just gonna 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 gonna be coding. It's software engineers are also gonna be writing specs.
They're gonna be talking to users. Like, this thing that we're starting to see right now on our team where engineers are very much generalists, and every single function on our team codes, like RPM's code, our designer's code, our EM codes, our like, everyone our our finance guy codes, like, everyone on our team codes.
We're gonna start to see this everywhere. So this is sort of this is kind of like the lower bound if we just continue with the trend. The upper bound, think, is a lot scarier.
And this is something like, you know, we hit ESL four. And this you know, at Anthropic, we talked about these safety levels. ESL three is where the models are right now.
ESL four 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 the extreme is that, you know, 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 it's just been honestly, it's just been, like, so exciting and humbling, like, seeing how people are using quad code. Like, you know, I just wanted to build a cool thing, and it ended up being really useful. And that was so surprising and so exciting.
My impression on Twitter or just the outside is basically everyone went away over the holidays and then, like, found out about ClaudeCode, and it's just been crazy ever since. But is that how it was for you at, like, in time that you were you having, like, a nice Christmas break and then came back here? Like, what happened?
Well, actually, for all of December, I was traveling around, and I I took a coding vacation. So we were kinda traveling around, and I was just, like, coding every day. So that was really nice.
And then I also started to use Twitter at the time because, like, I I worked on threads back then way back when. So I've been a threads user for a while. So I just, like, tried to see kind of, like, other platforms where people are.
Yeah. I think for a lot of people, they kinda discover that was the moment where they discovered OPUS 4.5 that I kind of already knew. Mhmm.
And internally, QuadCode's just been on this, like, exponential tear for many, many months now, so that just, like, it it became even more steep. That's what we saw. And if you look at QuadCode now, you know, there was some stuff from Mercury that, like, 70% of startups are, you know, choosing Quad as their model of choice.
There were some other stuff from, like, semi analysis that 4% of all public commits are made by QuadCode, like, of all code written everywhere. That.
All the companies, you know, use QuadCode from, like, the biggest companies to kinda, you know, smallest startups. You know, like, it it wrote it it parted the course for perseverance, like, for like, the Mars Rover.
This is just like this is the coolest thing for me, and we, like, we even printed posters because the team was like, wow. This is just, like, so cool that NASA chooses to use this thing. So, yeah, it's just, like, it's humbling, but it also feels like the very beginning.
What's the sort of interaction between Claude code and then Cowork?
Like, you know, was it a fork of Claude code? Was it, like, you had Cloud Code look at the Cloud Code code and say, let's make a new spec for nontechnical people that, you know, keeps all the lessons, then, you know, it sort of went off for a couple days and did that?
What's the genesis of that, and, you know, where do you think that goes?
This is gonna be, like, my fifth time using the word wait and demand. Yeah. It was just that.
I mean, like, we we were looking at Twitter, there was, like, that one guy that was using quad code to, like, monitor his tomato plants. Mhmm. There was, like, this other person that was using it to, like, recover wedding photos off of a corrupted hard drive.
There are people that are using it for, like, for finance. When we looked internally at Anthropic, every designer is using it.
All 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 can use this.
So we knew for a while that we wanted to build something, and so we're experimenting with a bunch of different ideas. And the thing that kinda took off was just, you know, a little quad code wrapper in a GUI in the desktop app. And that that's all it is.
It's just quad code under the hood. It's the same agent. Oh, wow.
And Felix and the team and Felix was an early electron contributor. He kinda knows that stack really well, and he was hacking on various ideas.
And they they built it in, I think, something like ten days. It was it was just like a 100% written by quad code, and it just felt ready to release.
There was a lot of stuff that we had to build for nontechnical 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 delete protections for deletion and things like this.
There's a lot of permission prompting and kinda other guardrails for users.
But, yeah, it was honestly pretty obvious. 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 three weeks. I 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. Yeah. Thanks for having in the sandbox.
Sounds good.
The Hook
The bait, then the rug-pull.
When the creator of Claude Code says the most surprising thing about this moment is that engineers are still using a terminal, he means it as a compliment to the model. The CLI was supposed to be the throwaway scaffolding. It turned out to be the thing.
Greg Isenberg gets a live, screen-shared tour of Jack Dorsey's new agent-native chat app from an early user — and presses him on whether it actually beats Slack.
A Claude Code creator mines his own chat history into a personal test pack, then builds a slash-command benchmark that tells him in one run whether a new model release is actually worth switching to.
A YouTube creator argues the real AI job threat isn't robots — it's coworkers who learned to direct agentic AI — then live-demos three tasks it can already do and a three-step plan for learning to manage it yourself.
The Skool founder walks Cole Gordon through the whole build — the network-effect bet, the year-long hunt for one engineer, the 11x price cut, and why he still won't let AI write his code.
00:39
01:54
03:20
05:06
06:37
07:35
08:48
09:51
10:43
11:28
12:05
13:21
13:53
14:44
15:08
15:43
17:32
17:35
18:53
19:27
20:54
21:27
22:38
23:18
24:27
25:45
26:30
27:41
28:24
29:05
30:07
30:50
31:31
32:25
32:44
33:36
34:00
34:42
35:12
35:47
36:46
37:20
37:43
38:15
39:09
39:40
40:16
40:53
41:25
42:04
42:59
43:37
44:06
44:41
45:54
46:29
47:26
47:45
48:23
49:39
15:41
38:44
08:16
14:03
Video of the Day2:08:57
Video of the Day30:53