- Two people from the Claude Code team reflect on the year since launch, when reactions were muted, to today where they run trees of thousands of agents — and the most important habit is: when Claude makes a mistake, write it to CLAUDE.md or make a skill rather than just re-prompting.
- They dig into verification (whether the agent can actually run the thing, not just unit tests), auto mode replacing plan mode, routines that auto-fix bugs and review PRs, and the heavy red-teaming behind shipping auto mode safely.
- Broader themes: roles are merging (designers, PMs, finance, data science all code), companies that win put Claude at the center of every process (like the PC transition but faster), and context engineering now means minimalism — give the model the least it needs and let it figure out the rest.
Reflecting on a year of Claude Code
- The single most important idea: every time Claude makes a mistake, don't tell it to do it differently — have it write the fix to CLAUDE.md or make a skill, so Claude can run forever and keep improving.
- Verification is widely misunderstood: people think unit tests, lint, or type-checks (already automated), but for agents it means "can the agent run the thing?" — e.g. Claude spinning up a local app and using computer use to click around and test new UX and edge cases.
- Auto mode has replaced plan mode for synchronous work because newer models (4.6/4.7) don't need a planning step; auto mode routes permission checks to another model that denies anything unsafe, and is actually safer than glazing over every permission prompt.
- Shipping auto mode safely required collecting thousands of agent-trajectory transcripts, having auto mode classify safety, then red-teaming with internal and external attackers to build evals and ensure prompt-injection and hacking attempts were denied — protecting against the most intelligent attacks they can construct.
- Routines are a breakthrough application of the Agent SDK: a routine listens for tickets, GitHub issues, or bug reports, proactively puts up a fix, and pings the PR — sometimes another person's Claude has already fixed your bug.
- Roles are merging — product, devrel, design teams all write code; engineers ship products end-to-end (working with legal, marketing, security); AI especially benefits curious people with product taste who want end-to-end ownership.
- Putting Claude at the center: like the 1990s shift to PCs (you had to throw out the filing cabinet and route everything through the computer), winning companies put Claude at the center of every process — and because work is already digitized, this transition is far faster than the 10-15 years computers took.
- Context engineering has shifted with the models: from prompt engineering (Sonnet 3.5) to context engineering (Opus 4) to today's minimalism — give the minimal system prompt and tools and let the model figure out the rest; a leaner harness leaves more room for your own prompts. Workflows are also moving from many terminal tabs to the new agent view, the desktop app, and even coding from a phone via remote control.
CLAUDE.md — A file where you record corrections and instructions so Claude doesn't repeat mistakes and can run autonomously.
Skill — A reusable capability you teach Claude (e.g. a desktop-development skill) that encodes how to do a recurring task.
Verification — For agents, whether the agent can actually run and test the thing it built, not just pass unit tests or lint.
Auto mode — A mode that routes permission checks to another model for a safety decision, replacing manual approval and the older plan mode.
Plan mode — An earlier Claude Code mode that produced a planning step before execution; now largely unneeded with newer models.
Routine — An automated, always-on use of Claude (built on the Agent SDK) that listens for events and proactively puts up fixes or reviews.
Red teaming — Adversarial testing where attackers try to prompt-inject or hack the system to find and close vulnerabilities.
Context engineering — Deciding what context to give the model; the current best practice is minimalism — the least the model needs.
Loop — A Claude product the speakers use, representing the leap from talking to an agent to having a routine/loop prompt Claude for you.
Remote control — Controlling agents running on your computer from your phone, enabling coding away from your desk.
When we first released Claude Code, it was like a little video and I remember posting it to Slack, and there was like two people that gave the reactions, and people were like excited. I thought it was really cool, especially for my very easy engineering tasks. It was quite good at it. That's a really nice way to say that it wasn't really good. I can't believe it's only been a year since we first launched Claude Code. It's hard to remember what that was like. It's so different than what we're doing today. Now I just have armies of agents that are doing stuff. I'm prompting one agent, or I have an agent that's prompting agents, that's prompting agents. And it's like a tree of thousands of agents.
But I think the most important idea when working on this stuff is, every single time Claude makes a mistake, I don't tell Claude to do it differently, I tell it to write it to the CLAUDE.md, or to make a skill, or something, to do it differently. And if you can do this, then Claude can just run forever. And the other thing that we kind of realized is the verification is really important. We didn't realize that. I hear this come up a lot with developers and enterprises that we meet with.
What are your tips for making Claude Code really good at verification? I sort of feel like this is this thing that everyone misunderstands, because whenever we talk about verification, people are thinking unit tests, or they're thinking lint or type check. These are the things that are obviously really easy to automate. And these are the things that were already automated. But actually when we talk about verification for agents, it's something slightly different. It's like, can the agent run the thing? It takes a little bit of mental work to figure out how exactly do you do this, because it's often not straightforward. And that's one of the challenges.
I remember with Opus 4, Claude tested itself. We just hooked it up to Opus 4 and I was like, Claude, build the feature and then test yourself in bash. And it opened a little Claude CLI and tested its own feature. And I was just like, whoa, it's crazy! Now we're so used to it. Now we have these loops going for the iOS simulator and the Android simulator and computers for desktop. It's not surprising. But back then that was crazy.
How are you doing it? So I've been mainly hacking on the desktop app these days. And one of the engineers on the team actually added this desktop-development skill that teaches Claude how to run the local desktop app. And I've been having it use it, and it still runs into issues or bugs with the staging environment sometimes. And so what I have it do is in those cases, I have it read Slack and understand, hey, is staging down right now? Or has someone else already hit this? And then when it debugs the whole issue, I tell it to update the desktop-development skill. What the skill does is Claude actually spins up a local desktop app, and it uses computer use to click around on it. And so when I add a new UX, it clicks around to invoke the new UX. It also tests edge cases, and when there's an issue it fixes it and re-checks.
This is honestly one of my favorite things about this team is everyone codes. I've never been on a team where my PM would code and it's like crazy and your code is really good. You're too nice. But I also feel like it's becoming easier because essentially Claude writes the code. And so what matters a little more is what's the idea that you have. And I feel like if you're a person that has the product context and the business context and you're thinking about the design and the user, you're just going to come up with better ideas. It's kind of like all the roles are merging. I remember seeing Megan, our designer's, PRs and I was horrified at the beginning. I was like, oh my God, why is Megan putting up PRs? And then she was like, yeah, I'm just fixing the button. And I was like, okay, all right, well, the code looks good, so maybe it's fine. And now it's just totally normal.
And we see this across all the enterprises we talk with. The engineers adopt Claude Code first and then the eng-adjacent roles look over their shoulder and they're like, whoa, this thing is very powerful. Let me try it out. And we found that our designers are more productive making prototypes and making changes directly in the app instead of pinging an engineer, PMs are making changes in the app. Our finance team runs in Claude Code, they do their projections there. Data science — if you talk with our data scientists, it's so cool. Everyone just has Claude Codes up on their screens. It's remarkably versatile for different roles.
What do you feel like nowadays are the use cases that are pushing the limit? One that I'm super excited about is routines. There is one engineer on our team who launched voice mode across all of our products. And he has his routine set up that just listens for every ticket that comes, every GitHub issue, every bug report about voice mode. And his Claude just picks it up, proactively puts up a fix, and then pings the PR to him. And when he got that working for voice, he thought, okay, we're getting a lot of other feedback that isn't being responded to. So he also set up a routine to listen for that. So I shipped this small feature. And there was an edge case in it that I didn't see. And so someone filed a bug for it, and I was going to get to the bug that night. And my Claude was working, it said, wait a second, another Claude has already fixed this. And I was like, how is this possible? I've never talked to him about this feature before. And so I pinged him, and I was like, how did you fix this so quickly? And he said he has another routine that just looks for bug reports that haven't been responded to in five hours and puts up a fix, and he merges the ones that are easy to verify. Claude tells me this all the time now, that someone else has already fixed it. There's always another person's Claude that's working on it.
I feel like a while ago we were trying to figure out how to use routines, and the Agent SDK was this first idea that we could use Claude Code programmatically. But at the beginning, it just wasn't obvious how do we use it, what do we use it for. And I think routines are the first really obvious application. It just does all the code review, it babysits every PR. You remember back in the day you used to actually have to respond to code review comments. You used to have to fix CI. You used to have to rebase. I haven't done that in a long time.
When you're in the CLI and you're synchronously working with Claude, what are your go-to features? What they used to be is plan mode. I don't use that anymore. What do you use instead? Auto mode. Auto mode? It's the best. Instead of plan mode? Instead of plan mode. Because the newer models they don't actually need a planning step anymore. I think this was really important for Opus 4 through maybe 4.5. Then starting with 4.6 and definitely with 4.7, it just doesn't need that planning step. I think some people still use it. They like to have that artifact. I don't use it, and I just do auto mode for everything because then I start my Claude, it starts to work and then I just move on to the next Claude and I don't have to sit there and watch it.
From the very early stage we had this permission-prompts model for Claude Code, right? It runs a tool and then it asks you, hey, are you okay running this tool? And you had to say yes or no. And at the time, that was kind of the best we had a year and a half ago, because we didn't have classifiers. The model was not as well aligned as it is today. So auto mode was such a big step up because actually you don't want to read most of these requests. Just routing it to a different model and having it check for security works so much better. And if a thing is a little suss, or this isn't the command that you think you want to run, or it's not safe, the model will just deny it. And then you can go back and you can allow it later. This has been one of those step changes. There's no way we could have done this a year and a half ago. It's just human nature, when you accept 99% of requests, that your eyes just glaze over when you read it. And so actually, we feel that auto mode is more safe than reading every single permission prompt, because it means that you're only paying attention to the most important thing and not being spammed a bunch of things that are just 99% yes.
I think security is one of these things. You can talk about it and then it's a totally different thing to actually do it correctly, because it just doesn't always look the way that you think it's going to look. And it's all about always red teaming, always pentesting, always looking, always having a threat model and then using that to figure out how is this thing going to get attacked, how are people going to get prompt injected. And the team is just obsessed with this. And it's so important because as a result, I just trust the agent to run and I can move on and I can have a second agent. And if I didn't trust it, then I wouldn't have been able to do that. And internally, to actually get auto mode out to our users, we needed to really trust it first. And so what we did was we collected thousands of transcripts of an entire agent trajectory and a permission prompt and had auto mode classify whether or not it was safe. And it was extremely good at this. So then we got red teamers, and we asked them to try to prompt inject, and try to hack the code base. And we used this to create evals and make sure that all of these were denied. And then we had our own internal teams try to prompt inject and hack Claude Code's auto mode. And then we improved auto mode to make sure that we caught all of these. So it's not only just protecting you against the vulnerabilities that are out there in the wild today, but the most intelligent attacks that we can construct.
It's honestly a weird approach. I feel like there's all these features the last year where the first time someone pitched it, I was like, no way, that's not going to work. And over time I just learned, like, I'm actually wrong, like so often now. Because building on the model is so weird. It's all this engineering stuff that I've learned over the years, so much of it I just have to throw out. And this is just part of what the job is now. We're building on a new thing and we just have to relearn it. And auto mode was definitely one of these. The first time I heard it, I was like, route the prompt for a model? No way. That's not going to work. And then it actually turns out empirically, it works really well.
But I heard you also love loop. Yeah, I love loop. How do you use it? For loop, there's this transition that we went through a year and a half ago where we were like, all right, there's source code. But actually the thing an engineer should interact with, maybe it's not the source code, maybe it's the agent. And so we made this leap of, I don't write the source code, I talk to an agent, and the agent writes the source code for me. And right now what's happening is we're making the next leap. I don't talk to an agent anymore. I talk to loop or I talk to a routine and it prompts Claude for me. It's a year and a half and this was like two big leaps.
If you take a step back, how are you seeing entire engineering orgs change? I'm going to put on my business hat. I have this favorite case study. This is a Harvard Business Review from the 90s. And they were talking about, computers are here, why are we not seeing the productivity benefits? And it's this amazing snapshot into what it actually felt like at the time, because people used to use mainframes. At some point companies switch to personal computers. It was a new thing, and the companies were trying to figure out how to use it. The same way they're trying to figure out how to use AI right now. And it turned out that to get the productivity benefits from computers, what you had to do isn't like you have your paper filing cabinet and your paper and pen business process, and then there's a computer on the side that does something. Actually, what you have to do is you throw out the filing cabinet, you throw out all your paper and all your pens, and then you put a computer in the center and everything has to run through the computer. It has to be at the center of every business process. And I feel like at Anthropic we do this thing where when you onboard, you don't ask people questions — no one asks me questions when they onboard. They ask Claude. And this is kind of weird, this is the first company I've been at like that. And for us, Claude is just at the center of everything. Whenever I have a question, I ask Claude. Whenever I write code, I use Claude. Whenever I need a code review, Claude does it, whenever I need a security review, Claude does it, whenever I need to fill out a form, Co-work does it. So Claude is at the center of everything. And the companies that are really figuring it out, there's a bunch of them now, they're just putting Claude at the center of it. And for computers, the transition took 10 to 15 years. But actually for AI, because so much of our work is already digitized and Claude can use a computer and it can write code and run code, this transition is happening a lot faster.
I feel like now I don't have to bug people anymore, and when I interact with people, it's because it's fun and I get to collaborate with them on stuff and we get to create something together. It's not that I need something from them, because Claude can actually do a lot of that stuff now. And I also feel like as an engineer, I've just never had this much fun doing engineering, because the tedious part I don't have to do. I'm just coming up with ideas, I'm talking to customers, and every idea — I don't have a to-do list anymore. Claude just builds everything. And so my job is to come up with these ideas and it's just so fun.
Okay, so here's a question. Is the future product or engineering? Is everyone going to be a PM or is everyone going to be an engineer? Everyone's going to be both. I feel pretty strongly that these roles are merging. When we look at our team, our product team all writes code. Our devrel team all writes code. Our design team all writes code. And then we look at our engineers and a lot of them ship products end to end. They have an idea for what to build. They build it. They work with legal and marketing to figure out how we communicate this to the world and make sure it's safe and with security too. And a lot of times they just see through this whole process end to end. So I think right now AI really benefits people who have a lot of curiosity, have a lot of product taste, who love to have this end-to-end ownership.
And now a lot of people are running hundreds of agents. What are the products that you think people should be adopting as they transition from single to multiple to hundreds? Until recently, the way that I wrote code was I had six terminal tabs with six git checkouts on the same repo, and then I would just tab between them. Now it's pretty different. I have one tab, I use the new agent view that we just shipped. It's so good. And I'm so glad that we took a while to iterate on it to make that really good. And I also use the desktop app because I don't have to fiddle with checkouts that way. It does the work-tree cloning, it creates the work trees for me. And the thing that I would not have expected six months ago is probably half my engineering now I do on my phone. So I have so many agents running that I just start from my phone. I use a remote control, which is amazing now, and I will start something on my computer. And then I'll just remote control in from my phone and I'll just walk around, I'll get coffee, and then I'll check in on my agents and maybe I'll start another agent. And sometimes I'm talking to someone and we come up with a new idea. I'll just start an agent on the spot. I talk to it with voice mode and just have it build something, and I don't even have to go back to my computer anymore.
I remember when you started doing this because you would actually leave work, have your computer on your desk open, plugged in, screen locked, and I just thought you would come back to the office at some point to get your computer, but then it would be pretty late and I was like, maybe he just left it here by accident. And then it happened again the next day. And then it happened again the next day. And I was like, wait, it's so weird because you're landing PRs but your computer is right next to me. And I remember you responding, and you're like, yeah, I'm coding from my couch. Yeah, that was the week the remote control got really good. So another thing that users are asking about all the time is how do you do context engineering, especially in a large enterprise? This is a thing. People used to talk about prompt engineering. They used to work on context engineering. This is sort of matching where the model was at the time. Back in the days of Sonnet 3.5, you had to prompt engineer. Back in the days of Opus 4, you had to context engineer. But with the models of today, you don't do any of this. You give it the minimal possible system prompt, the minimal possible tools, and then you let the model figure it out. You just have to give the model some way to pull in the context. I think that's the most important thing.
How do you think about it? I see things very similarly. I'm a context minimalist, so my general philosophy is tell the model only what it needs to know and let it figure out the rest of it. When you give the model too much context, it's kind of like you're micromanaging it. And sometimes the model knows a better way to get to the same outcome. And I personally prefer to give the model that freedom to do that. And then in general, we're also making our harness more lean so that you have more room for your own prompts. And so that follows your prompts better.
There's all these different ways to Claude now, but I feel like in a year it's going to be a totally new set of things, and it's going to be so surprising if it's still these same things, because I think we're seeing these giant trends happening right now. Agents are running for longer. They're more autonomous. Very rarely am I running one agent at a time. It's usually a few agents or dozens or hundreds or thousands. And so the form factor for that, it's going to be really different than what came before. And I don't know what it's going to be. And in large part, it's going to be up to the team to figure it out. And this is why I'm so happy we run the team the way that we do, where everyone just comes up with ideas and everyone is able to think about the product. Everyone talks to users all the time, because I don't think these ideas are going to come from us. It's going to come from the team. Totally, and from everyone in our community building with us.
TL;DR
- Two people from the Claude Code team reflect on the year since launch, when reactions were muted, to today where they run trees of thousands of agents — and the most important habit is: when Claude makes a mistake, write it to CLAUDE.md or make a skill rather than just re-prompting.
- They dig into verification (whether the agent can actually run the thing, not just unit tests), auto mode replacing plan mode, routines that auto-fix bugs and review PRs, and the heavy red-teaming behind shipping auto mode safely.
- Broader themes: roles are merging (designers, PMs, finance, data science all code), companies that win put Claude at the center of every process (like the PC transition but faster), and context engineering now means minimalism — give the model the least it needs and let it figure out the rest.
Takeaways
- The single most important idea: every time Claude makes a mistake, don't tell it to do it differently — have it write the fix to CLAUDE.md or make a skill, so Claude can run forever and keep improving.
- Verification is widely misunderstood: people think unit tests, lint, or type-checks (already automated), but for agents it means "can the agent run the thing?" — e.g. Claude spinning up a local app and using computer use to click around and test new UX and edge cases.
- Auto mode has replaced plan mode for synchronous work because newer models (4.6/4.7) don't need a planning step; auto mode routes permission checks to another model that denies anything unsafe, and is actually safer than glazing over every permission prompt.
- Shipping auto mode safely required collecting thousands of agent-trajectory transcripts, having auto mode classify safety, then red-teaming with internal and external attackers to build evals and ensure prompt-injection and hacking attempts were denied — protecting against the most intelligent attacks they can construct.
- Routines are a breakthrough application of the Agent SDK: a routine listens for tickets, GitHub issues, or bug reports, proactively puts up a fix, and pings the PR — sometimes another person's Claude has already fixed your bug.
- Roles are merging — product, devrel, design teams all write code; engineers ship products end-to-end (working with legal, marketing, security); AI especially benefits curious people with product taste who want end-to-end ownership.
- Putting Claude at the center: like the 1990s shift to PCs (you had to throw out the filing cabinet and route everything through the computer), winning companies put Claude at the center of every process — and because work is already digitized, this transition is far faster than the 10-15 years computers took.
- Context engineering has shifted with the models: from prompt engineering (Sonnet 3.5) to context engineering (Opus 4) to today's minimalism — give the minimal system prompt and tools and let the model figure out the rest; a leaner harness leaves more room for your own prompts. Workflows are also moving from many terminal tabs to the new agent view, the desktop app, and even coding from a phone via remote control.
Vocabulary
CLAUDE.md — A file where you record corrections and instructions so Claude doesn't repeat mistakes and can run autonomously.
Skill — A reusable capability you teach Claude (e.g. a desktop-development skill) that encodes how to do a recurring task.
Verification — For agents, whether the agent can actually run and test the thing it built, not just pass unit tests or lint.
Auto mode — A mode that routes permission checks to another model for a safety decision, replacing manual approval and the older plan mode.
Plan mode — An earlier Claude Code mode that produced a planning step before execution; now largely unneeded with newer models.
Routine — An automated, always-on use of Claude (built on the Agent SDK) that listens for events and proactively puts up fixes or reviews.
Red teaming — Adversarial testing where attackers try to prompt-inject or hack the system to find and close vulnerabilities.
Context engineering — Deciding what context to give the model; the current best practice is minimalism — the least the model needs.
Loop — A Claude product the speakers use, representing the leap from talking to an agent to having a routine/loop prompt Claude for you.
Remote control — Controlling agents running on your computer from your phone, enabling coding away from your desk.
Transcript
When we first released Claude Code, it was like a little video and I remember posting it to Slack, and there was like two people that gave the reactions, and people were like excited. I thought it was really cool, especially for my very easy engineering tasks. It was quite good at it. That's a really nice way to say that it wasn't really good. I can't believe it's only been a year since we first launched Claude Code. It's hard to remember what that was like. It's so different than what we're doing today. Now I just have armies of agents that are doing stuff. I'm prompting one agent, or I have an agent that's prompting agents, that's prompting agents. And it's like a tree of thousands of agents.
But I think the most important idea when working on this stuff is, every single time Claude makes a mistake, I don't tell Claude to do it differently, I tell it to write it to the CLAUDE.md, or to make a skill, or something, to do it differently. And if you can do this, then Claude can just run forever. And the other thing that we kind of realized is the verification is really important. We didn't realize that. I hear this come up a lot with developers and enterprises that we meet with.
What are your tips for making Claude Code really good at verification? I sort of feel like this is this thing that everyone misunderstands, because whenever we talk about verification, people are thinking unit tests, or they're thinking lint or type check. These are the things that are obviously really easy to automate. And these are the things that were already automated. But actually when we talk about verification for agents, it's something slightly different. It's like, can the agent run the thing? It takes a little bit of mental work to figure out how exactly do you do this, because it's often not straightforward. And that's one of the challenges.
I remember with Opus 4, Claude tested itself. We just hooked it up to Opus 4 and I was like, Claude, build the feature and then test yourself in bash. And it opened a little Claude CLI and tested its own feature. And I was just like, whoa, it's crazy! Now we're so used to it. Now we have these loops going for the iOS simulator and the Android simulator and computers for desktop. It's not surprising. But back then that was crazy.
How are you doing it? So I've been mainly hacking on the desktop app these days. And one of the engineers on the team actually added this desktop-development skill that teaches Claude how to run the local desktop app. And I've been having it use it, and it still runs into issues or bugs with the staging environment sometimes. And so what I have it do is in those cases, I have it read Slack and understand, hey, is staging down right now? Or has someone else already hit this? And then when it debugs the whole issue, I tell it to update the desktop-development skill. What the skill does is Claude actually spins up a local desktop app, and it uses computer use to click around on it. And so when I add a new UX, it clicks around to invoke the new UX. It also tests edge cases, and when there's an issue it fixes it and re-checks.
This is honestly one of my favorite things about this team is everyone codes. I've never been on a team where my PM would code and it's like crazy and your code is really good. You're too nice. But I also feel like it's becoming easier because essentially Claude writes the code. And so what matters a little more is what's the idea that you have. And I feel like if you're a person that has the product context and the business context and you're thinking about the design and the user, you're just going to come up with better ideas. It's kind of like all the roles are merging. I remember seeing Megan, our designer's, PRs and I was horrified at the beginning. I was like, oh my God, why is Megan putting up PRs? And then she was like, yeah, I'm just fixing the button. And I was like, okay, all right, well, the code looks good, so maybe it's fine. And now it's just totally normal.
And we see this across all the enterprises we talk with. The engineers adopt Claude Code first and then the eng-adjacent roles look over their shoulder and they're like, whoa, this thing is very powerful. Let me try it out. And we found that our designers are more productive making prototypes and making changes directly in the app instead of pinging an engineer, PMs are making changes in the app. Our finance team runs in Claude Code, they do their projections there. Data science — if you talk with our data scientists, it's so cool. Everyone just has Claude Codes up on their screens. It's remarkably versatile for different roles.
What do you feel like nowadays are the use cases that are pushing the limit? One that I'm super excited about is routines. There is one engineer on our team who launched voice mode across all of our products. And he has his routine set up that just listens for every ticket that comes, every GitHub issue, every bug report about voice mode. And his Claude just picks it up, proactively puts up a fix, and then pings the PR to him. And when he got that working for voice, he thought, okay, we're getting a lot of other feedback that isn't being responded to. So he also set up a routine to listen for that. So I shipped this small feature. And there was an edge case in it that I didn't see. And so someone filed a bug for it, and I was going to get to the bug that night. And my Claude was working, it said, wait a second, another Claude has already fixed this. And I was like, how is this possible? I've never talked to him about this feature before. And so I pinged him, and I was like, how did you fix this so quickly? And he said he has another routine that just looks for bug reports that haven't been responded to in five hours and puts up a fix, and he merges the ones that are easy to verify. Claude tells me this all the time now, that someone else has already fixed it. There's always another person's Claude that's working on it.
I feel like a while ago we were trying to figure out how to use routines, and the Agent SDK was this first idea that we could use Claude Code programmatically. But at the beginning, it just wasn't obvious how do we use it, what do we use it for. And I think routines are the first really obvious application. It just does all the code review, it babysits every PR. You remember back in the day you used to actually have to respond to code review comments. You used to have to fix CI. You used to have to rebase. I haven't done that in a long time.
When you're in the CLI and you're synchronously working with Claude, what are your go-to features? What they used to be is plan mode. I don't use that anymore. What do you use instead? Auto mode. Auto mode? It's the best. Instead of plan mode? Instead of plan mode. Because the newer models they don't actually need a planning step anymore. I think this was really important for Opus 4 through maybe 4.5. Then starting with 4.6 and definitely with 4.7, it just doesn't need that planning step. I think some people still use it. They like to have that artifact. I don't use it, and I just do auto mode for everything because then I start my Claude, it starts to work and then I just move on to the next Claude and I don't have to sit there and watch it.
From the very early stage we had this permission-prompts model for Claude Code, right? It runs a tool and then it asks you, hey, are you okay running this tool? And you had to say yes or no. And at the time, that was kind of the best we had a year and a half ago, because we didn't have classifiers. The model was not as well aligned as it is today. So auto mode was such a big step up because actually you don't want to read most of these requests. Just routing it to a different model and having it check for security works so much better. And if a thing is a little suss, or this isn't the command that you think you want to run, or it's not safe, the model will just deny it. And then you can go back and you can allow it later. This has been one of those step changes. There's no way we could have done this a year and a half ago. It's just human nature, when you accept 99% of requests, that your eyes just glaze over when you read it. And so actually, we feel that auto mode is more safe than reading every single permission prompt, because it means that you're only paying attention to the most important thing and not being spammed a bunch of things that are just 99% yes.
I think security is one of these things. You can talk about it and then it's a totally different thing to actually do it correctly, because it just doesn't always look the way that you think it's going to look. And it's all about always red teaming, always pentesting, always looking, always having a threat model and then using that to figure out how is this thing going to get attacked, how are people going to get prompt injected. And the team is just obsessed with this. And it's so important because as a result, I just trust the agent to run and I can move on and I can have a second agent. And if I didn't trust it, then I wouldn't have been able to do that. And internally, to actually get auto mode out to our users, we needed to really trust it first. And so what we did was we collected thousands of transcripts of an entire agent trajectory and a permission prompt and had auto mode classify whether or not it was safe. And it was extremely good at this. So then we got red teamers, and we asked them to try to prompt inject, and try to hack the code base. And we used this to create evals and make sure that all of these were denied. And then we had our own internal teams try to prompt inject and hack Claude Code's auto mode. And then we improved auto mode to make sure that we caught all of these. So it's not only just protecting you against the vulnerabilities that are out there in the wild today, but the most intelligent attacks that we can construct.
It's honestly a weird approach. I feel like there's all these features the last year where the first time someone pitched it, I was like, no way, that's not going to work. And over time I just learned, like, I'm actually wrong, like so often now. Because building on the model is so weird. It's all this engineering stuff that I've learned over the years, so much of it I just have to throw out. And this is just part of what the job is now. We're building on a new thing and we just have to relearn it. And auto mode was definitely one of these. The first time I heard it, I was like, route the prompt for a model? No way. That's not going to work. And then it actually turns out empirically, it works really well.
But I heard you also love loop. Yeah, I love loop. How do you use it? For loop, there's this transition that we went through a year and a half ago where we were like, all right, there's source code. But actually the thing an engineer should interact with, maybe it's not the source code, maybe it's the agent. And so we made this leap of, I don't write the source code, I talk to an agent, and the agent writes the source code for me. And right now what's happening is we're making the next leap. I don't talk to an agent anymore. I talk to loop or I talk to a routine and it prompts Claude for me. It's a year and a half and this was like two big leaps.
If you take a step back, how are you seeing entire engineering orgs change? I'm going to put on my business hat. I have this favorite case study. This is a Harvard Business Review from the 90s. And they were talking about, computers are here, why are we not seeing the productivity benefits? And it's this amazing snapshot into what it actually felt like at the time, because people used to use mainframes. At some point companies switch to personal computers. It was a new thing, and the companies were trying to figure out how to use it. The same way they're trying to figure out how to use AI right now. And it turned out that to get the productivity benefits from computers, what you had to do isn't like you have your paper filing cabinet and your paper and pen business process, and then there's a computer on the side that does something. Actually, what you have to do is you throw out the filing cabinet, you throw out all your paper and all your pens, and then you put a computer in the center and everything has to run through the computer. It has to be at the center of every business process. And I feel like at Anthropic we do this thing where when you onboard, you don't ask people questions — no one asks me questions when they onboard. They ask Claude. And this is kind of weird, this is the first company I've been at like that. And for us, Claude is just at the center of everything. Whenever I have a question, I ask Claude. Whenever I write code, I use Claude. Whenever I need a code review, Claude does it, whenever I need a security review, Claude does it, whenever I need to fill out a form, Co-work does it. So Claude is at the center of everything. And the companies that are really figuring it out, there's a bunch of them now, they're just putting Claude at the center of it. And for computers, the transition took 10 to 15 years. But actually for AI, because so much of our work is already digitized and Claude can use a computer and it can write code and run code, this transition is happening a lot faster.
I feel like now I don't have to bug people anymore, and when I interact with people, it's because it's fun and I get to collaborate with them on stuff and we get to create something together. It's not that I need something from them, because Claude can actually do a lot of that stuff now. And I also feel like as an engineer, I've just never had this much fun doing engineering, because the tedious part I don't have to do. I'm just coming up with ideas, I'm talking to customers, and every idea — I don't have a to-do list anymore. Claude just builds everything. And so my job is to come up with these ideas and it's just so fun.
Okay, so here's a question. Is the future product or engineering? Is everyone going to be a PM or is everyone going to be an engineer? Everyone's going to be both. I feel pretty strongly that these roles are merging. When we look at our team, our product team all writes code. Our devrel team all writes code. Our design team all writes code. And then we look at our engineers and a lot of them ship products end to end. They have an idea for what to build. They build it. They work with legal and marketing to figure out how we communicate this to the world and make sure it's safe and with security too. And a lot of times they just see through this whole process end to end. So I think right now AI really benefits people who have a lot of curiosity, have a lot of product taste, who love to have this end-to-end ownership.
And now a lot of people are running hundreds of agents. What are the products that you think people should be adopting as they transition from single to multiple to hundreds? Until recently, the way that I wrote code was I had six terminal tabs with six git checkouts on the same repo, and then I would just tab between them. Now it's pretty different. I have one tab, I use the new agent view that we just shipped. It's so good. And I'm so glad that we took a while to iterate on it to make that really good. And I also use the desktop app because I don't have to fiddle with checkouts that way. It does the work-tree cloning, it creates the work trees for me. And the thing that I would not have expected six months ago is probably half my engineering now I do on my phone. So I have so many agents running that I just start from my phone. I use a remote control, which is amazing now, and I will start something on my computer. And then I'll just remote control in from my phone and I'll just walk around, I'll get coffee, and then I'll check in on my agents and maybe I'll start another agent. And sometimes I'm talking to someone and we come up with a new idea. I'll just start an agent on the spot. I talk to it with voice mode and just have it build something, and I don't even have to go back to my computer anymore.
I remember when you started doing this because you would actually leave work, have your computer on your desk open, plugged in, screen locked, and I just thought you would come back to the office at some point to get your computer, but then it would be pretty late and I was like, maybe he just left it here by accident. And then it happened again the next day. And then it happened again the next day. And I was like, wait, it's so weird because you're landing PRs but your computer is right next to me. And I remember you responding, and you're like, yeah, I'm coding from my couch. Yeah, that was the week the remote control got really good. So another thing that users are asking about all the time is how do you do context engineering, especially in a large enterprise? This is a thing. People used to talk about prompt engineering. They used to work on context engineering. This is sort of matching where the model was at the time. Back in the days of Sonnet 3.5, you had to prompt engineer. Back in the days of Opus 4, you had to context engineer. But with the models of today, you don't do any of this. You give it the minimal possible system prompt, the minimal possible tools, and then you let the model figure it out. You just have to give the model some way to pull in the context. I think that's the most important thing.
How do you think about it? I see things very similarly. I'm a context minimalist, so my general philosophy is tell the model only what it needs to know and let it figure out the rest of it. When you give the model too much context, it's kind of like you're micromanaging it. And sometimes the model knows a better way to get to the same outcome. And I personally prefer to give the model that freedom to do that. And then in general, we're also making our harness more lean so that you have more room for your own prompts. And so that follows your prompts better.
There's all these different ways to Claude now, but I feel like in a year it's going to be a totally new set of things, and it's going to be so surprising if it's still these same things, because I think we're seeing these giant trends happening right now. Agents are running for longer. They're more autonomous. Very rarely am I running one agent at a time. It's usually a few agents or dozens or hundreds or thousands. And so the form factor for that, it's going to be really different than what came before. And I don't know what it's going to be. And in large part, it's going to be up to the team to figure it out. And this is why I'm so happy we run the team the way that we do, where everyone just comes up with ideas and everyone is able to think about the product. Everyone talks to users all the time, because I don't think these ideas are going to come from us. It's going to come from the team. Totally, and from everyone in our community building with us.