1:36:30AI Engineer · Tutorial
Full Walkthrough: Workflow for AI Coding
A 96-minute live workshop on using software engineering fundamentals to get autonomous coding agents to ship real, non-slop features.
April 24thThe argument in one line.
The engineer who spent seven years perfecting code quality at Meta now ships 20-30 pull requests daily without touching a single line manually -- his account of how the workflow evolved is the most detailed insider view of what software development looks like when the model does the coding.
Read if. Skip if.
READ IF YOU ARE…
- A software engineer actively using AI coding tools who wants a real workflow breakdown from the person who built the tool, not marketing copy.
- An engineering lead reassessing code review, staffing assumptions, and prototyping culture in the AI-first era.
- Anyone grappling with the identity shift when a craft you spent years mastering becomes something anyone can do.
- A technical founder who wants to understand how the Claude Code team itself builds products: no PRDs, prototype-everything, 10 days to ship CoWork.
SKIP IF…
- You want a beginner introduction to what Claude Code is -- this assumes hands-on experience.
- You are looking for model internals, training methodology, or research-level AI content -- this is entirely product and workflow.
The full version, fast.
Boris Cherny built Claude Code as a side project after being told to stop writing code by hand on his first day at Anthropic. What started as a bash script became the tool that now writes roughly 80% of all code at the company. The interview covers his five-terminal-tab parallel workflow, how AI review catches about 80% of bugs before a human sees a PR, why agentic grep outperformed RAG for codebase retrieval, how CoWork was built in 10 days with hundreds of agents, and why the printing press analogy is the right frame for where software engineering is headed.
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.
Create a free account →Where the time goes.
00:00 – 11:15
01 · Intro and origin story
Cold open teaser cuts then Boris origin: Pokemon cards, TI-83 assembly, YC startups
11:15 – 19:46
02 · Lessons from Meta
Seven years at Facebook and Instagram; Better Engineering 20% program; code quality causal impact on productivity
19:46 – 23:08
03 · Joining Anthropic
First PR rejected for being hand-written; discovering Clyde; first AGI-feel moment with tool use
23:08 – 32:55
04 · Origins of Claude Code
Bash chatbot to agentic tool use; internal debate about releasing it; 100% Anthropic technical staff adoption
32:55 – 36:28
05 · Boris daily workflow
Five parallel terminal checkouts; plan mode; Opus 4.6 one-shotting implementations; iOS app writing a third of his code
36:28 – 40:25
06 · Parallel agents
When to parallelize vs. follow along; learn mode vs. ship mode; notification-driven round-robin across tabs
40:25 – 47:18
07 · Code review in the AI era
Lint-rule-from-spreadsheet; Claude writing lint rules inline on PRs; claude -p in CI; 80% bug catch rate; human always approves
47:18 – 52:39
08 · Claude Code architecture
Core query loop; tool experimentation; prompt injection at three layers; most code written gets thrown away
52:39 – 55:05
09 · Permissions and sandboxing
Permission prompt origin; allow-list config; open-source sandbox; why even find and sed need scrutiny
55:05 – 1:05:15
10 · Engineering culture at Anthropic
Member of technical staff title rationale; no PRDs; prototype-first; data scientists and finance all writing code
1:05:15 – 1:08:15
11 · Claude CoWork
10-day build; non-engineer demand signal; VM safety; Chrome extension; Slack-from-spreadsheet use case
1:08:15 – 1:11:15
12 · Observability and privacy
Cannot pull user logs due to enterprise privacy; privacy-preserving event logging; mix of vendors and custom code
1:11:15 – 1:21:16
13 · Agent swarms and Teams
Uncorrelated context windows as test-time compute; plugins built by autonomous swarm; Teams research preview opt-in
1:21:16 – 1:37:59
14 · Printing press analogy and skills
Scribes-to-authors; language and framework debates obsolete; generalist hybrids rewarded; book recommendations
Lines worth screenshotting.
- Agentic glob and grep outperformed a local vector database for codebase retrieval -- RAG freshness, permission complexity, and drift made it more trouble than its recall gains justified.
- Claude Code reviewing every pull request in CI catches roughly 80% of bugs before a human sees the code; a human still approves but no longer originates the review.
- Parallel agents with uncorrelated context windows produce better results on complex tasks than extending a single window, because it is a form of test-time compute.
- When Opus 4.5 shipped, Boris uninstalled his IDE without noticing -- a month later he realized he had stopped opening it entirely.
- Claude CoWork was built in 10 days by a small team using hundreds of agents; most of its complexity is VM-backed safety and a rethought permission model for nontechnical users.
- Plugins for Claude Code were fully built by a swarm of agents running autonomously over a weekend -- the swarm created an Asana board, split into tasks, and implemented them.
- The most durable engineering skills right now are hypothesis-driven thinking, cross-lane curiosity, and adaptability -- strong opinions about language and framework choice are the first to drop.
- The permission prompt system (run once, this session, always) was invented in the very first internal Claude Code release as the pragmatic answer to letting a model run bash commands.
- Prototyping dozens of versions before shipping is only possible because the cost of building has collapsed -- aim carefully before taking your shot no longer applies.
- Non-engineers joining the Claude Code user base happened by latent demand: people jumping through hoops to use a tool not designed for them is the clearest product-market-fit signal.
- Prompt injection is defended at three independent layers: model alignment, a runtime classifier, and sub-agent summarization -- no single layer is sufficient on its own.
- Code quality at Meta had a double-digit causal percentage impact on engineering productivity -- clean codebases are measurable multipliers, not aesthetic preferences.
- The printing press did not destroy scribes -- they became writers and authors, and the entire market for the written word expanded beyond anything anyone predicted.
- The model improving so quickly that old ideas become good again requires a permanent beginner mindset -- intellectual humility is now a core engineering skill.
- Shipping 20-30 PRs a day from a phone during holiday travel is a proof-of-concept: the environment (session hooks, configured cloud execution) matters more than the device.
Which engineer skills survive the printing press moment
WHAT TO LEARN
The person who built Claude Code uses it to write every line he ships -- and his account of what still matters for engineers, and what to drop, is more credible than any pundit take.
02Lessons from Meta
- Code quality has a double-digit causal percentage impact on engineering productivity -- clean codebases are measurable multipliers, not aesthetic preferences.
- Tech-debt tracking without goals or causal measurement is just noise; adding prioritization and impact data turns it into a productivity lever.
03Joining Anthropic
- Being told your first pull request is invalid because you wrote it by hand is faster onboarding to the new paradigm than any tutorial.
- The model does not need to be structured as a component of a larger system -- give it tools, let it run, constrain it as little as possible.
04Origins of Claude Code
- Safety research in the wild produced improvements that synthetic evals could not generate.
- Internal adoption going vertical happened by self-selection, not mandates; 100% of technical staff and half the sales team chose it independently.
05Boris daily workflow
- Five parallel checkouts with plan mode front-loads coherence and removes the single-context-window bottleneck.
- Starting on a new codebase calls for explanatory learn mode; once familiar, pure-ship mode reviewing only plans is faster.
- Shipping code from a phone on a coding vacation works when the environment is configured correctly -- the device is not the constraint.
07Code review in the AI era
- AI-first code review catches roughly 80% of bugs before a human sees the PR; humans still approve but no longer originate the review.
- The lint-rule-from-spreadsheet discipline now extends to having the model write the lint rule inline on the PR.
- Determinism gaps in LLM review are closed by best-of-N parallelism and by layering static analysis that does not hallucinate.
08Claude Code architecture
- Agentic glob and grep beat a local vector database -- freshness and drift made RAG more trouble than its recall gains justified.
- Prompt injection is defended at three independent layers (alignment, classifier, sub-agent summarization) -- no single layer is sufficient.
- Most code written gets thrown away; this is healthy when the cost of writing and trying approaches zero.
10Engineering culture at Anthropic
- Removing titles removes the social permission-seeking before crossing lanes -- everyone defaults to assuming everyone does everything.
- Prototyping dozens of versions before shipping is only practical because the cost of building has collapsed.
- Non-engineers using a developer tool by jumping through hoops is the clearest signal that a dedicated product is needed.
11Claude CoWork
- Ten days and a small team is enough to ship a new product when the codebase is already in place and agents do the implementation.
- Most of CoWork complexity is not UI but VM-backed safety and a rethought permission model for users who do not want to read bash commands.
13Agent swarms and Teams
- Uncorrelated context windows give better results on complex tasks than extending a single window -- multiple fresh agents is a form of test-time compute.
- Plugins were fully built by an autonomous swarm over a weekend -- the swarm created its own task board and implemented against it.
14Printing press analogy and skills
- Strong opinions about language and framework choice are the first engineering skill to drop.
- Cross-lane curiosity, generalism, and adaptability are the skills that compound now.
- The printing press did not destroy scribes -- they became writers and authors, and the market expanded enormously; the same dynamic is likely true for software.
Terms worth knowing.
- Uncorrelated context windows
- Multiple agent instances each starting with a fresh context window rather than sharing one -- they do not know what each other has seen, which produces better aggregate results on complex tasks and acts as a form of test-time compute.
- Plan mode
- A Claude Code mode (shift-tab twice) where the model produces a plan before taking any action, letting the user review and correct direction before execution begins.
- Best-of-N review
- Running N parallel AI review passes then a separate deduplication pass to filter false positives -- makes nondeterministic LLM review more reliable without requiring any single pass to be deterministic.
- Agentic search
- Letting the model use glob and grep directly to retrieve code context rather than pre-indexing a codebase into a vector store; outperformed RAG in practice because it stays in sync with the working tree.
- Clyde
- The internal predecessor to Claude Code at Anthropic -- a Python script requiring careful flag usage, 40 seconds to start, non-agentic, but capable of writing a working pull request if prompted correctly.
- Better Engineering (Meta)
- A company mandate (circa 2016-2018) that every engineer spend 20% of their time on tech debt, with centralized prioritization and causal tracking of productivity impact.
- Claude CoWork
- Anthropic product for nontechnical users built on the same Claude Code agent, shipped with a virtual machine for safety and a rethought permission model accessible via a Chrome extension.
Things they pointed at.
1:36:30bookAccelerando by Charles Stross
1:36:10bookLiu Cixin short stories
1:36:50bookFunctional Programming in Scala
Lines you could clip.
59:40
“I wrote maybe ten, twenty pull requests every day. Opus 4.5 and Claude Code wrote 100% of every single one. I did not edit a single line manually.”
1:35:00
“Agentic search just outperformed everything. And when I say agentic search, it is a fancy word for glob and grep.”
1:21:15
“We are the scribes. We spent years mastering this craft and now the printing press is arriving.”
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.
You wrote the first ever TypeScript book with O'Reilly. Yeah. I found that book translated in Japanese in this little town in Japan.
That was just the coolest moment, and then I realized I don't remember TypeScript at all. Now we're the point where QuadCode writes, I think, something like 80% of the code had Anthropic on average. I wrote maybe ten, twenty poll requests every day.
Opus 4.5 and QuadCode wrote a 100% of every single one. I didn't edit a single line manually. Andre Carpet posted that he's never felt as much behind as a programmer as he is now.
This is something I really struggle with. The model is improving so quickly that the ideas that worked with the old model might not work with the new model. One metaphor I have for this moment in time is the printing press in the fourteen hundreds because there was a group of scribes that knew how to write.
Some of the kings were illiterate who were employing the scribes. And if you think about what happened to the scribes, they ceased to become scribes, but now there's a category of writers and authors. These people now exist.
And the reason they exist is because the market for literature does expanded a ton.
What happens when you join one of the top AI labs in the world and your first pull request gets rejected? Not because the code was bad, but because you wrote it by hand. This is exactly what happened to Boris' journey when he joined Anthropic.
Boris is the creator and engineering lead behind ClotCode. Before joining Antropic, he spent seven years at Meta where he led cold quality across Instagram, Facebook, WhatsApp, and Messenger and was one of the most prolific code authors and code reviewers at the company. In today's episode, we cover how Cloud Code went from a side project to one of the fastest growing developer tools and the internal debate at NoTropic whether to release it at all.
Boris' daily workflow of shipping twenty thirty pull requests a day with zero handwritten code and how code review works when everything. Why Boris believes we're living through a time as transformative as a printing press and which engineering skills matter more now and which ones do not.
If you want to understand how one of the people closest to AI coding agents actually builds software today and what that means for the rest of us engineers, this episode is for you. This episode is presented by Statsig, the unified platform for flags, analytics experiments, more. Check out the show notes to learn more about them and our other seasonal sponsors Sonar and WorkOS.
How did you get into tech, software engineering, coding in general?
It starts a while back. Well, I think there was kinda like two parallel paths that crossed. So when I was maybe 13 or something like this, I started selling my old Pokemon cards on eBay.
And I realized that on eBay you can actually write HTML. And I was looking at other people's Pokemon card listings and I realized some of them have big colors and fonts and stuff like this. And then I discovered the Blink Tag.
I That really was Blink Tag. And if I put the Blink Tag on it, could sell my card, you know, for, like, 99¢ instead of 49¢ or whatever.
So I kind of learned about HTML this way, then I got an HTML book and kind of learned about HTML. And then the second thing was, this was also, I think, sometime in middle school, we had these old TI 83 graphing calculators, and we used them for math.
And what I realized is I can get a better answer on the math test if I just program the answers to the math test into my calculator. And so I wrote these little programs. They just program the answers, and then the test got harder, so then I had to program solvers instead of the actual questions because I didn't know what what, you know, the coefficients and stuff would be ahead of time.
And then the math got more advanced, like, the next year, and so I had to drop down from basic to assembly to just make the program run a little bit faster. Oh, so, like, in high school, you dropped down to assembly?
I think it's, like, middle school or high school, maybe, like, eighth or ninth grade or something like this. Then the thing I realized is everyone in my class was starting to realize that I had this software and they got kinda jealous, and so I bought this little serial cable so I can give it to them too. And then the next math test, everyone on the class just got a's, and the teacher was like, what's going on?
Eventually she realized it, and she was like, okay, you get away with it once and knock it off. But for me, it was very practical.
So, you know, in school I studied economics. I actually dropped out to start startups, and I never thought that coding would be a career at all.
It was always very practical to me. Coding is a means to build things and to to make useful things.
This startup, the first one was I think it's like my friends and I were trying to get weed. And so we started this, like, weed review start up.
We made, like, a website. We called kinda different dispensaries, I I think.
And then we just tried to get kinda, like, weed samples so we could, like, review it for them. And it actually blew up, and then I actually got more interested in at the time, no one was testing this stuff.
And so I got into chemical testing, chemical analysis. And then after this, kinda did a bunch of other startups, and then I joined YC actually pretty early.
And I was the first hire of this YC startup up up in up in Palo Alto after. How did you decide to go go to one startup after the other? Kinda vibes.
Vibes, I'd say. Because, you know you know, like, you know start ups, it's it's never a linear path. You always kinda pivot, pivot, pivot.
You have to figure out what the market wants and what users want, and it's never the thing that you think. You you always try a thing, but the the idea is always a hypothesis, and then almost always you have to pivot once, twice, three times.
You know, at this medical software company, this is called Agile Diagnosis, this was kind of an early YC company, this was back in maybe 2011, 2012, something like that.
It was medical software for doctors. And the idea was there's these clinical decision protocols, they vary a lot hospital to hospital. And our idea was there was one hospital in Chicago that had a really great protocol, specifically for cardiac symptoms.
And so we were like, wouldn't outcomes be great if every hospital in The US would use the same protocol? And so we tried to standardize it, and we made this decision tree software for doctors to use.
And I wrote some of the software. It was just a few of us.
It was a pretty small team. And I wrote the software. It was in a web browser.
And I remember this was back in, like, the Internet x four six days. That's what hospitals were using. And I wrote this SVG renderer because it was this visual decision tree.
And we launched it, and then we had a DAU chart, and the DUs were flat and couldn't figure it out. And we were piloting it with a few hospitals at the time. And at the time we were based in Palo Alto, we were piloting it with a few hospitals, including UCSF.
And I rode a motorcycle at the time, so I rode my motorcycle up to UCSF and I shadowed doctors for a couple days just to see how do they actually use this. And I realized that actually doctors don't have time to sit down and use a computer. Because you're seeing a patient, then you have maybe five minutes until the next patient.
And in those five minutes, you have to walk down the hall, you have to go to the computer station, you have to open up this totally legacy computer. By the time it boots up, that's like three minutes.
Then you open up Inner Explorer six. That takes like thirty seconds. Then you have to open up this app that we built.
You have to sign in, and your five minutes are up. You don't even have time to use it. And so we rewrote everything to run on Android, and they still weren't using it.
And the thing we realized is doctors are walking around with a bunch of residents behind them. In this kind of situation, it's like a social situation. Right?
Like, the the thing that matters is they're seen as an authority. They don't wanna be seen on their phones. And then we pivoted again.
So at that point, we were like, okay, so maybe the doctor isn't the target user. Actually, we want it to be used by maybe nurses or x-ray technicians or something like this. At that point, I left because I was like, this is actually pretty far off from kinda what I wanted to do.
This is like the most fun thing for me, is finding this this product market fit because it's always surprising. You can't have one big idea because the idea is probably gonna be wrong.
So you you kinda form hypotheses, you you follow it down, and and you see what's right. Also,
I find it so interesting how you're telling us this story because I feel behind a lot of startup success stories, we hear the success story, we hear the path of how it went. But first of all, a lot of startups are like this. And second of all, what struck me is you you were hired as a software engineer.
Right? And this was back before product engineers or anything was a thing, which we're now talking about. But you just, like, you rode your motorbike and you went there and you shadowed the people and you understood how they're using it, why they're not using it, getting getting ideas, I I feel, you know, this this is what makes a great software engineer
back then and and even today. Right? You you you weren't doesn't seem to me that you were focused on the technology.
You were focused on the outcome, though. Yeah. I mean, look, there there's different kinds of engineers, there's different ways to do it.
And, you know, I even even on our team right now, I look at an engineer like Jared Sumner, and he's just incredible technical mind. He understands systems better than anyone I've met.
And, you know, you need you need people like this. You need people with this kind of depth. For me, engineering has always been a practical thing.
And, you know, for me, I've always been a generalist. And, like, it doesn't matter if I'm doing, you know, like, design or, you know, if I'm doing engineering or user research or whatever.
The investment thesis for AI and software engineering is straightforward. As AI writes more code, more code needs to be verified. But there's a catch.
AI generated code is on average harder to verify than human written code. This is why they're Sonar, the makers of SonarCube. As a critical verification layer for the AI enabled world, Sonar ensures that speed and volume with AI does not compromise your codebase.
Sonar's competitive position is built on seventeen years of specialized expertise that no foundational model can replicate. We're talking about deep analysis engines like symbolic execution and cross repository data flow tracking that simulate how code actually behaves, not just what it says. To bridge the divide between AI productivity and code quality, Sonar has released the SonarQube MCP Server.
This tool acts as a universal translator between AI applications and the SonarQube platform. By using the model context protocol, it gives AI tools like Cloud Code, GitHub Copilot, and Cursor direct access to SonarQube's analysis capabilities.
Instead of context switching, your AI agent becomes a full fledged code review and quality assurance copilot capable of analyzing code snippets for issues, filtering bugs by severity, and even checking your project's quality gate status before you ever commit code. Whether you're working with coding assistance or scaling up with full agent workflows, Sonar provides the automated verification that 75% of the Fortune 100 rely on.
It's about giving your developers the freedom to innovate without the fear of breaking the code base. Head to sonarsource.com/pragmatic to learn more about how Sonar enables the confidence to develop at the speed of AI.
With this, let's get back to Boris' career and what he learned working at startups.
My first job I ever had, I was like, I think I was 16. And I just wanted to buy an electric guitar. And so what I did was I I started I just started freelancing.
And so I was like, okay, I guess I'll make websites. And I think Fiverr was not a thing back then, so there were some other freelancing websites. I just sort of like I put up a website, I started bidding on stuff.
And my first paycheck, I just spent the entire thing on an electric guitar. But it was very practical. Right?
Because it's like when you're in this kind of setup, you have to you have to do the engineering, you have to do kind of the accounting, you have to do the the design, you have to talk to customers. So it's just always been like that for me. After
a couple of these startups, you ended up at Facebook, now called Meta. And there, you spent seven years there. Can you just talk us through what you've worked there, what you've learned there?
You've also had a very remarkable career growth in terms of four promotions over over over seven years. And what do you take away from that that experience?
Yeah. So I started on Facebook groups. That was the first time I worked on Vlad Kolesnikov hired me.
I think I think he's actually still at Facebook. I think he's on some other team now. And it was cool, actually.
There there was a big group of people that I worked with that were these kind of early JavaScript people too. And, you know, like, I I did a bunch of JavaScript stuff, and it's it's funny. Like, I kept crossing paths with these people.
And so Vlad, he worked on Bolt. Js, which was the software it was the framework that powered Ads Manager, which later became React.
Js. I kept crossing paths with these people, and later on, for yeah. Later on, there was a bunch more people like this.
But anyway, so I I was working on Facebook groups. I was really excited about it because of this mission of connecting people to their community.
This is the thing that drew me in. And at the time I was a big Reddit user. I became a Reddit user back when I was a teenager because I didn't know anyone else that coded.
Even in college, I didn't really know anyone that coded. And honestly, was always kind of embarrassed about it because I thought it was this nerdy thing.
And I thought it was kind of this thing that I knew how to do. But I to be like a cool kid, I couldn't tell people that I coded. Very nerdy.
And at some point I discovered it was some programming community on Reddit, And I just shocked, like, there's other people that are into this thing, it's such a weird hobby, it's so niche. And it was just so exciting to find like minded people like this and get this connection.
And so I just wanted to work on this, I wanted to kind of contribute to this in some way. So I worked on Facebook groups for a while, and then, you know, there's a bunch of different projects I have to kind of get into details for any of these.
Eventually I became the tech lead for Facebook groups I kinda grew into this, and the org grew, the work really changed. It changed from kinda building to a lot of doc writing and coordination and kinda delegating to others.
The culture was changing at the time. So, you know, this early Facebook culture was disappearing. The docs were coming in.
The alignment meetings were coming in. There was a lot more work around this kind of foundational stuff, privacy, security, things like this, that I think, honestly, early on, a lot of corners were cut in order to grow. But at some point, you just have to pay that debt, and that was the time when that happened.
Then I spent a few years at Instagram after. That was also a funny story. My wife got a job offer and she was just really excited about it and she came to me and was like, Hey, I got this offer, but we're gonna have to move.
Is that okay? And I was like, yeah. That's fine.
You know, like, I I work in tech. We can work remotely anywhere. Where's the job?
And she was like, it's a Nara. And I was like, where where is that? And Nara is, like, rural Japan.
And this was Different time zone as well? Different time zone. Yeah.
This was 20 or something different or something like that? Something like that. Yeah.
It was, like, 2021. Wow. And then I I tried to kinda find a team that would sponsor me because there was there were these kinda arcane HR rules about, like, the time zone you have to be in and the team you have to be colocated with so on.
And so there was a little kinda nascent team for Instagram in Tokyo, and Will Bailey was running this team. He was also the guy that made Instagram stories.
And so he was my manager for a while. And so we decided to grow that team together. And I worked remotely from Nara, and then most of the team was in Tokyo.
And during this time, I started hacking on Instagram, and the stack was just insane. Like, Facebook was the single best web serving stack in the world. The the way that h h everything is optimized, like, from from the hack language to the h h v m runtime to the to GraphQL as the transport layer to, like, the client libraries, like, Relay and and all the stuff.
It was just and and React, it was just amazing. There there's no other DevStack in the world that was this good, and it's just fully optimized. And then I went to Instagram, and it's like, you know, Python where the type checker didn't work, and click click to definition didn't work.
And it was this, like, kinda hacked together Django, and then, like, a fork of, you know, the Cython runtime. And just nothing really worked. And so I came to Instagram.
I joined the labs team, you know, in in Japan, and the idea was to find the next big thing for Instagram. We tried some stuff, but what I very quickly realized is that I was just not effective at working on the stack because it was such a terrible stack. And so I just went and started working on dev infra because we we needed to fix it.
And there there's a few projects that we worked on. So one was migrating from Python to the big Facebook monolith, another one was migrating from REST to GraphQL. And these projects, they're they're actually in progress.
Know, like, are things that involve it takes hundreds of engineers many years to do this. It's a big code base. It's a big migration.
Now it's it's much faster. Yeah. With with with these tools that we have, the AI AI tools, and migrations are a pretty good use case for them, though.
Yeah. It's like the it's the perfect use case for it. And then I I just started getting kinda deeper into this.
And by the end by the time I left Instagram, so I was working on this on Devidfront, kinda leading a bunch of these migrations, that's also where I intersected with Fiona Fung, who is now the manager for the quad code team. I just worked with her, and she was just such an amazing leader, this incredible depth and kind of history in tech.
And I just thought, like, there's no better there's no better manager for this team. And then I I also started working on code quality. And so the the work on Instagram kinda expanded a bit.
And by the time I left, I was leading code quality for all of Meta. And so I was responsible for the quality of the code bases across Instagram, Facebook, Messenger, WhatsApp, Reality Labs, kinda all these code bases.
At Meta, it was this program called Better Engineering. And the idea was, I think it's sort of like twenty sixteen or 2018 or something, but Zuck mandated that every engineer at the company, 20% of their time has to be spent fixing tech debt. Oh, interesting.
And we called this better engineering. Mhmm. And some of this is kinda bottom up where a team knows best the tech debt that they have to fix, and then some of it is top down, where you need to do very big migrations, you need to migrate to new language features, new frameworks, things like this.
And at Facebook's scale, there was tens of thousands of these migrations every year. And so I just started leading all of this, and I realized very quick that it just needed a little bit more order to it.
There was no goals, no one knew what the outcomes were, there wasn't any tracking. And so we developed a bunch of stuff. One of the ideas was a centralized way to prioritize the different kind of code quality efforts.
The second thing was figuring out the impact of code quality on engineering productivity, which turned out to be significant. How how did you measure? What did you find there?
There was a bunch of stuff. I think some of this has been published. I don't know if all of it has.
But essentially, you try to do causal analysis and causal inference. This is the methodology. And you try to figure out what are the factors that make it so engineers are more productive.
Some of it is code quality. Some of it is outside of code quality. So for example, Meta went back to return to office instead of work from home.
Those partially driven by this because we just found some, you know, fairly strong correlations that we thought were causal Yep. About this. But cold quality actually contributes, like, you know, double digit percent to to productivity,
it it turns out, even even at the biggest scale. This is kind of comforting to hear because I I think it's it's rare to have a place where you actually measure this, but I think we feel it.
Like, when you have a clean code base modular or it can get easier to work with, and I I think, you know, reasoning, could it also be easier for LMs to to work with it? And my hint would be, yes, it should be. Right?
But I I think there's just very little data, but but that's a feeling that I I would have. Yeah. I think a lot of the big companies have published about this.
Like, I think Facebook published something, Microsoft publishes a bunch about this, Google does. But, yeah, totally. If every time that you build a feature,
you have to think about, do I use framework x or y or z? These are all options that you can consider because the code base is in a partially migrated state where all of these are around the code somewhere.
As an engineer, you're gonna have a bad time. As a new hire, you're gonna have a bad time. As a model, you might just pick the wrong thing.
And then, you know, like, the user has to course correct you. So actually, you know, the better thing to do is just always have, you know, a clean code base. Always make sure that when you when you start a migration, you finish the migration.
And this is great for engineers, and nowadays it's it's great for models too. And then you joined and I've heard the story, which you can confirm or give more color to it, that your first pull request was rejected by Adam Wolf.
He was my ramp up buddy. So I joined Anthropic. I was trying to figure out kinda, like, what to do next, and, you know, I I met a bunch of people at all the different labs, and Anthropic was just the obvious choice for me because of the mission.
This is the thing that personally I know that I need the most. And also just kinda seeing all this change that's happening, it's important to have some sort of framework to think about this and to think about our role in it. I'm also a really big sci fi reader, like, that's definitely my genre.
I'm big reader, have a giant bookshelf at home and stuff. And I just know how bad this thing can go. And I just felt like this is a place that has serious thinkers.
People are taking this very seriously and thinking about what what what can we do to make this thing go better. So when I joined Anthropic, I did a bunch of ramp up projects, just, you know, various stuff that that I was hacking on.
And I wrote my first pull request by hand because I thought that's how you write code. That used to be how you write code.
That used to be how you write code. But even at the time, at Anthropic, there was this thing called Clyde, and it was the it was the predecessor to quad code. It was it was super janky.
It was, like, it was Python, you know, it took, like, forty seconds to start up. It was research code. It was not agentic.
But if you prompt it very carefully and hold the tool just right, it can write code for you. And so Adam rejected my PR, and he was like, actually, you should use this Clyde thing for it instead.
And I was like, okay, cool. It took me like half a day to figure out how to use this tool, because you have to pass in a bunch of flags and use it correctly. But then it sped out a working PR.
It just one shotted it. Oh. And this was like 2024, it was like September 2024 or August, something like that.
And I think for me this was my first Fuel to HI moment at Anthropic because I I was just, oh my god, like, I didn't know the model could do this. Like, I I was used to these, like, kinda tab completions, line level completions in the IDE.
I had no idea that it could just make a working pull request for me.
Boris just talked about how he had a true wow moment at work using their AI model. A very different wow moment is when you use a tool at work that makes things so much easier than before. And this leads us nicely to our presenting sponsor, Statsig.
Statsig offers engineering teams a tooling for experimentation and feature flagging that used to require years of internal work to build. It's the kind of tool that was so complex to build that only large companies like Meta or Uber had their own custom advanced tooling for it. Here's what Statsig looks like in practice.
You ship a change behind a feature gate and roll it out gradually, say, to 1% or 10% of users at first. You watch what happens. Not just did it crash, but what did it do to the metrics you care about?
Conversion, retention, error rate, latency. If something looks off, you turn it off quickly. If it's trending the right way, you keep it rolling forward.
And the key is that measurement is part of the workflow. You're not switching between three tools and trying to match up segments and dashboards after the fact. Feature flags, experiments, and analytics are all in one place using the same underlying user assignments and data.
This is why teams at companies like Notion, Brex, and Atlassian use Statsig. Statsig has a generous free tier to get started and pro pricing for teams starts at a $150 per month. To learn more and get a thirty day enterprise trial, go to statsig.com/pragmatic.
And with this, let's get back to Boris and the origin story of Cloud Code. Yeah. And and then when you when you joined Anthropic, we we've covered this in in a deep dive, but we could recap briefly on how Cloud Code came to be out of out of what seemed like a side project or just a cool hack.
So, yeah, I I I started hacking on a bunch of different stuff. I was working on some things in product.
I worked on reinforcement learning for a little bit just to kinda understand the layer under the layer at which I was building. This is still advice that I give to a lot of engineers, is always understand the layer under. It's really important.
Because that just gives you the depth and you have a little bit more levers to work at the layer that you actually work at. This was the advice ten years ago.
It's still the advice today. But the layer under is a little bit different now. Before, was like, if you're writing JavaScript, understand the VM and frameworks and stuff.
Yeah. Now it's like, understand the model. So I was hacking on a bunch of different stuff.
Something shipped, something didn't ship. And at some point, just wanted to understand the public Anthropic API because I'd never used it before.
And I didn't wanna build a UI. I just wanted to, you know, hack something up quite quickly because we didn't have cloud code back then. We're still writing code by hand.
And I wrote this little bash tool that all it did was it hit the Anthropic API, it was essentially like a chat based application, but just in the terminal.
Because that's what AI used to be. And, you know, I I still think about it, like, engineers are the first adopters.
And so when we started to move out of conversational AI to agentic AI, it took a little bit, but engineers understood it pretty quick. And I I think now when you ask non engineers about, like, what is AI, They would say it's this conversational AI.
It's like a chatbot or something. And that's why I'm actually very excited for, you know, Cowork, this new product that we launched, because it's gonna bring the same thing that engineers saw very early to everyone else.
But when I think about, you know, co work, I think back to this moment that we're talking about, like, very early on. QuadCode originally wasn't QuadCode, it was a chatbot, because that's what I thought AI was.
But we had to kinda figure out kinda what is the next thing. And so at the time I built this chatbot, it was somewhat useful, but it was just a chatbot.
And the next thing that I tried was I wanted it to use tools because tool use just came out and I didn't know what it was. And I was like, let's experiment.
And and I I gave it a single tool, was the bash tool. And I didn't know what to do with the bash tool, so I asked it, you know, like I I actually didn't know if it could even do this, but I asked it, like, what music am I listening to? And it just wrote a little AppleScript program using, like, sed or or whatever to open up my music player and then, like, query it to see what music it's listening to, and just one shot at this with Sonnet 3.5.
This is actually my second a j field AGI moment very quickly after the first one. And the model just wants to use tools.
That's just what I realized. This thing, if you give it a tool, it will figure out how to use it to get the thing done.
And I think at the time, when I think about the way that people were approaching AI and coding, everyone essentially had this mental model of you take the model and you put it in a box, and you figure out, like, what is the interface?
Like, how how do you wanna interact with this model? What do you need it to do? Essentially, like if if you have a program, you you stub out some module, stub out some function, and you say, okay, This is now AI, but otherwise, the rest of the program is just a program.
And so this is just not the way to think about the model. The way to think about it is the model is its own thing. You give it tools.
You give it programs that it can run. You let it run programs. You let it write programs.
But you don't make it a component of this larger system in this way. And I think there's just like you know, this is a version of the Bitter Lesson. The Bitter Lesson has a very specific framing, but there's many corollaries to it.
This is one of the corollaries, is just let the model do its thing.
Don't try to put it in a box. Don't try to force it to behave a particular way. One of the first ways you saw it was giving it tools, giving it access to the bash, and then later to the file system, and then to more tools, right?
That's right. Yeah. We we give it we give it bash, then I say we.
It was just me the first three months, but then the team grew. So it it was bash, it was
and file edit. That was the second one. And one of the interesting thing we talked about last time for the deep dive is when you built it and it started to actually write code with with the with the tools that you had, you've had an internal debate inside Entropic.
Should we just keep it to ourselves? Because making suddenly, it's spread across engineering, and it was making all of you a lot more productive.
Right? Yeah. That's right.
In the end,
the decision was to release so that we can study safety in the wild. Because when you think about safety, and I keep talking about the word safety, the reason Anthropic exists as a lab is safety. This is the reason it was founded, this is the reason it exists.
If you ask anyone at Anthropic why they chose it, it's because of safety. And so if you think about model safety, there's different layers at which to think about it. There's alignment and mechanistic interpretability, this is at the model layer.
Then there's evals, and this is putting the model in a petri dish and synthetically studying it in this way. And then you can study it in the wild, and you can see how it actually behaves.
You can see how users talk about it. You can you can see, like, what are the risks in the wild, and you actually learn a lot this way. And by doing this, we we've been able to make the model much safer.
So in in hindsight, it was it was totally the right decision. It's amusing
to hear about it from your perspective, because from the outside, what what I saw and what a lot of engineers saw is like, oh, Entropic release, Cloud Code. Oh, wow. This you know, for the first release with I I believe it was with Sonnet four release.
Was was did it come up with Sonnet four originally or Sonnet 4.5?
I think it was it was four that that was the general availability in February, but I think it was research preview before that. Yeah. But when it came out,
my interpretation was like, oh, this thing can write code pretty well, and over time it became a lot more capable. So from from our perspective, it was like this really capable coding tool that we just started to adopt and use and use for all sorts of increasingly productive parts.
And it has become, I believe, one of the fastest growing developer tools, and I'm always surprised to hear the story that it actually comes from research and the goal to understand how people use the model. Because on the other hand, like, some startups have been trying to build developer tools deliberately to to get adoption and yet this research tool is getting a lot more adoption.
I mean, this is, you know, Anthropic, we're a research lab, we're a safety lab, and product is this kind of thing tacked onto the side. Product exists so that we can serve research better and so we can make the model safer. And this is kinda how we think about everything.
There's also this funny moment early on when had this launch review, and we were deciding whether to launch it.
I remember this moment, because we were in the room, I think there was Mike Krueger, there was Dario, there were some other folks in the room when we were deciding what should we do. We were looking at the internal adoption chart, which was just vertical.
Was just insane. Was, you know, like nowadays Pervert is a 100%, right? Just a 100%.
Like, nowadays, everyone at every technical employee at Anthropic uses QuadCode every day is pretty much 100%. For non technical employees, it's actually getting quite close to 100%, it's increasing very quickly.
Half the sales team uses quad code, and I think that's increasing, it's crazy. Dario had this question about how did it grow this fast?
Are you forcing people to use it? And I was like, no. We offer this tool, people vote with their feet, and it was just like, let people use the tool that they prefer.
They chose it. You don't seem like the person who's exactly
forcing people to use your tool. Yeah yeah, I mean, the way we did it, we launched the thing, and then we just listened to the users, and we talked to people, we saw how they used it, we followed up, we made it better, And, yeah, I mean, now now we're at the point where QuadCode writes, I think, something like 80% of the code in Anthropic on average,
and, you know, it writes all of my code for sure. Yeah. And this started for you, it started the first time you mentioned, I think it was in November when it started to write all of your code.
When did that switch come? And what what happened to made you trust
it to to write your code, how much you trust it? How much you review that code, for example? So the switch was instant when we started using Opus 4.5.
This was before before it came out, you know, we we were dogfitting it for a little bit, and it it was just right away. It's such a more capable model. I just found that I didn't have to open my IDE anymore.
I just uninstalled my IDE
because I just didn't need it at that point. I actually did that like a month later because I I I just didn't even realize that I wasn't using it anymore. Yeah.
A lot of us had similar experiences once Opus 4.5 was out in the public, and especially over the winter break. I I had a similar experience. I just realized that this thing, it actually writes, if I'm being honest with myself, as good code as I would have written in the stack that I'm very familiar with and my code base, my side projects where I know it, and just a lot better than what I could for code base that I'm not as familiar or technologies I'm not as familiar with.
Yeah. I'll be honest, he writes better code than I do. I I
I don't wanna go there. I I still like to keep my pride, but probably true. Yeah.
Yeah. I I realized this because also in December, was traveling a little bit. I was, like, on a I was on a coding vacation.
We were talking about this before, but I went to Europe, we were just in a different time zone, kinda nomading around. And it was so fun because I was just coding all day every day, which is my favorite thing to do. And I wrote maybe ten, twenty pull requests every day, something like that.
Opus 4.5 and quad code wrote a 100% of every single one. I didn't edit a single line manually. And I realized at the end of that month, Opus introduced maybe two bugs.
Whereas if I'd written that by hand, that would have been, you know, like, $20 or or
or something like that. Can we talk about your development workflow? You have written threads about this, which is awesome.
It's on it's on social media, on threads, and on on x. But can you tell us how you use today ClotCode in terms of, you know, parallelism and and tips and tricks that you and the team have learned and shared across
the team? Yeah. Mean, look, there's no one right way to use quad code.
So I can share some tips and things, but I think the wrong conclusion to draw would be to just copy these and use it. The way we build quad code is we build it to be hackable, because we know every engineer's workflow is different.
There's no one way to do things. There's no two engineers that have the same workflow. It's just every every engineer is Same with workstation setup, right, like keyboards, monitor, placement, all that ever has it differently.
Yeah. It's like we're like craftspeople, right, like you choose your tools, like we care deeply about it. So there's no one right way to do it.
So for me, the way that I do it generally is I have five terminal tabs. Each one of them has a checkout of their repository. So it's five parallel checkouts.
And usually, I'll kind of round robin and start quad code in each one. Almost every time, I start in plain mode, so that's like shift tab twice in the terminal. And I also overflow as I run out of tabs, because there's only so many terminal tabs.
I used to use web a lot for this, so like quad dot ai slash code. That's the place that I overflowed to. Nowadays, I actually use the desktop app.
It's more convenient. So quad code, it's been in our desktop app for many months. It's just the code tab in quad hub.
And I actually really like it because it has built in work tree support, so that's existed for a while. And that's quite nice for parallelism. So you don't need multiple checkouts, you just have one and then we automatically set up git work trees for you.
So you get this kind of environment isolation. The reason I do that is I actually just really hate fiddling with git work trees on the command line because it's it's kind of fiddly. Like, you you need to know the c d git git work tree for those who are not as familiar with it.
It's it's when you can check out and instead of having a separate local folder, it's almost like checks out a separate branch. Right? And then you can work on it separately, but not have the have the complex only at, like, merge time.
That's right. Imagine that you you have a folder, but you have maybe, like, Git makes five copies of that folder in a way that's very cheap and kinda easy to throw away, so you get this kinda isolation. You can work in parallel on the Quadstone Interfare.
Yeah. So you now have support for this, which I I think you recently added, like, native support, but, like, for your workflow, you just stuck with the old one of checking out all the separate folders. Right?
Yeah, exactly. I actually find that over time, I'm using the desktop app more and more for this,
just because I don't need these separate checkouts, and I just have a bunch of quads running in parallel, and I don't have to think about it. The other surprise hit is the iOS app for me. Every day, I start like, I wake up and I just start a few agents on my phone.
Oh, the the native one. Yeah. The native one.
Yeah. It's just like, it's the quad app. It's the code tab in the in the quad app, and it's the same exact quad code.
Except it runs in the cloud. Right? It runs in the cloud.
Yeah. So you have to kinda configure the environment. Luckily, our environment's pretty simple, so, you know and we just use hooks for it.
So you just use the session start hook and configure it. This is kind of one of the benefits of making quad code really hackable, is it's very easy to do this kind of configuration. And this is something, honestly, I would never have predicted because, you know, I code on a computer.
If you told me six months ago, I'd be writing, I don't know, a third I haven't pulled the data, maybe like a third half, something like this of my code on a phone. That's crazy. But that's
that's what I'm doing today. And you're using parallel agents. At what point did you start using them and how has it changed your work?
Because one thing that I noticed on myself, I don't really use that many parallel agents. I may be, like, two at a time, but I'm someone who well, I I like to be in charge and especially with Claude.
Claude is is is a tool that you can follow it along. It tells you what it's doing. It you can also have, for example, learn mode, which this was shipped a lot earlier where where you can actually follow along.
It gives you tasks. I I feel that, like, staying in one tab and following along the model is pretty fast as well. I can kind of keep in touch.
I'm assuming at some point you must have done this, but then what happened when you changed to parallel? And are do you feel you're losing any control, or it doesn't really matter that much? Yeah.
I I I think there's kind of, like, two modes to think about or kind of like two
kind of workflows to think about. So when you're new to a codebase, learn mode is awesome.
Highly recommend it. For people that are onboarding to the Quadrico team, people that onboard to Anthropic, the thing that we recommend is, so you do, for people that haven't tried it, you do slash config in quad code, you pick the output style, and you can do learn or explanatory.
We usually recommend explanatory because that tends to be better for new code bases that you kinda haven't been in before. For me, once you're familiar with the code base, you just wanna be productive.
You just wanna ship as much as you can, and you wanna be effective doing that. So the world really switches. I don't really go deep into tasks anymore.
I sort a quad in plan mode, I'll have it kick something off. With Opus 4.5, I think it got there.
With 4.6, it just really, really does it. Once there is a good plan, it will one shot the implementation almost every time.
So the most important thing is to go back and forth a little bit to get the plan right. So what I do is I start one, I enter plan mode, I give it a prompt, as it's chugging along, I'll go to my second tab, and I'll start the second quad, also in plan mode, get it chugging along, then go to the third tab, go to the fourth one.
Then maybe I'll go back to the first one when I get notified that it's done, and then I'll come Do up to you have front the of the pickers on or do you turn them off? I actually operate in both modes. Sometimes I do, like, you know, focus mode on the Mac, so I just have it off.
But also sometimes I use the system notifications.
And you're very, very productive with with PRs. I mean, I I think it was very visible. Even around the the holiday breaks on social media, you actually were responding to I think someone reported a bug or or a feature request.
I'm not sure which one it was. And then an hour or two later, it was done because because you did it. You've also talked about, like, number of pull requests you've done on a day, not to, like, show up, but just as context.
What what does a pull request typically involve in terms of com complexity? Are these, like are some some super trivial or some actually, like, larger pieces of work as well?
Yeah. Portworx has each one varies a lot.
Sometimes it's a few lines, sometimes it's a few 100 or a few thousand lines. They're all just very, very different. It's changed so much.
Back when I was at Instagram, think I was one of the top two, maybe top three most productive engineers at Instagram just by volume of code written. Oh, wow.
So I've always, you know, for me, always just coded a lot. Coding is, like, a way that I can express myself, and it's just, like, it's a way that my brain thinks also. And so now I just get to do it.
But I I think with quad code, the the the kind of code that you write, if you are very productive, it it tends to be even just the number of PRs sort of undersells what's happening. Because I I think people that used to be very productive in the old days, before AI assistants, a lot of the code maybe was code migrations or something like this.
So people that shipped twenty, thirty PRs every day. A lot of it was pretty, you know, like, a one liner or kind of migrating a to b or whatever. Nowadays, I ship twenty, thirty PRs every day, but every PR is just completely different.
Some of them are thousands of lines, some of them are hundreds, some of them are dozens, some of them are one liners. It's none of these are kind of code migrations because actually Quad just does those, and I I don't need to be part of that. Shipping this much code or this much more productive, the obvious question that comes up for any, like, software professional is, well, the review.
What the way Teams used to work, and I'm not sure if Instagram did this, but a lot of other companies. So this is you make a pull request, you put it up there, there's a mandatory human reviewer. At Google, there's actually two because there's one on code quality as as well.
How has this workflow changed? How does the hot code team think about code review and how has it changed over time? Yeah.
I'll start by thinking I'll I'll start by talking about how code review used to work for me. So the the way that I used to do it is every time I I also used to be one of the most prolific code reviewers. Oh, okay.
So both. I I met at yeah yeah. Writers and code reviewers.
That's actually and that's one of the benefits of being in a different time zone. Like, I'm not super human, I just didn't have any meetings. And the the way that I approach code review is every time that I would have to comment about something, would drop it in a spreadsheet and I would describe the issue.
So let's say, someone named a parameter in a function badly, would put that in a spreadsheet. If someone did some bad react pattern or something, I would put that in a spreadsheet. And then over time, I would just of tally up the spreadsheet and any time that a particular row had more than three or four instances, I would write a Lint rule for it.
So just automate it with kinda And some kind of so that's what it used to look like. For me, I've always tried to automate myself away because there's just so many things to do.
And this is one of our superpowers as engineers, is we are able to automate all of the tedious work. There's very few other fields where you're able to do this thing.
This is a thing uniquely that we're able to do. And this is a thing that I've just always enjoyed because it gives me more free time, and I get to do the work I actually enjoy. And so today, the way this looks is a little different, but it mirrors this a little bit.
So when QuadCode writes code, it generally it will run tests locally, and this is something Quad just often decides to do when it's relevant, it'll write new tests. You kinda do this kind of verification.
When we make changes to QuadCode, Quad will also test itself. So it'll launch itself kind of in a subprocess, it'll verify itself, and it'll test itself end to end. This is for your
internal QuadCode implementation,
so you have this test suite so they can test itself. Yeah. That's right.
That's right. But it'll literally launch itself just in a bash process and kind of just see like, hey, do I still work? Okay.
So it'll do this. And this this is something that we we just didn't code in. Like, it it just with OPUS four four point five especially, it just sort of spontaneously doing this.
It just wants to kinda check. So so we do this, and then we also run claud dash p, so this is the claud agent SDK in CI. So every pull request at Anthropic is code reviewed by quad code.
And that actually catches maybe like 80% of bugs, something like this. And it's the first round of kind of code review. Quad will automatically address some of these.
Some of it'll
leave to a human because it's not sure what to do. There's always an engineer that does the second pass of code review. And, you know, there there always has to be a person in the loop approving the change.
Mhmm. So on on on the team before anything goes into production, if if you will, an engineer does look at it? Yes.
As you're thinking of code review, would you do this for every type of project or this is specifically because you now know that this actually has real world impact, people depend on it, you know, there's a lot of users. Let me put it the other way around, like, can you see places where you would just not have an engineering review
code? What situations would that be in? I think it depends how how how it's used.
Yeah. I'd agree with that. Like, you know, if you're building some personal side project, like, can just y'all straight to main, you know, like Even
even before AI, you would have not reviewed. You just trust yourself or, you know, you just ship to production or SSH to production and do some changes, that kind of stuff. Right?
Exactly. Exactly.
The very first versions of Cloud Code that were internal, like, you know, I committed straight to main. But then, you know, as soon as you have users you know, for Anthropic, our main customer base is enterprises. This is what we care about the most.
For us, for safety reasons, security is really important, privacy is important. These are these are all related. It's also very important for our customers.
And so because this is an enterprise product, it has to be secure, it has to be we have to make sure that it meets a certain bar. So we definitely use a lot of automation, but at least for now, there has to be a human in the loop just to make sure. One thing that
is just known about LLMs is they're nondeterministic. And by putting LM as a reviewer, Claude doing a review, like, it will give good feedback.
But how would you deal with the fact that you can't be sure if it's always giving the feedback, you cannot be sure that even if it's capable of catching an issue that it will necessarily catch that. Are you doing anything in in this loop to do deterministic thing?
For example, linting is very deterministic as you will very well know. Like, have you thought of marrying some of these ideas or are using, for example are you using linters on the code base or you found no need for it? Yeah.
Absolutely. Absolutely. Yeah.
You you So this is just a Yeah. Yeah. We we have type checkers, we have linters, we run the build.
Clauda is actually so good at writing lint rules. So actually, what I do now, I used to tally stuff up in the spreadsheet. Now what I do is when a coworker puts up a pull request, and I'm like, this is Vintable.
I'll just be at Claude. Please write a Vint world for this in that PR, on their PR.
And we have you know, you just run, like, slash, I think it's, like, setup GitHub or or something like this. You can do this in quad code and it'll install the GitHub app, which then makes it so you can tag claud on any pull request, any issue. I use this every single day.
So very, very useful. So you want these deterministic steps. Also though, there are ways to get Quad to be a little bit more deterministic.
So for example, you can do best event, you can have it do multiple passes. This is actually quite easy to do. So, know, for example, the coder view skill that we use internally, it's open source, and it's available in the quad code repo.
And so all we do is we launch parallel agents to do stuff, and then we launch parallel deducing agents to check for false positives. But essentially, best event, the way you implement it is all you say is, quad,
start three agents to do this, and that's it. Boris just talks about building that enterprise infrastructure layer, the auth, the permissions, the security that has to all work before you can ship to real customers. This makes it a great time to speak about our seasoned sponsor, WorkOS.
If you're building any SaaS, especially an AI product one, then authentication, permissions, security, and enterprise identity can quietly turn into a long term investment. SAML edge cases, directory sync, audit logs, and all the things enterprise customers expect.
It's a lot of work to build these mission critical parts and then some more to maintain them, but you don't have to. Workhorse provides these building blocks as infrastructure so your team can stay focused on what actually makes your product unique.
That's why companies like Anthropic, OpenAI, and Cursor already run on Work OS. Great engineers know what not to build. If identity is one of those things for you, visit workoaz.com.
And with this, let's get back to building Cloud Code with Boris. How does Cloud Code work in terms of arc architecture? So as as an engineer, how can I imagine its setup?
It's we we covered some of this in the the deep dive, and I think you told me that you had some pretty complex ideas when you started and you just simplified a lot of Yeah. Yeah. It's very simple.
Like, you know, there's not much to it. There's
a core query loop, there's a few tools that uses, we delete these tools all the time, we add new tools all the time, we're just always experimenting with it.
So there's kind of this core, kinda agent part of it, then there's the two e part of it, and then there's actually a ton of different pieces around security and making sure that everything that Quadco does is safe and that there's a human in the loop for when it happens. And
by safety, do you mean as as a user when when it's doing stuff on my computer or also as anthropic monitoring
use cases that that could be deemed unsafe? Yeah. There there's kind of a couple versions of this.
Safety, there's just many, many layers, and for things like safety and security, there's no one perfect answer. So, you know, it's always a Swiss cheese model. You just need a bunch of layers, and with enough layers, the probability of catching anything goes up.
And so you just have to kind of count the number of nines in that probability and pick the threshold that you want. And so for something like prompt injection, for example, we do this generally at three different layers.
So let's think about something like web fetch. So quad fetch is a URL, and it reads the contents of that web page, and then it does something in quad code.
So one of the risks for something like this is prompt injection. Maybe there's an instruction on that website to be like, hey, quad, delete all the folders, or something So like we think about this in a number of ways.
The most basic way is it's an alignment problem. And so OPUS 4.6 is the most aligned model we've ever released, because we've taught the model how to be more resistant to prompt injection. And so you can read about this on the model card, and I think it was part of the release.
The second part is that we have classifiers at runtime where if there is a request that seems to be prompt injected, we block it, and we just make the model try again.
And then the third layer is for something like web fetch, we actually summarize the results in using a sub agent, and then we return that summary back to the main agent. So again, this kind of reduces the probability of prompt injection.
And so you can kinda see how this isn't just one mechanism. It's it's a layer, and by by having a bunch of these different layers, it just reduces the probability a lot. One interesting technical choice that you've also mentioned is is using RAG or not, RAG
retrieval, augmented generation. And you mentioned how in the earlier version of Cloud Code, you use a local vector database to to get some to to speed up search, and you layer through this away. Can you talk about how this one because this was another example where, I guess, did the model get better?
Yeah. I mean, this is one of those things where we try so many different things. We try so many different tools, and just statistically, most of them we throw away.
Even something like the spinner in quad code, I think it's gone through like a 100 iterations,
I wanna Oh.
Just the spinner. Know, out of those, we've landed maybe like 10 or 20 in production, and like 80 of them I probably just threw away because it didn't feel good enough. So just statistically, almost all the code we write, we throw away because it's just so easy to write this code and try stuff and see what feels good.
So for something like RAG, we tried a bunch of different approaches early on. So the first one was RAG for retrieval, because I was just reading up how people were doing retrieval and it seemed like all the papers were talking about RAG.
And so the way I did it was it was like a local vector database. I think it was written in TypeScript, and you just looked on the user machine. And then I was using some embedding model that was in the cloud to compute the embeddings before storing it.
And that worked pretty good. But there's a lot of issues with Rag. So, for example, I was finding that the code drifted out of sync.
Like, if I make a local function, it's not yet indexed, and so Rag isn't gonna find it. There's also this question of how exactly is the index permissioned? So who can access it?
I can access it, but then how do we encode that in permission policies? How do we make sure no one else can access it? How do we make sure that if there's a rogue IT person within the company, they can't access someone else's data?
This is really, really important that we think about this. Yeah. And so we just decided it was sort of working, but it also has a lot of downsides.
And so we tried a bunch of other stuff. One of them was just using the model to kinda index everything recursively. That was kind of a cool idea.
There was another version where we just tried glob and grep. We tried a bunch of different stuff.
It it turned out that agentic search just outperformed everything. And when I say agentic search, it's a fancy word for glob and grep. That's all it is.
Nice. So so the model
both got good enough and you realized that it can use these tools pretty efficiently.
Yeah. And this was partially inspired, honestly, by my experience at Instagram. Because at at Instagram, click to definition didn't work because the the dev stack was just borked, like, half the time.
And I think now it's better. And so what engineers have learned to do instead is let's say you're looking for the definition of the function foo. Instead of click to definition, what you would do is you would use the global index, which is quite good at meta, and then you would search for foo per opening parenthesis.
And this worked pretty well. And it's funny because like this works for the model pretty well too.
Interesting how one one idea from one area can come to the other. One of the
more advanced parts of Cloud Code that we also previously talked about is the permission system. Can you talk about what was complex about it?
And also, recently opened source sandboxing. Right? Permissioning is really complex.
There's like everything else that has to do with security, it's a Swiss cheese model.
There are a number of classifiers that run to make sure the command is safe. And there's also static analysis that we do to make sure the command is safe. As a user, you can also allow list particular patterns that you know to be safe.
So for example, some standard Unix utilities we pre allow because we know they're read only, because we know they can't expository data or anything like this. So we just won't prompt you for permission.
But actually quite a few tools fall into this category because even something like the find command, there's actually a way to execute arbitrary code as part of that command, because there's there's, like, system flags that you can use for this.
Or even something like the said command, there's ways to use this. So there's just, like, all this, like, arcania about these various Unix utilities where it's actually not as safe as you think. And so we wanna be, by default, fairly conservative about what we allow by default.
As a user, though, you can configure an allow list. So you can say, for example, these patterns are allowed, these patterns are not allowed, And so we we let you define that, and we also check this allow list to to make sure that it's safe.
Yeah. And then you you have this, like, neat permission system where every time you run a command that needs permission, you can decide to run it once, or run it for either this session or whatever it makes sense, or just to globally allow it going forward. Right?
That's right. This is a funny artifact. This was actually in the very, very first version of quad code.
This is the way permissions worked. This is the very first release. This was, like, September 2024,
the first internal release. I remember at the time, we weren't sure whether agentic safety could even be solved. And so there was actually a lot of pushback internally from safety teams because they were like, okay, like, you can't just run let the model run bash commands.
Like, that's unsafe. So, like, what do you do? Like, this is not a solvable problem, so we can't launch this.
I brainstormed with Ben Mann, and Ben started the labs team, he's one of the founders at Anthropic. He's actually the person that hired me to Anthropic. We just come up with permission prompts as the way to do this.
You you put the human if you're not sure, just ask the human, and and they can decide.
Yeah. I wanted to ask you about how software engineering is done in general in terms of Anthropic.
And one of the first questions, which is a, I guess, a more formal one, but or from the outside, is titles or lack of them. Everyone at Anthropic has the same title member of technical staff. Why did this happen, and what does this result in?
This kind of like everyone there are basically no titles, right, except for one. I think it's kind of an acknowledgement that
everyone just is figuring stuff out. And if if you kind of squint and look at the work people are doing, it's all quite similar, and it's it's kind of quite generalist.
If you talk to the average software engineer, they might not just be doing coding. They might also be doing a little design. They might also be talking to users.
They might be writing their own product requirements. They might be writing software and also, you know, doing research.
They might be writing product code and also infrastructure code. At Anthropic, there's a lot of generalists. This is also, you know, from my background, is one of the reasons that I gravitated towards it.
And I I I think member of technical staff just kind of encodes this in in the way that people talk to each other even if they don't know each other. Without this title, the default would have been I see your name on Slack and under your name it's a software engineer. And then I'm like, well, okay, I guess you're the coding person, so I'm not gonna ask you product questions.
But when everyone's title is member of technical stuff, by default you assume everyone does everything. And so it kinda inverts this relationship between people, even if you don't know each other well yet.
In a way, it's kind of this optimism built into the structure.
I think it's also a glimpse of the future, because I think this is where software engineering is going. I think this is where every discipline is going,
is more of this generalist model. It definitely feels like it in in software engineering. And I've heard this funny comment by Marc Andreessen, how he said that there's this Mexican standoff happening in the tech world where the the designers are are saying that they're actually now doing, like, PM and engineering work.
The engineering are saying that we're doing design and and, like, every everyone thinks they're doing the work of the others, and they're kinda standing there like, I'm doing your work as well. But when the reality is everyone's role is expanding, most of it thanks to AI because it makes easier for an engineer to do product work or for a product person to engineer work and so on.
So it's what what you've said. I I remember back in the back in June or July of last year, I I walked into the office,
and the data there's a row of data scientists that sit right next to the Quadco team, at least at least at the time. And I walked in, and our data scientist for the Quadco team had Quadco up on on his monitor. And he he was using it, I was like, this is interesting because you're you're a data scientist.
Did you like, why are you using a terminal? Like, you you didn't have Node. Js installed, cause we depended on Node.
Js back then. I was like, are dogfooding it? Are you just trying to figure out how this thing works or something?
He was like, no, I'm using it to run queries. He was just using it to run SQL, it had little ASCII visualizations in the terminal.
And then the next week, the entire row of data scientists had quad code running on their computers. And and this expanded.
And so if you look at the team today, on the quad code team, everyone codes. The engineers code, our engineering manager codes, designers code, data scientist code, our finance guy codes.
Everyone on the team codes. And I think part of it is, code just makes it so easy, so you don't really have to understand the code base, you can just dive in and make small changes quite easily.
But I think another thing is,
people are able to use quad code to do their jobs more, whether it's, you know, financial forecasts or, you know, data science or whatever. And by doing this, it's actually quite an easy crossover to just use it to write a little bit of code also. So it's it's just a way to dip your toe in the water.
One other interesting thing about how you work is Kat Wu was talking about she is I guess, you you the title is the same, but people might gravitate for a role a bit bit more. I understand she's a little bit more on a product role. But she said that PRDs are just not really written inside Entroffing.
And PRDs, product requirement document, it's a well known artifact across big tech and increasingly over larger startups where you write a spec and the idea is that you write down your thoughts, people align, you send it over, and now you know what to build. But apparently, you're not doing much of this or at all.
Some of this, I think, is because Anthropic is still, you know, it's still a start up. So you you don't actually have to align with that many people usually. You can just kinda talk about it or do it in Slack or whatever.
But, yeah, also part of it is, you know, like, Kat used to be an engineering manager. She's she's extremely technical. And I think this is this is the way that, you know, our product team thinks about it too is, you know, better to send a PR.
You're you're doing a lot of prototyping instead. So, like, that that's also something where
when we talked about how you're building Cloud Code early on, you were showing actually, you had a whole thread about the number. I think you did, like, 15 or 20 prototypes for the the to do list and all of them interactive working.
And what surprised me compared to my past experience, you said that, well, you did this in, like, a day and a half, all all 20, tried it out, got a feeling for it, which incomprehensible for me, it it would have taken a week or two weeks and people would have not done 20, they would have done three.
Yeah. So, like, are you seeing this is there an increase in in prototyping and and building and showing instead of, writing things?
Yeah. Absolutely. I mean, on our team, the culture is we don't really write stuff, we just we show.
It's a little hard to reflect back on the time before, because I I think now just prototyping everything is so baked into the way that we build. Just everything is prototyped multiple times.
Like, you know, we launched agent teams earlier this week. This is our implementation of swarms. It's very exciting because it just lets Quad do more work for longer, more autonomously.
You have a bunch of different uncorrelated context windows, and you have this kind of communication between agents.
They can just do more. This is something that Daisy and Suzanne and other folks on the team and and Karen, they they prototyped this for months.
And they tried, all in all, probably hundreds of versions of this before they got a user experience that felt really good. It it was just really, really hard to get right. And there's just no way we could have shipped this if if we started with, you know, like static mocks in Figma, or if we started with a PRD or something like this.
It's a thing that you have to build, and you have to feel, and you have to see how it feels.
And to me, one of the big takeaways even from there was that, like, we probably should prototype more and just be more daring, or just
release your priors of how long it took to build a prototype or who needed to build. Back then, was always an engineer that needed to build, but it's probably not true anymore. Yeah.
That's right. I mean, we're in this world right now also where we just we don't know what the right answer is. You know, I think back in the old way of building, the cost of building was high, and so you had to actually spend a lot of effort to aim very carefully before you take your shot.
Because after you take your shot, it's very hard to course correct, you can only take so few shots. But now it's changed.
The cost of building is very low, but also we don't know where we're aiming. So we just have to try and we have to see what feels good. And it's just very very exploratory.
And I think also a big part of it is humility, where personally I'm wrong half the time. I'd say most of my ideas are bad, at least half of them are bad.
And I don't know which half until I try it. And I get feedback from others as well sometimes. That's right.
It's like I I have to try it myself and then I have to see what others think because, you know, my intuition does not always match others. When you were showing these prototypes of just how the
the tasks were built, you were telling me that you built the prototypes, and then your process was always you first, like, looked at it, you tried it out, you got a feel for it. And then for the ones that you felt were good, you showed it to others, and sometimes they give you feedback like, nah. This doesn't work.
And then sometimes when it felt good, then you shared it even broader. So I feel like, you know, like it's it's a mix, right, where sometimes you can decide already,
and then sometimes you get feedback, and then eventually some good ideas come out of it. Yeah. And there's a lot of examples of Like, we we launched this kind of condensed view for file reads and file search, just because the the model was just so agentic now.
Like, I felt like half the screen is these, like, file reads, and I actually don't care, like, you know, a read a thing. I don't really care what it is. And so we condensed this down to make the output a little bit more readable.
I really liked it after probably 30 prototypes or something like this. It took it took so much effort to make that feel really good and clean.
We rolled it out to employees at Anthropic for about a month, and we had everyone dogfooded. And I fixed another probably dozen dozen bugs, dozen tweaks based on all this feedback. We launched it externally, and almost all users liked it.
But there were a few users that didn't, because they want more expanded output. And so on the GitHub issue, I was just going back and forth with people to be like, what don't you like?
And people gave a lot of feedback, I shipped another version. Then some people liked it, some people didn't. And so I iterated again and kinda made it good.
It's actually, I think, almost there where people can configure it the way that they want, but still the default is really good. But this is just the process, you know, we we get it right some of the time, we have to learn from our users, we wanna hear from people so we can get it right. Do you use ticketing systems for your work, where, you know, where where you capture, like, here's the work I I want to, or do you just pretty much do the work as it comes in?
So at Anthropic, we we leave it up to teams. On the Quadco team, we leave it up to every person. Different people use use this differently.
For example, I don't use a ticketing system. Some people like to use Asana or Notes or something like this.
One of the coolest things that I saw, this was maybe like three months ago or something, we launched plugins. And the way we launched that is Daisy for a weekend. She had a very early version of swarms.
And she let the swarm run, and she told that your job is to build plugins. You have to come up with a spec, then you have to make a Asana board and split up into tasks, and then all the different agents have to build it. And she set up a container, and she set up a quad in dangerous mode.
And she let it run for the entire weekend. It spawned a couple 100 agents, they made a 100 tasks on the Asana board, and then they implemented it.
And that's pretty much the version of plugins that we shipped. These kind of coordination systems, they used to be for humans, but I think nowadays it's just as much for models.
Let's let's talk about Claude CoWork.
It's one of the very important things about us. It looks great, so I I tried it out.
It's inside Claude, you have the CoWork tab there, and and you can I I feel it's a lot more visual way of of running agents, interacting with them? One of the surprising thing I just heard that it was built in ten days.
Can can you take us through, like, what it took to build it and what does it actually mean? Was it from the idea or, like, from the decision of of building it, and how how big was the team building it? The team was really small.
It was just a few people. For a long time, we felt that there is some product to be built for non engineers. The reason we felt this is for a long time, people that were using Cloud Code are non engineers.
And so, you know, in the product world, when you see latent demand, you see people jumping through hoops to use a product that was not designed for them, That's a really good sign it's time to build another product that is built just for them. There's all these people on Twitter that there's this one guy that was using Quadco to monitor his tomato plants.
I just I evolved this. It was like, get a webcam set up, and Quadco was like, oh my god. I'm so happy that our plant is budding.
And because it had a webcam, and just like every day it was monitoring it, and it was so happy that the tomatoes were growing. There was someone that was using Quadco to recover photos off of a corrupted hard drive, and it was like his wedding photos.
Wow. Know, like I said, our entire finance team at Anthropic uses quad code, our sales team uses quad code. So there's just all these people that are non engineers that were using it.
And at that point, quad code, it's available in a lot of form factors. Right? Like, we started in a terminal, then we expanded and we added support for IDEs.
So we have extensions for, you know, every Versus code based IDE, every JetBrains based IDE. There is also iOS and Android apps. There is the desktop app.
There is web. So then then there's, like, Slack and GitHub apps. So we kinda expanded to all these places to make quad code easier for engineers.
But ultimately, none of these are built still for non engineers. And so quad code evolved a lot, but it still felt like there was a there was kind of a gap, and there's a product that could make this even easier for people. And so for the last couple months, the team was kinda hacking around and just seeing what is the right product.
And at some point, someone came up with this idea of what if we just take quad code, add some guardrails, so for example, co work ships with a virtual machine. This is one of the many ways that we make sure it's really safe, especially for nontechnical users that don't wanna read, like, bash commands to figure out what it what it's doing.
And they were hacking on this, I think it was something like ten days and 200 or something. It was just fully built with quad code,
and then we shipped it. And can you give us a sense of, like, the complexity behind an app like this and if if we can walk through, like, what parts needed to be built? Because from the outside, it's a little bit hard to tell, like, is this just a nice UI wrap that's, you know, like, I don't know, like, a few 100 lines of code.
I'm just being obviously I'm I'm provocative here. Or behind the scenes, it's actually a really complex piece of software. The reason I ask is, like, Uber is a great example where people look at the app.
It looks really simple. I work there, and I know it's it's really, really complex because you don't see a lot of the complexity. There's a lot of regional things.
There's a lot of back end things that are all hidden. So from just from looking at a cloud co work, it's it's hard to tell how much of this is is additional business logic that needed to be carefully thought out versus it's actually just a nice little thin wrapper on top of the the model.
In in some places, I think there's less complexity than you would think. In some places, there's more complexity.
So on the product side, it's quite simple because it's just the Quad desktop app. So download the Quad app, it's a single desktop app. It has a tab for co work, it has a tab for code, it has a tab for chat.
So it is just one app, and we're able to inherit a lot of that product logic. There's some UI rendering code. Under the hood, it's just the same Quad code running, it's the same Quad agent SDK that powers quad code.
A lot of the complexity actually is about safety. Because like I said, we know the user is nontechnical, and so we just want to make sure they have a good experience.
And so, for example, if someone launches the app and then they delete a bunch of family photos, that's really not good. And so we wanted to make sure that we protect against this, so you can't accidentally do that. And so that's where a lot of the guardrails came from.
So there's a bunch of classifiers running on the back end. This is for safety and, again, extra mitigations for things like prompt injection and, you know, risks like this around security. On the front end, there's an entire virtual machine that we ship.
There's a bunch of operating system level integrations to make sure people don't accidentally delete things.
So just around safety, there's a lot there. And then we also have to rethink the permission system because we inherit the permission system from quad code.
But also for co work, actually, big part of the value is not just running locally, but it's using all of your tools the way that quad code uses it. But the thing is, for nontechnical users, your tools aren't really available with CLIs. Some of them are available over MCP.
Many of them are available in a browser. And so, co work is really, really good when you pair it with a Chrome extension. This is the way that I usually use it.
So, you know, for example, I use it every week to do project management for the team. We a spreadsheet that tracks kind of at a really high level what everyone's working on, and this is kind of my personal way of project managing. Other people, like I said, use Asana, other people use Notes or whatever.
For my own tests, don't use anything. But kind of for the team overall, have the spreadsheet. And I have co work on a check-in.
And I I just ask co work every week, hey, can you look at the rows for any status that has not been filled out? Can you just ping the engineer on Slack? And so it'll open one tab in Chrome for the spreadsheet, it'll open another tab with Slack, and then it'll just start messaging engineers on Slack.
And it just one shots it. There's like one engineer's name for some reason that can't auto complete, but everything else it just gets.
And so this is actually like, from a safety point of view, we also thought pretty deeply about this Chrome extension, how this works, and how the permissioning model should interact with this local permissioning model. So there there's also a bunch of code to kinda make sure that that's that feels smooth. And what's the tech side behind this?
I I assume a lot of it will be similar to the the Cloud app, but is it is it Electron, TypeScript, those kind of things, or or something else? Yeah. Just Electron and TypeScript.
Actually, some of the people working on it are early Electron folks. So Felix, who's, you know, the creator of of Cowork, he was a really early engineer on Electron, and he helped build it.
Oh, amazing. And the Cowork launched macOS only. What was the reason for, both for choosing this platform first and for now only choosing this platform?
Yeah. So Windows coming soon. I think probably by the time this podcast comes out we will have Windows support.
We just wanted to start early and start learning. You know, like everything we do at Anthropic, it's kind of like the way that I told my own story, one of the things I like about Anthropic is it just really really matches the way that people here think about it.
You know, back to this point where we don't have high certainty about the things that we build, and our intuition is often wrong, and so we just have to learn from users and figure out what people actually want, and just spend a lot of time listening to people and understanding the feedback deeply. This is the way that we build a product.
And so we always launch a little bit before it's ready. We did this for QuadCode. When we launched QuadCode initially, it didn't even support Windows.
Also, it didn't support a lot of different stacks, and then over the coming weeks, we added support for every stack. Now QuadCode supports every single stack. You know, like Windows, whatever weird Linux distro you use, Mac OS, we support everything.
And so for Core Work also, we just wanted to launch early. We wanted to start with Mac because that was just the starting point. But, yeah, it's it's gonna support everything.
One one thing you mentioned is is getting feedback.
I'm curious, both for Cloud Code and for Cloud Code Work, how do you go about things like observability, monitoring? When you're rolling out, do you use any feature flags?
And I'm I'm more interested in, like, did you build custom tools for this, or did you decide to use certain vendors? Because especially for observability, I'm sure that this is this is both important, but it also sounds like pretty high scale in terms of the number of users that we can derive or this will not be a small operation.
Yeah. There's there's some off the shelf vendors that we use. There's some custom code that we use.
So it's it's actually a mix of both. There's nothing too surprising about it. There's one thing about Anthropic that's kinda interesting is because we're an enterprise company and we care a lot about privacy and security, we can't see people's data.
And so, you know, if someone reports a bug, I actually can't pull up your logs to kinda see what's going on. A lot of work goes into kinda figuring out how to log events and things like this in a privacy preserving way.
This is just very important to the way that we operate. For co work, what kind of learnings have you had so far? It's it's it's it's been out for, I think, a a few weeks now.
Did you see something unexpected? Are you shaping the product based on feedback that you're getting? Yeah.
Every day, the team is landing so many fixes. The most surprising thing is just how much people are loving it, to be honest. When Quadricode first came out, it actually wasn't an overnight hit.
This is something people think it was, but it was sort of a slow takeoff at the beginning. And I think the first big inflection was in May when we released Opus four and Sonnet four.
That's when it really clicked, And that's when our growth became exponential. But at the beginning, it was sort of a research preview. People didn't really know how to use it.
Some people got it immediately, but most people didn't. It took it took a little while. For Cowork, it's a much steeper growth trajectory than QuadCode was at the beginning.
So it's just been an instant hit, and that that's actually a bit very surprising. I I didn't really expect that. One of your new releases,
which came out just very recently, it was I think yesterday or the day before when we're recording this podcast, was agent teams. And I as I understand the idea with what agent teams, agent forms, instead of single agent, you can have a lead agent that can delegate to its different teammates.
How did you start experimenting with this and how did you decide to ship it now? We're always doing experiments.
Right? There's there's there's all sorts of ways to get more mileage out of out of quad code.
One way you can do it is by extending context. Another way is auto compacting context, so it's essentially infinite context, and that's what we have right now. Another way is using sub agents, so you have multiple agents kinda working together.
There's just like a lot of different approaches to get a little bit more mileage out of the context window. There's this one idea called uncorrelated context windows, that's what we call it.
And the idea is you have multiple context windows, but they essentially start fresh, so they don't know about each other.
And so an example of this is like a correlated context window is if you have the model and it does a task, and then you just do a second task in that same context window. And in this case, the second task knows about the first one because it's in the same window.
But for something like a sub agent, it's uncorrelated because the main agent prompts the sub agent, but the sub agent's context window is fresh. Besides that prompt, it doesn't know what's in the parent context window. And you can see this actually a little bit in, for example, sub agents versus skills.
Because when you run a skill or a slash command, it sees the parent context window, versus for a sub agent, it doesn't.
So it's uncorrelated. There's some cases where you want that context, there's some cases where you don't. And there's this kind of interesting thing where uncorrelated context windows and just throwing more context at the problem and throwing more tokens at it, when the windows are uncorrelated gives you better results.
It's actually a form of test time compute to do this. And for something like Teams, we've been experimenting with this for a while, I think since maybe, like, October or September or something like this.
And it really just felt like with Opus 4.6, it clicked, where the model figured out really how to use this.
And sometimes you see these kind of cute exchanges where the agents are talking to each other and they're like discussing something, and it's just very cool to see. It's very like humanistic in a way. But there's other times where you just get very good results.
And so we had a bunch of internal evaluations, for example, where we have Quad build something very, very complex, something more complex than what a single Quad would build, and we saw the results just really, really improve with Opus 4.6 with Teams.
And that's why we felt it's the right time to release it. We also wanted to be careful, and the reason you have to opt into it, the reason it's a research preview is it uses a ton of tokens, because it's just a bunch of quads that are running.
Not everyone wants this all the time. So just excited to see how people use it and hear the feedback.
It's something you want for fairly complex tasks, you don't probably want this for every task. The main quad decides the roles for the sub quads. We don't have a regimented way to do this, it's context specific.
I wouldn't say there's one right way to do it. I think actually a lot of the magic of this comes out of this idea of uncorrelated context windows. It's less about the specific configuration of the agents, but it, you know, it's something that people should experiment with.
I don't think there's a one size fits all. Have you seen use cases even in even I I know it's it's so researched, but have you seen use cases where it could look it looks promising, this approach, this swarm approach? Well, you know, like I said before, plug ins were fully built with swarms.
There there's a bunch of other features since that or built them this way. So, yeah, I I think for anything where you see a single quad struggling, the swarms can help. It's it's an interesting tool to look at.
Talking about change in in general, with Andre Karpathy, you had a really interesting exchange back in December where when he posted that he's never felt as much behind as as a programmer as he is now because of the progress with AI. And then you shared the story about how you started to debug a memory leak the old fashioned way, and then Claude just one shot at it.
I think it was a reflection of, like, how everyone is feeling that things are changing so fast. And in holiday break, I started to feel that things have really shifted. How did you, I guess, come to terms with this or start to embrace this change?
This is something I really struggle with. The model is improving so quickly
that the ideas that worked with the old model might not work with the new model. The things that didn't work with the new model might work or with the old model might work with the new model.
And it's weird because there's just not a lot a lot of other technologies like this. So I I just don't really have a lot of experience to draw on to figure out how I should approach this.
And it's been this new skill that I've had to learn. In a way, it's like you just always have to bring this beginner mindset. Honestly, I'm using the word humility a lot, but you always just have to bring this kind of intellectual humility because just all of these ideas that were bad before are now good and the inverse.
I think that's honestly it. It's something I constantly have to remind myself about. And back in the it's funny, back in the old world, when someone tries an idea again and we've tried it in the past and it didn't work, usually the feedback is like, why are you doing this again?
Yeah. You should learn. This used to I mean, we used to call it bit of a gatekeeping, but it was somewhat valid where I know with architecture, someone came and said, like, why don't we do microservice?
And someone said, we tried it and it didn't work. And if we tried it a year or two or three years ago, it was kinda valid. Right?
Because not much has changed. Yeah. That's right.
That's right. And something like Microsoft, it's just funny because it's like every ten years, it goes in and out of in and out of style. But yeah, now now it's I think the first time ever where it's actually not crazy to just try the same idea every few months because the model improves and it just works.
And I I actually see this with engineers on the team, like new people that are newer to the team, people that are newer to engineering, sometimes do things in a better way than than I do. And I just have to look at them and I have to learn, and I have to adjust my expectations.
You know, like, an example of this is, you know, when when we release features, sometimes I'll screenshot myself using them on X or on threads or whatever just to kinda talk about it. But recently, Tarek, our DevRel guy, he actually codes a lot.
He's amazing. And he just started automating this. So he's having like quad code generate its own videos for for its launches, and he just started doing this.
And, you know, this is something like I thought would be, you know, maybe it's possible.
It's not something I would have tried because I wouldn't have thought the model was ready, he just he just did it and it just kinda worked. One thing that I've I felt like just a bit, like, odd about, and I think a lot of developers can relate, is I've come to terms with this starting from Opus 4.5, the and and also similar models.
Like, I think GPT 5.2 gave me similar vibes as well. The models have been just really good at writing code, and I I realized that I don't think I will handwrite the code when I'm get when I want to get stuff done.
If if I actually want to, you know, get the pleasure of writing, I can still do it. But one thing I reflected on is it's just been so much effort to get good at coding.
I I remember when I when I was learning, when I I started from, like, kind of hacking around to go into university to learning c and then c plus plus, and it it was just bloody hard. And, actually, you know, going through my my first few jobs where I started to become better at it, I became better at debugging. And there's a point where, like, a lot of my identity was tied to being good at coding.
That's how we used to get jobs or higher paying jobs. When I was an engineering manager, when we designed the interview loop at Uber, we we had talked with managers of what we need to screen for, and we we talk like, well, what do developers do most of their time? About 50% of the time they code.
Therefore, we place about 50% of the signal was all about coding. So So there was a lot of things tied into coding because it it is just hard.
I think we all know that it takes grit, it takes some level of intelligence to get good at it, and there's a sense of loss of, like, well, I I think it's great on one end that the model can do it, but it feels that something really quickly got taken away that I don't think I personally thought it would happen this quickly.
And I'm I think a lot of other people are are feeling that they some people move on a bit easier, but there's definitely this this sense of of grief. How did you think about it?
Because, again, you're you're an example of you wrote so much code at at Facebook also outside of it. I know it was just a tool of doing it, but not many people could do what what you did.
And now the models can also work as good as you have, if not better. That's the challenge.
Yeah. I think it's something that used to be a thing that we do as software engineers, it's becoming a thing that everyone is able to do.
There was a moment, you know, like, when I started coding, it was a very practical thing and it was a way to get things done. And at some point I just fell in love with the art of coding and languages and the tools themselves.
And at some point I kind of fell down this rabbit hole, I wrote
a book about a programming language TypeScript. You wrote the first ever TypeScript book with O'Reilly.
Yeah yeah yeah, that's right.
It was was funny, actually. There there was this, like there was this amazing moment for me in my little town in Japan. I went to the bookstore, and I I found that book translated in Japanese.
No. In this tiny town, and that was just, like, the coolest moment. And then I actually realized I I don't remember TypeScript at all, because I was only writing Python for a couple years at that point.
Yeah. And then, like, at some point, I started the the first the the biggest TypeScript meetup in the world, that was in that was in SF, and I got to meet kind of a lot of my heroes. There was, like, Chris Colwell, who wrote, like, general theory of reactivity.
There was Ryan Dahl, the guy that made Node. One of the first times that I I went really deep into this this community and just the language itself and the the tools themselves.
And for something like TypeScript, there's this beauty in the type in the type system, because Heilsberg is just, like, he he he's just brilliant. Like, the the idea of, like, conditional types, and just like anything can be a literal type. And there's there's these very deep ideas that even the most hardcore functional languages do not have.
Like, even in something like Haskell, it doesn't go this far, and Anders just took it, and he pushed it much further than it had been pushed. And, know, like, Paymer and a bunch of other folks kinda explored a lot of these ideas and thought of this.
And I think for them, was also very practical. Because they had these large on type JavaScript code bases, how do you gradually migrate it to something typed, you have to come up with these very beautiful ideas to do this. For me, Scala was another kind of rabbit hole that I fell into in kind of like this functional programming world, and still, when I write code and when the model writes code, I always think in the types first.
That that's what matters is what it what is the type signature? That matters more than the code itself and getting that right. So there is this beauty to it.
There's a there's an art to it, for sure. But in the end, it's a practical thing. And in the end, this is a thing that we use to build things, and, you know, it's a means it's a means to an end.
It's not
an end to itself. I I think one metaphor I have for kind of this moment in time that we're in is the the printing press in, you know, like the the fourteen hundreds or whatever. Mhmm.
Because at that moment, it it was actually quite similar. Right? Like, there was a group of scribes that, you know, knew how to write.
And it it it was, as I understand, of course, we never lived there, but as as I imagined, it was it was a hard process to learn. You needed to to learn. You needed to get the equipment.
You probably needed some sponsorship or being selected Yeah. Yeah. Practicing because you needed to produce the same thing over and over again, and few people could do that.
And I assume it was either high prestige or highly paid or who knows? Let's assume it was, but then the printing press came along. Yeah.
Yeah. And at least in Europe, like, you had to like, a lord or a king or something had to employ you, and then you had to go through years of training. And there was this class of scribes that knew how to write, they were employed by someone like this.
Often the king themselves, the queen, was not literate. So it was this very very niche skill, and it was like less than 1% of the population was literate in Europe, you know, back then.
And then the printing press came out. And what happened? So the cost of printed material went down something like a 100 x over the next, I think, thirty years, fifty years or something.
The quantity of printed materials went up like 10,000 x in the next fifty hundred years. This was the first effect.
Literacy, it took a little while for it to catch up. So I think global literacy, it went up to something like 70%, but that took another two hundred years, three hundred years.
Because learning to read is just very hard. Learning to write is hard. It takes a lot of effort.
It takes education system. It takes infrastructure to have paper and ink and the free time to do this instead of working on a farm.
So it took early stage of industrialization to actually get there. But I think this effect of making it so this thing that was locked away in ivory tower, now it's accessible to everyone, this was just, you know, like, none of the things around us would exist today without this.
Like, if if we weren't literate, if the people that built, you know, this microphone weren't weren't literate, it would have just been very hard to have a modern economy. None of these things would exist. And I I just kind of think about back then, if people had to predict what would happen when the printing press came out, no one would have predicted that the microphone would become a thing.
So I I just feel like this is this is the best analog
for for the moment that we're in right now. And it's interesting that you say that some of the kings were illiterate who were employing the scribes because if we're being honest with ourselves, we have business owners who know what they wanna build and they are employing software engineers because they themselves cannot write code.
And I think we we like to mock the CEOs who are coming there, coming to the team. They they might even have a a drawn prototype or whiteboard and saying this should be easy, but, of course, they don't understand how difficult it is. But there seems to be a bit of analogy where where there's a person who wants what they want, but until now, they needed to hire a software a specialist who can build that, and there's always that disconnect between the idea and the person.
And just like with the printing press, like, what would happen if they could actually express them? Like, the king could actually read or write their own letters. They wouldn't need that middleman, and it things become more efficient.
I mean, of course, for the scribe, it's not the best news necessarily, but I mean, smart scribes can also do, you know, so someone needs to, like, write the books, run the press, etcetera.
Yeah. Exactly. And if you think about what happened to the scribes, right, like, ceased to become scribes, but now there's a category of writers and and authors.
Like, these people now exist. And the reason they exist is because the market for literature just expanded a ton.
And I guess also if we think about, like, back then, a scribe's work was read by a few people. And with the printing press and author, there's a lot more authors and some of them are not really read, but some of them have wider reach than than they could imagine.
There's new careers that that exist because of that. Yeah. I love the analogy.
And the most exciting thing for me is it's just so
impossible to say today what will happen after this happens, and after this transition happens.
Just, you know, the economy as we know it would not have existed without it. So what's next?
Like, what is the thing that we can't even predict today that will exist because anyone can do this?
Well, we cannot predict, but I think we can look at what is working right now. If you look around in your environment, may that be the team across Entropic, who are software engineers or or builders or members of technical staff, however we call them, who to you are stand out?
What are they doing? What skills have they built up, and and how have they changed the way they they work? It's hard to name individuals because, honestly, this is just the strongest
these are the strongest people I've ever worked with in my career. There's all sorts of different archetypes. There are some people that are really amazing prototypers.
So take something from zero to point five. Just, you know, figure out, like, what are some cool ideas? What is the technology unlock?
There's other people that are amazing at finding product market fit. So kind of point five to one, or maybe zero to one. There's other people that span different disciplines, and I I'm just seeing more and more of these people.
Like I said, like, people that span product engineering and infrastructure engineering, or, you know, product and design, or design and engineering. I I think I'm just seeing a lot more of these of these hybrids.
What's belief that changed from last year to this year? Something that, you know, like you either believed
or or a conviction that you have that you've either revised or completely threw away? Think one thing I wasn't sure about is how big a problem is safety, to be totally honest. I joined Anthropic because, like I said, I read a lot of sci fi and I know how bad this thing can go if it goes bad.
It wasn't something I was sure about.
Seeing it from the inside and then seeing how the new risks that have arisen in the last year, it just makes me much much more worried about it. So I think it was kind of an important thing for me, now it's just the most important thing for me, is how do we make sure this thing goes well?
I think it's safe to say. You you were a really great software engineer even before
all the AI things started. And you seem to be a very productive engineer, of course, part of a team as well, but but also individually. What are some skills of, like, you know, before being a software engineer that are are still as valuable or maybe even more valuable than before, and what are ones that are maybe just not as much and and they're best left behind?
Probably okay. So stuff that's left behind is
best left behind is maybe, like, very strong opinions about, like, code style and languages and things like this. Like, I I can't wait to get past, like, these endless language debates and framework debates and all this stuff.
Because the model can just use whatever language and framework, and if you don't like it, it can just rewrite it for you. So it just doesn't matter anymore. I think something that still matters a lot today is being methodical and hypothesis driven.
This matters both in product design in this world where everything is being disrupted, and we need to figure out what to build next, and this is something everyone is thinking about.
But it also matters for engineering day to day, you know, something like debugging. You just have to be very methodical about it. And the model can do this and it can help a lot.
But I think still we're in this transition point where you still need to have this skill. I don't know if you're still gonna need to have it in six months. Other skills that I think are more valuable are being curious and being open to doing things beyond your swim lane.
So if you're working on engineering but you really understand the business side, you can just build really awesome products. And think the next billion dollar product, after QuadCode, whatever the next startup is that becomes the next trillion dollar startup, it might just be one person that has some cool idea, and their brain just is able to think across engineering and product and business, or design and finance and something else.
People are gonna become more and more multi disciplined, and this will become more and more rewarded. So in in some ways, I think this will be the year of the generalist. I think the other skill that's actually been been rewarded of it is having a short attention span.
I was being rewarded now. Oh, yeah.
You know, like, teenagers are using TikTok and all this stuff.
I think in some ways it's kinda dangerous for society because you want people that can think deeply and can contemplate ideas aren't and just moving on to the next idea very quick.
But in some ways, I think this year is of the year that is gonna reward it's like the year of ADHD. Because the work for me has become jumping between quads, it's become managing quads.
And so it's not so much about deep work, it's about how good am I about context switching and, you know, jumping across multiple different contexts very quickly. Could I add that from what
all of you said, maybe we could add one thing, is adaptability, because you're saying, of course, that ADHD and and you can jump across, but, of course, earlier, you were very good at focusing deeply on one thing as well.
And what strikes me about you, and maybe this is true for other people as well, you're you're just kinda very open to adapting your working style and seeing what works well for this stage, especially when things are changing. I think the one certain thing we can be sure is whenever the next model comes out, it'll change again, and you need to be curious and open to adapting how you work.
Right? Yeah. And as closing, what's a book or books that you would recommend?
I've gone down a Sichin Liu rabbit hole.
So he's the three body problem guy, but he actually has a lot of other really great books. I really love his short stories. He has a couple books of short stories.
I'm a big fan. For people that are new to sci fi and you want a little bit harder sci fi, I really love Accelerando by Strauss.
This is a book I would totally recommend. It's essentially the product roadmap for the next fifty years. It it it starts with takeoff kinda starting to happen and kinda AI singularity, and then it ends up with, like, this kind of like group lobster consciousnesses orbiting Jupiter, and it's just like amazing.
And the thing that I think it really captures is just the pace, this quickening quickening quickening pace of how this feels. It really matches the feeling right now. And then on the technical side, I would strongly recommend functional programming in Scala.
Even if language choice just doesn't matter as much anymore, I think there is this art to functional programming that just teaches you how to code better, and it'll just teach you how to think in types.
If you read this book, I think what's really important is to do the exercises also, and I've gone through, and I've done all of them probably like three times over. And it's just amazing. It it it really just like knocks this idea of functional types into your head, and it's just a thing you can't stop thinking about.
Boris, thank you so much. This was awesome. Yeah.
Thanks, Grigey.
This was a really interesting conversation and the thing that I keep coming back to is to Boris' printing press analogy. The idea that medieval scribes were this tiny elite who could write employed by kings who themselves were often illiterate and that we soft rangers might be in a similar position today.
We are the scribes. We spent years mastering this craft and now the printing press is arriving. But what Boris told me is that the scribes did not disappear.
They became writers and authors and the entire market for written work expanded beyond anything anyone could have predicted. I do find this hopeful and also appreciate that Boris didn't sugarcoat it. The other thing that struck with me is just how differently the plot code team built software.
No PRDs, no mandatory ticketing system, designers and data scientists and finance people all writing code and building dozens or hundreds of prototypes before shipping a feature. And Boris is shipping 20 to 30 port requests a day without editing a single line by hand.
And there are different verification systems in place. Clock code reviewing gets code, automated lint rules, best of end passes, and human code review. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube.
A special thank you if you also leave a rating on the show. Thanks and see you on the next one.
The Hook
The bait, then the rug-pull.
When Boris Cherny joined Anthropic, he wrote his first pull request by hand. His ramp-up buddy rejected it -- not because the code was wrong, but because there was already a tool that could write it for him. That moment, and everything that followed, is the subject of this conversation.
How they asked for the click.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
- . Sonar - The makers of SonarQube, the industry standard for automated code review. ↗
- . WorkOS - Everything you need to make your app enterprise ready. ↗
- . How Claude Code is built ↗
- . How Anthropic built Artifacts ↗
- . How Codex is built ↗
- . Real-world engineering challenges: building Cursor ↗
- . X ↗
- . LinkedIn ↗
- . Website ↗
- See the transcript and other references from the episode at ↗
- Production and marketing by ↗
