A (2:02)

Not really. We started by building something that's useful for us and I built a thing that first and foremost was just useful for myself and it's something that I found myself using every day. And then I gave it to the team and I saw that the team started using it every day. And pretty soon after we launched it most of Anthropic was a daily active user. And so I think at that point we had kind of a hunch internally that maybe we had a hit on our hands. But it's still not obvious because it's in a terminal. It's kind of a weird form factor. Everyone is coding in IDEs. Are people going to like this? Is it going to be that useful? Can you actually use it for a lot of coding? We had no idea.

B (2:40)

Was it always going to be your product or you started using it and then it was ahead and then you decided to release as a product?

A (2:46)

It was very accidental. When I joined Anthropic, I did a lot of prototyping and one of the prototypes that I built was this thing that it just ran Quad in the terminal just because as an engineer that was the easiest thing to experiment with. And it didn't even code at first. Quad code didn't code. It was called Quad CLI at the time. And what it did was I used it to automate my note taking. So it kind of controlled my notes app and it controlled my music player to kind of play music for me. So I'm like, play this band. And it would go in and kind of automate that. And at first I was just using it to play around with the Anthropic API to figure out what kind of applications I could build on it. And just on a whim, tools came out recently and I tried giving the model BASH tool so it can use my bash to use the command line. And immediately the model just went. It just started coding and it was just the craziest thing. As soon as it had bash, it kind of knew, okay, okay, I can write AppleScript and I can automate stuff and I can use this computer. And it just felt like very native to the model in this way. That was kind of a surprise. So I think that was a surprise. And then it was a surprise that this ended up as something useful where it was able to edit code and the code came out really good and the model could kind of intelligently reason about the way to edit code.

B (4:03)

When was this? If the product was launched at the end of February of 2025, that journey leading to this, did I start a. A few months before that? What was the timeline?

A (4:14)

Yeah, something like that. It was late last year, so late in 2024.

B (4:18)

Okay, great. Let's start from the top end. For anyone that is just starting to learn about cloud code, how do you describe it?

A (4:28)

Cloud code is a agenda coding tool. The way to think about it is when engineers program, there's kind of different ways to program. And this has changed over time. This has changed a lot over time. There is, you know, 50, 70 years ago, the way that people programmed looked very different than the way it does today. So, you know, 70 years ago, if you talk to a programmer, they would have been like, oh, yeah, I take my punch cards and I punch holes in it and I put in this IBM kind of typewriter Y thing and it punches holes and that's programming. And then you feed this into this mainframe, it does some work, and then eventually you get some kind of result out printed on a paper sheet.

B (5:00)

I heard you say somewhere that your grandfather in the guess what was at the time the USSR used punch cards. Tell that story.

A (5:09)

Yeah, yeah, yeah. Growing up, my mom would tell me stories about how her father, my grandfather, he was one of the first programmers in the Soviet Union. And he would come home and he would bring back these big stacks of punch cards. And when she was a little girl, she would take her crayons and just draw all over them. And this was growing up for her. This is actually something that I didn't know until later in life. I was far into my engineering career when I learned this was a thing. There's something about just the visceral nature of this kind of physical programming. I don't think we're going to get that again. But I think that was a special moment where you could feel the language and you can feel the computer in a really different way. And so I think after punch cards, it changed a lot. Software became a thing, and you could start to program directly in software. You didn't have to do this anymore. In the original programming software, it was emulating Teletype. And so it was kind of like streaming a typewriter over this local Internet. And that's how the text editors were built. The way that you would code is still the way that actually most people code today, before agentic coding came out. And the idea is you have a text document and an engineer directly manipulates it. So you load it up in a special piece of software called the ide. It's kind of like Microsoft Word or Google Docs, but just for code. And the engineer just manually edits the code using a keyboard. And this was the case for, gosh, 50 years now. Now, like 70 years, this has been the way that people programmed Ed and Vim. These were early 1970s. So, yeah, it's been like 50 years. And now it's starting to change. For the first time. There's been a lot of work to try to evolve programming from direct text manipulation to something else. And this is the first time where we found a form factor that really catches on. And it took really great LLMs to do this. Models weren't really capable of doing this a year ago, but now they are. The way that it works is a human describes to the model the change that they want and then the model is the one that manipulates the text. And so it's this kind of next layer up where you're describing the change you want and the model does all the work of doing the editing. And we're still at this point today where you can do a lot of this through the model. But for complex changes, maybe it'll take a bunch of iterations, maybe the last 20, 30%. You still have to open an IDE, you have to kind of go lower level to do these last mile changes. And we think that over time, more and more of coding is just going to be the model doing it and a human will have to intervene less and less.

B (7:40)

So just to double click on a couple of the things you just mentioned, and in an effort, as we try often on this podcast, to make things broadly understandable, not just by people who are super deep in tech, but also people that are in the tech world, but sort of like curious to learn about the things. So the cloud code works at the CLI level as opposed to an ide. So you mentioned the ide, sort of the Google Docs, the command line, maybe define that for people. So my kind of mental model as I was learning about this, was like that black box where you sort of type in things for your computer to do. What's a better way of describing it?

A (8:23)

The terminal is a little bit hard to explain if you're not a programmer because it's so low level. It's something that most people will never ever touch and never ever gonna see. It's something like in movies when you see this kind of green screen, green text going across the black screen, and there's like a hacking scene or something.

B (8:41)

When you're trying to look very techy. That's why you.

A (8:43)

Very techy.

B (8:44)

Yeah.

A (8:44)

And it's something every engineer uses. There's nothing kind of good or bad about it. It's just an interface. It's another way to interact with a computer. It's a little lower level because it's not visual. So you can think of quad code. When we say quad code runs in the terminal, you can think of it just. It's a computer program. And some computer programs have user interfaces, so a person can interact with them. And some of them just kind of run in the background. So you can think of quad code as in that second category. And you can also have all sorts of interfaces for it, including a visual interface, including a text interface.

B (9:15)

One way of describing this, I heard, was that interacting with the computer at the terminal level was like texting the computer. So sending instructions, sort of one by one, versus an IDE was more of an application, more like a phone, kind of a gui, where you basically click on icons and you have visual representation. Is that fair?

A (9:37)

Yeah, it's a lot like that. Think text messaging before you could send images and videos and stuff. So just really, really simple interfaces, just back and forth.

B (9:46)

Okay, great. So why did you guys choose to operate at the terminal CLI level?

A (9:53)

Honestly, it was sort of an accident. We were thinking about what can we build in the coding space. It seems like the models are getting a lot better at coding, so maybe there's something that could be built here. And at the time, like I said, I was prototyping some of these ideas. Some of them were kind of coding adjacent. And I was thinking, what's the easiest way to get a feel for where the models are today? Because there was this feeling where the models can do so much, but no one's yet built a product that can harness this capability. And in the AI world, we call this idea product overhang, where the model is just capable of all of these things, and there isn't really yet a product that can kind of capture this and let a person use it. And I remember there was this moment back in. Yeah, it was sometime late last year. The other engineer on the team, Sid and I, were in a room, and we're whiteboarding, and we're like, okay, what do we build? And just in 15 minutes, we kind of throw up a few ideas on the whiteboard. We can do a cli. We can do some sort of IDE extension. We can do something based on the Web. And we kind of closed our eyes and just picked one, and it kind of seemed like CLI is the simplest. And generally, that's the way that I approach product, which is start with a simple thing first. So this kind of made sense in hindsight. There was a lot of benefits of this, too. And I think one of the big ones is that it kind of works anywhere. So it doesn't matter what kind of system you're on. If you're on Mac or Windows, it doesn't matter what IDE you use, it doesn't matter what your preferences are. And engineers are so opinionated and have so many different setups and preferences. It just works with all of them. And that's kind of the benefit of building at such a low level where you're not coupled to particular, you know, to Mac or to Windows or, you know, a color scheme or whatever.

B (11:28)

I think you guys have been pretty clear about the fact that this was a starting point and that you were starting with something very simple, at least when you launched the product. Fast forward to today. Are you finding that the universal aspect of this is so compelling that you may keep it there? Or is the plan, or at least the idea to over time keep building towards something that may be more like an IDE or more an application?

A (11:54)

The way we think about it is the model is evolving so quickly that we build a minimal possible product to keep up with it. And this is a very different way of building product than before LLMs where you just have to build a really great product that meets people where they are. There's some of this. So we have to build in a form factor where people understand and can use it. But actually the bigger motivation is the model is advancing so quickly. There's literally no product we could build that would keep pace with it. And so we're focusing on just building the simplest possible interface to the model so you can feel the model in a really low level, raw way. And so that when the model gets quickly, we can adapt quickly and you can feel the next model in that same kind of way. So today we're in a terminal. Claude code also runs as ID extensions. So there's extensions for VS code based IDEs and cursor and so on. And also for JetBrains based IDs, I can tell OJ and then there's also a GitHub action, so you can mention Claude on GitHub. So it's just you tag quad, add quad and talk to them like you would a co worker and they can make changes for you. There might be more interfaces coming soon. This is something we're always experimenting with, but generally the philosophy is we don't make really gorgeous interfaces like many other companies do and are really great at. We focus on just building the simple thing that shows off the model.

B (13:15)

Talking about the model, if your design principle is that the product should follow the model rather than the other way around, which is super interesting. What model does it currently run on? Is it 3.7? Is that 4? Can people choose?

A (13:30)

Yeah, people can choose the model. We support Sonnet 4 and Opus 4 and then we also use Haiku maybe.

B (13:35)

As a high level question, why is Claude so good at coding use cases? I was again reading somewhere perhaps in the information that Anthropic has a little above 40% of the market for code generation, while OpenAI has 21%. So clearly anthropic is powering its way to win this market. Why is that? Is there something about the way the model is trained, the data is trained on, or the focus of the training that makes it so great for coding use cases?

A (14:12)

I think Anthropic has a lot of really great researchers and coders. And for us, this is kind of a natural way to think about the kinds of abilities the model should have. Because you think about what should the model be able to do. And as a programmer, the first thing you think is, oh, it should be able to do this thing that I'm doing and it should be able to help with me and I can pair with it like I would another engineer. So I think just at all levels and across the company, this is a way that we think about it. There's also something about it where maybe coding is the way that we get to the next level of intelligence. If you call it like AGI or ASI or whatever. The model needs some way to interact with the world. And for a model, the natural way is code. And so from, you know, the mission of the company is to build safe artificial intelligence for everyone and safe asi. The way the model interacts is through code. And so this is the thing that we should start to learn about now. And this is also the reason that one of the reasons that we release cloud code is just to learn how people use it and to learn how to make this thing safe, to learn how it behaves in the wild so that we know what to do next.

B (15:12)

So still on that theme of the product versus the model and the choice of operating at the CLI level, who is a product for? Does the fact that it operates at the terminal level make it a great product for power users who are very deep in coding? Or at the end of the other end of the spectrum, if I don't know anything about coding, can I use the product for Vibe coding?

A (15:36)

Cloud code is for professional software engineers. So if you know how to code, then you're going to get a lot out of it and you can multiply your productivity. We've seen people multiply their productivity many, many times over with a fleet of cloud codes that's running and Even with a single one, you can become a lot more productive. Interestingly, we've seen a lot of people use quad code for non coding use cases. So for example, the data scientists at Anthropic all use quad code to write their queries and designers use it to build small prototypes and product managers use it to manage tasks. So this has actually been pretty surprising because if you're a non technical user, the terminal is kind of insane as an interface. I couldn't imagine why you would want this, but it sort of seems like because it's such a great agent, generally people are jumping over hoops to use it, even though it's not the easiest thing to use because again, it's in a terminal, which is very technical. There's another part of quad code which is the SDK and this is the way that people can build on top of quad code and build their own agentic applications. And this has also been pretty interesting because people are using the quad code SDK to build agent decoding applications and platforms and user interfaces on top of it, but they're also using it for all sorts of tooling Agentic use cases that are totally unrelated to coding. So anything where you need AI, maybe a few years ago you used API and nowadays we find that some users are reaching for an agentic SDK as sort of the thing that you need to build AI apps of today.

B (17:06)

Yeah, and as I was prepping for this, it seems that there is even beyond that, like an emerging category of people that are using cloud code for just not even technical related use cases of any sort. I just saw that tweet from somebody named Alex Finn that talks about using Claude code for note taking for his personal sort of life organization, his business metrics and all the things. So it seems that people are finding ways to use the product for something that matches their needs way beyond their technical job.

A (17:41)

Absolutely.

B (17:42)

Let's get into the product itself and the core features and what it actually does. So a key part of the product is the eugenic aspect, as you described. Agentic. Again, in an effort to go into definitions and make this interesting for everyone. Eugenic is one of those terms that everybody uses, but it's sort of unclear what that actually means. What does agentic mean in the context of cloud code?

A (18:12)

Yeah, when you think about the ways that LLMs work and the way you interact with them, there's the old kind of LLM which is you sent them a message and they send you a message back. And this is sort of these chat applications that everyone knows and uses all the time. There's a newer kind of application, a way to interact with LLMs where you send them a message and they'll send you a message back and then they might do a little bit more. So we call this tool use is one of the things that they might do if you give them tools. So, for example, a tool might be read a file or search something on the Internet or edit a file or something like this. Then they'll use tools to answer your question. And so, for example, if you ask, what's the weather today? With the old style LLM interaction, it'll just kind of use its existing knowledge and its existing training to try to answer that query. But if it's agentic, what it might do is it'll say, okay, I'm going to look up the weather. And then maybe if it has some kind of tool to check the weather, it'll reach out to the Internet or wherever that tool is, it'll use that tool, it'll get the response back and then it'll answer the question. And this tool use, this is kind of the essence of being an agent, because without tools it's very difficult to be agentic. You could kind of do it without. But it's only since models started using tools and gained that new capability because we taught them that they started to get this new agentic capability that we talk about. What this looks like in practice is maybe I'll ask the model, I have a red button on my website, make it blue. And because it has a tool to read a file, it'll choose to read the file. It'll choose to read the file that has that button. Maybe if it doesn't know where that file is, it'll use a file search tool to find that file first. The same way that you might when you're looking for a file. You'll use a file search. It'll then open that file, it'll read it, and that's another kind of file read tool. Then it might edit it. That's a different file edit tool. And then it'll write it back. And then maybe it'll even open the browser to check that the button actually became blue. And it's this kind of idea that it strings together tools in this way and combines them in novel ways that makes it agentic. There's also two concepts that are kind of related, but different. Here you could say you must always, when the user asks you to make the button blue, you must always read the file and then edit the file and then save the file and then check your work. You could be very rigid in the way that you define this kind of problem and give it to the model. Generally we call this a workflow, and this is distinct from something like an agent. Workflow is something where a human thought through for this kind of problem. Here are the steps roughly that you should take. For an agent, it's very different. The model is in charge, it's in the driver's seat, and we give it tools that it can use, and the model decides how to combine those tools to answer your question, and I think going into the future, more and more things will be agentic because the model is getting more and more intelligent. So it can actually use these tools in pretty novel and interesting ways to answer questions.

B (21:13)

Great. So to play it back and perhaps coding context with your typical AI model, I would ask a question and I would get some code back and I as a developer would copy and paste it as a next action. Whereas, you know, coding use cases, you. Whereas in an agentic coding use case, you give the agent a task and then it's going to plan and then it's going to execute, and then it's going to continue running until it believes it's done with the task. Is that a fair summary?

A (21:48)

Exactly. Exactly. And the same way that a person might do it. If you have a problem, you're going to think about it for a bit and you're going to think about what tools you have, and then you're going to combine the tools that you have in ways to do the thing that you want to do.

B (21:59)

What are some of the actions? If taking an action is one of the core part of being an agent, what kind of actions can take Claud.

A (22:10)

Code can do pretty much anything that a person can do on their computer. There isn't really a limitation besides safety. This is something we think about a lot to kind of place intelligent limits on what it can do and put a human in the loop at the right points to make sure that if an action is potentially dangerous or destructive in any way, that a human has to prove it first. But besides that, the model can do pretty much anything. So reading files, writing files, running commands on the system, editing things, you can reach out to the Internet, obviously, most of these, again with human approval, then there's ways to customize it however you want. So if you have a bunch of MCP tools, for example, to read your JIRA issue tracker or to open a browser, or to open an iOS simulator, the model can use these too.

B (22:58)

And how does the MCP part work. So mcp, the model context protocol being something that you guys at Anthropic defined, how does that work? You just leverage the protocol to connect to any tool.

A (23:10)

Yeah, exactly. Quadcode is a MCP client and an MCP server. And what this means is if you give IT tools to use. So maybe at your company you have a bunch of MCP tools that you build for kind of all your systems to integrate with. Like I said, maybe there's one to integrate with Jira. Maybe there's another one to read Slack and maybe write messages to Slack. Maybe there's another one to, you know, fetch some internal knowledge base or something like this. You're going to plug this into a bunch of your tools. You can plug it into Cloud AI, into Cloud Desktop. You can also plug it into QuadCode, so it gets all the same tools that you do.

B (23:41)

So just a few days ago, you guys announced the release of sub agents. What does that do?

A (23:47)

Yeah, subagents are really exciting. And this actually started with a Reddit post. There was someone that posted on Reddit about how they have these subagents that they built for quadcode, and they had a product manager subagent and an engineer and a designer subagent. And a couple engineers on the team saw this and got really excited and felt that this is something that we should support a lot better. And the way subagents works is when you start quad code, you have a quad, and you can talk to the quad and it can do things for you. Subagents are just other quads, and they're prompted a little bit differently. So you can customize what prompts they have, you can customize what tools they have. So, for example, you can say you are really excellent QA engineer or sub agent. Your job is to verify that code is correct and to test code. And to do that, you have these tools at your disposal. Maybe you have like a browser, iOS simulator, Android simulator. You're given code, your job is to test it. You might have another engineer, another sub agent that's maybe a project manager. And their job is to have tasks and then divide up tasks for other subagents. And so you can kind of split up all the work into these different roles. I think we're still figuring out what these roles are. There's one version of the world where the roles are kind of like on a regular engineering team, where you have engineers and designers and product managers and data scientists and so on. There's another world where actually subagents are a little bit more Similar. And maybe every subagent can kind of do the same thing, but they kind of split up the work a little bit more, so everyone is a generalist. And then Claude is in charge of figuring out how to launch the subagents and which particular subagents to use in which way. Exactly the same way that it would use for any other tool. So you can think of it as a really, really intelligent tool where the model can launch more clauds to do things.

B (25:40)

So basically, it's like, if you think of AI as an intern, it's like having a group of interns and every intern has their own role. And then you recombine what everybody did into one result.

A (25:53)

That's exactly right. And you can define what those roles are.

B (25:56)

And it's a fascinating question whether to anthropomorphize human functions into what agents should be doing, or whether there's something that's agent native in the way the work gets distributed and chopped into smaller parts.

A (26:10)

Yeah. In the AI world, we talk a lot about this essay called the Bitter Lesson. This was a Rich Sutton essay from a decade ago or something, where he talks about the more general model. Most of the time, in the long term, it will subsume more specific models. And so what this means is if you build agentic system in this context, then the more general agentic system will generally outperform the more specific one in the long term. And I think where we're at today is models have the capability to do stuff, but if you give them too many tools or too much context or too much responsibility, it might be disappointing because they won't really know how to handle it. And the models of a year ago could barely even call tools. The models of today are pretty good at doing it, but get a little bit overloaded sometimes with context or with too many tools. So we can divide them up into subagents in this way. But I think that the models six or 12 months from now, they probably won't need this anymore because they're all going to be pretty good. And you won't have to define very rigidly what each one's responsibilities are anymore. And so this is something we're building for people today because we think it's quite useful today and it's something that we use a lot. But I could also see this going away at some point.

B (27:20)

Yeah, There's a concept of context pollution. Right. That's one of the way people describe it. Right. And then Claude code can handle both very precise tasks like debugging or much Broader tasks, like a broad refactor, for example, is the idea that the broader the task, the more sub agents you would have in the current context?

A (27:46)

Yeah, that's probably one way to think about it. Generally when we introduce quad code to new people, we actually suggest that like you said, quad code can do everything. And this is one of the things that makes it a little bit hard to use. If you're an engineer that's used to essentially text completions in the ide, it's a very different kind of AI coding experience. And so generally the thing that we recommend is start with something simple like just ask questions about the code base. So don't even code, don't use any tools, just ask the model questions. You know, how, what does this file do? Where is the file that does this thing? If I want to make a new whatever, how do I do that? So just ask it questions like that. And for this, generally the main model can do it and you don't really need subagents. But then as you get a little bit more sophisticated, you might want to start splitting up the work. If you ask the model maybe to make a small change, like I said, make the button red or make the button blue, you probably don't need subagents. But if you do something a little bit fancier like build a new section of the website that does blah, blah, blah, then you might want to have a few subagents. Maybe one is the software architect and it's responsible for planning out the work. Another one is maybe some kind of reviewer where it'll review that plan to make sure it looks good. Then maybe you'll have a few subagents that actually do the implementation. So maybe there's a front end engineer, back end engineer, this kind of thing, and then some kind of verifier at the end that verifies it. And then we also internally we really love using a code simplification subagent. And its job is to take the code that was produced and just simplify it while making it still work.

B (29:16)

Okay, great. So that's the actions part of the AgentIQ workflow. Let's talk about the awareness and memory of this. One of the exciting features is that cloud code can connect with the existing sort of code knowledge in the company. How does that work?

A (29:35)

There's a few different ways to pull in context and this kind of knowledge from the company. The simplest one is just looking at files. There's a few different approaches actually to reading files. So I'll go a little bit into depth, into the way that actually happens in the past, the thing that people used the most is this thing called rag. And essentially this is a technique where you take the whole code base and this actually works for any document set of documents. It's not necessarily code, but you take a set of documents like all the files in the code base, you do this kind of indexing step and then you store essentially this database of all the knowledge that's in these files in a very, very particular form. That makes it really easy for the model to search. There's a lot of trade offs to doing this. The indexing takes time. It's pretty expensive to maintain this database. It's quite tricky practically to make sure that security is really good and privacy is really good because it's very sensitive information like your code base. And so you want to keep it really safe. And so Claud Code actually doesn't use this technique called rag. Instead what it does is it just searches files the same way that a human would. You can think of it like at the engineering level. It uses the tools glob and grep. These are two tools that are kind of built into the computer. And you can think of it as kind of command F for files. So it'll just search around with text the same way that a human can. And what's kind of cool is if you just search for one piece of text, you might get the result you're looking for, but you might not. And depending on the results you get as a human, you would refine your search term and you would try again. And you might try a few times to get the result you're looking for. And the model is really good at this. And again, this is one of those things that was not the case with models of a year ago, but with models of today, they're excellent at this. And so we call this process agentic search. And what this means is using really, really simple search tools like command F and using them repeatedly and then adjusting the search terms over and over based on the result of the query. And this is something that we don't specifically tell the model to do. It's something that it just figures out because it's intelligent enough and it has the search tool. So this is the first form of memory which is just looking at the contents of the code base and understanding it in this way. We augment this a little bit with this thing we call CLAUDE MD files. And all this is, is a special file. It's literally called CLAUDE md. You put it in your code base or you can put it in whatever folder you want and use it to record memories. So at any point you can tell Quad to remember something. So, for example, whenever I edit this file, I always want you to double check it in a browser or something like this. You can tell Quad to remember this and then it'll record it in the right quadmd so that it remembers it next time. And I think one of the most powerful use cases we've seen with this is when people check this into their code base and share it with their team. So this is a. It's a memory file. It's just a regular text file on the computer, but you don't keep it to yourself. You share it with all the other engineers on your team. And what it means is if Claude remembered something when you were using it, everyone on your team gets to benefit from that. It gets this really interesting effect where everyone on the team starts to contribute to this knowledge base and this memory bank. And it's very simple. Again, it's a text file, so anyone can read it also. So it's very easy to edit these memories also and see exactly what's in there. But everyone just starts to benefit. And it feels kind of magical because as your team uses quadco to get smarter and smarter and kind of similar to building in the cli, this is literally the simplest thing we could have done. There's nothing simpler than this, I think, that we could have done to build memory. There's no special tools, there's no special prompting. There's nothing like this. It's just a file and Claude kind of learns to use it.

B (33:26)

Fascinating. And you have to declaratively add to the memory or whether today or in the future, the memory will automatically pull from the context and sort of improve itself.

A (33:39)

Yeah, you have to add to it manually. Today we've actually had a bunch of internal experiments to do. Automatic memory. So Quad can automatically remember things. The problem is there's kind of two ways in which it fails. One is that it remembers things that it shouldn't. So, for example, if I say make the button blue, it might remember. The user always wants the button to be blue. And this is maybe that's the case for this button. That's not the case for every button. And then sometimes it doesn't remember very important things that it should remember. And so for the last few months, we've been doing a lot of experiments to try to get this performance really good. And it's something we've been using internally. And at some point when we're Happy with it. It's something we're going to release for everyone. But generally our bar is if we find ourselves really happy with it and we find ourselves using it every day, then we release it to everyone. And this one's not quite there yet.

B (34:26)

It's another fascinating example or discussion. When you compare a memory like this to human memory and the fact that you can edit it. And then it leads to all sorts of questions around, okay, what is it that we as an organization should remember? And who's in charge of ultimately editing what should be remembered or not? Because this is for code, but code being everything. It's a fascinating concept.

A (34:54)

Yeah. I think this is one of those social problems and maybe not social problems. This is one of those social dynamics that will change over the coming years as people use these tools more and more is we need to figure out what are the roles of people on the team and how do they interact with each other and interact with Quad. And this is maybe one very specific problem within that, who curates Quad's knowledge. And my feeling is that this is something where teams will kind of get more and more horizontal as a result of this, because anyone is able to contribute in this way. But it'll be interesting to see how it plays out.

B (35:30)

And then the key question for agents is always the level of autonomy versus human in the loop. How do you guys think about that? And where do I get pinged as the human coder? In my cloud code workflow, the default.

A (35:48)

Behavior is there's always a human in the loop. This is super important because in the end, this is a model and it's not predictable, and you want to make sure that it doesn't do anything dangerous. So, yeah, there's always a human in the loop. So for actions that we know can't have any kind of dangerous repercussions. So, for example, reading a file, we know this is inherently safe. We just let the model do this in the folder that you let it do this in. But for other actions, like editing a file or running a command or using the Internet, this always needs a human in the loop, and it always needs a human to approve it. There's ways to reduce this burden a little bit. So, for example, if you find yourself always approving edits to the same file or always approving the same command, there's a settings file that you can configure across your team, and you can use this to essentially allow list or block list certain commands or certain files that you always want the model to be able to edit. Without human approval or you never want it to be able to run.

B (36:47)

And while we're on the topic of safety and security, how do you guys think about confidential code, that whole world of regulated industries and sensitive code and that kind of stuff? Do you offer a local version of this, an on prem version of this? Or maybe that's a question for cloud code, but I can throw up. In general, are you all sort of cloud based?

A (37:11)

It's something that actually we've seen work quite well in these very, very regulated industries. And the reason is that it doesn't use any services except the API itself. So that's all it needs. And then everything else you actually don't need. And this is one of the nice side effects of not doing code based indexing or anything like this. It's just very easy to hook up to. So if, let's say you're a bank and at your company you already have Bedrock approved, you can just use Bedrock and use Quad code that way. So you run it on people's laptops and all you need is access to Bedrock, so really easy to get approval for. And then if you want to use the Anthropic API or Vertex, you can use that too.

B (37:48)

How do you think about the UI and UAC experience of this? Or sort of how you balance the power of everything can do versus your stated goal of being as lean and lightweight of an interface on top of the model. So we just talked about how you can approve actions that the agent takes. What about the the rest? Does it basically feel like you'd be using a regular cli or is this something different that one needs to get used to?

A (38:19)

We tried really hard to make Quad code something really beautiful that everyone feels is something that we put a lot of care into, because we did. And I think when you use Quad code, you can feel that this is something that we use every day at this point. Most code at Anthropic is written using Quad code, and almost everyone at Anthropic is using it every day. And when we look at customers that start to use Quad code, they use it kind of more and more and more. And with a product like this, you want it to feel really smooth and really beautiful and something you really enjoy using. And that's been really fun from an engineering and design point of view because we built in a terminal and like I said, terminals have been around for 50 plus years at this point. And it really feels like we're rediscovering how to design for a terminal because since terminals were first Invented the design world, moved to web, and then it moved to apps. And there's kind of different design principles you can take here. And we try to apply these back to Quad code, even though it's running in a terminal. And there's a lot of details that we spent a lot of time on, like the way that we represent statuses for every item with this kind of blinking dot that turns red or green to indicate whether it succeeded or failed. Even the loading indicator, like the spinner, while Quad is working, we spent probably 30 or 40 iterations of this just to get it to feel just right, to make it feel so you know what's happening, but it's not giving you too much information, and it's also not jittering and moving around on you. So, yeah, every part of the interface we iterated on probably more than you think.

B (39:54)

Yes. And then there's this really fun kind of, like, series of words while Claude does its thing where it says like, cooking or herding or schlepping or honking or clotting, which, you know, how many of those words do you have that you seem to have, like, dozens of them. I just find it such, like, a fun kind of like, Easter egg kind of design detail that makes the whole difference.

A (40:23)

You know, at the beginning, I added maybe 20 of them. And then immediately people started making suggesting changes like, hey, how about this word? How about this word? How about this word? So now at this point, there's a pretty big list, and Quad can actually choose the word that best describes the task that it's doing. So it's up to Quad which word it wants.

B (40:40)

How do you charge for using the product? And I'm asking this in the context of, I think over the last few days, there was some evolution. As people became more and more rabid users of the. Of the product, the pricing structure evolved.

A (40:58)

Yeah, this is something that we were honestly really excited to see how some people are just going. They're really figuring out how to run this thing at all hours of the day. It's just, you know, some people have this army of quads, you know, like 5, 10, 20, that are just running in parallel all the time and just doing work. I talked before about how you, Claude, generally needs human approval to do work. There's actually ways to do in a slightly more autonomous way, too. If you want to run it for long periods, essentially, you need to set up a container for it and just give it some kind of, like, a container to be in, and then it can run without approval in a way that is safe. And so there's a lot of people that do this. It's extremely exciting. But also the pricing structure that we had was really not cut out to actually serve these kinds of users. And there's also just a little, we call this kind of abuse where at the tail end, you know, there's like account sharing and things like this, where people are just really not using it in the way that it's intended. So generally for quadco, there's two pricing models today. One is you can get a subscription, there's Pro and then there's Max. And this is, I think it's 20 bucks a month, 100 bucks a month or 200 bucks a month. And it has very, very generous rate limits. If you use only Opus, you'll run out of limits pretty quick and then we'll switch you over to Sonnet. If you use Sonnet, then you can use much more of it than most people need. And almost everyone doesn't run into rate limits at all. It's generally power users run into it. And this is something that we're also thinking through, how to evolve this as we land features where people use more tokens and there's more sub agents and there's more autonomy because we need to figure out a way that we can provide this to people in a way that's sustainable.

B (42:42)

It's an interesting dynamic. Right, because you're a tool for power users, very sophisticated coders that do sophisticated things with it. But equally you want to encourage them, not discourage your power users with pricing.

A (42:56)

Exactly, exactly. Yeah. We want to support the community, we want to hear how people use Quad code in these ways so that we can make sure that we can support that. That's super important to us.

B (43:06)

Great. So it's a price per token or you get like a certain number of tokens for certain pricing tiers.

A (43:12)

Yeah, Essentially within a certain period of time you have a certain number of tokens you can use. And then if you want pretty much unlimited usage without dealing with these limits, you can always just use the API key and this way you can just use it as much as you want.

B (43:25)

So I'd love to spend a little bit of time double clicking on use cases. So we talked about this a little bit and talked about how actually some people at the fringe are using CLAUDE for non coding use cases, but talking about the intended users, who are the coders, what are the main things that you see people do in a context where Claude presumably can do everything?

A (43:49)

Yeah, we see people using it for all sorts of Stuff for all sorts of code related tasks. Everything from planning projects to managing tasks to actually writing code, testing code, debugging. It's excellent at. So if something doesn't work, you can ask Claude to debug it. Writing unit tests, verifying code whenever there's issues in production. Our first line of defense is to give it to Claude. So we have logs coming from GCP or whatever. We give this to Claude and it'll figure out what is the issue that's happening. And it can even interact with git and source control so it can figure out what exactly caused a breakage or what exactly caused a regression. It can automatically fix it. So yeah, it's for every stage of sdlc and I think this is the first tool that really serves every stage in this way. And like I said before, we didn't intend it to be this way. It just happens to be very general and Claude happens to be really good at using these tools. And so this is a, you know, for me this has been kind of accidental product market fit across the entire lifecycle of engineering work.

B (44:54)

Yeah, the kind of accident that every founder or creator of a product dreams of. That happens so rarely. What amazing story. Presumably if you have those MD files and agentic search, cloud code can also be used if you're a new person either at a company or on a project to learn about the code. First of all. Is that right? And two, do you see people do that?

A (45:23)

Absolutely. When I think about the things that quad code is good at, I'll be a little bit self critical. I feel like if you look at answering questions about the code base and kind of code based research, I think it's like 10 out of 10 good. It's, it's as good as it can get when it comes to writing code. It's maybe like a 6 out of 10. It's pretty good. It won't get everything perfect. The next model will be better and it's something that we keep improving. When it comes to debugging code, it's maybe also like a 6, 6 or 7 out of 10. So I think this codebase research and onboarding onto codebase, it's, it's really, really excellent at it and at anthropic. Whenever new people join on their second day, this is part of technical onboarding. We teach them, here's quad code, here's the code base. If you have any questions, don't bug engineers on your team. Just ask quad code and they can answer these questions probably better than they can because you can search around the code. It can look through history, it can look through pull requests and slack and just pull in all the context to answer all these questions. What we saw is at anthropic technical onboarding used to take a few weeks, but now engineers are usually productive within the first few days and they don't task their teams anymore. I think this is the biggest thing where you don't need to bug your senior engineer or your manager anymore to get answers to your questions. You just ask quadcode and it can answer all these questions for you.

B (46:43)

So in the same vein, what do you find yourself using cloud code for as a leader and engineer? What's your daily use case?

A (46:55)

Yeah, I use it all day for all sorts of stuff. So obviously, like I said, code based research. If I'm working on a piece of code I'm not familiar with, I'll just start by ask quad code to tell me about it. Whenever I'm working on a small feature, I'll usually use quad code in GitHub actions. So I'll just say I'll make a new GitHub issue and then I'll say add quad. Implement this feature for me. And it'll just do it usually in one shot. And sometimes I'll do this on the command line too. So I'll just say implement this feature and make a pull request and I'll come back a few minutes later and it's done. Then there's this kind of other work where it's a little bit more complex. You can't really do it in one shot. It's not as simple as changing a piece of text or changing a button or building a small feature. Maybe it's something more involved. There's probably two workflows I have here. One is for really complex stuff. I'll prototype it a bunch. And this is something that I did even before quadcode. When you write a complex piece of code or a complex feature, often engineers will write it a few times because you don't actually know the right way to do it. And so you'll try one approach, you'll try a second approach, you'll try a third approach and you'll kind of figure out the the edge cases for each and the limitations. And you'll get a feel for the problem this way. And this is something I used to do by hand. Nowadays I'll just tell quad code to do it. So I'll maybe make a few git work trees, I'll launch a few quads, and then in parallel I'll tell them here's your job. I want you to implement this feature, go to town, and I'll then look at each of the solutions and try to figure out, okay, maybe I like this piece of this one, this piece of this one, this piece of this one, and then I'll throw away all that code, I'll discard it, and then I'll start a new quad and I'll tell it, okay, here's how I want you to do it. Now that I got a feel for the problem, and then I think the last workflow is actually the one I probably use the most. And this is probably for medium sized features. And in this one I'll ask Claude to make a plan and I'll go back and forth with it a little bit on that plan. And it's really important actually to get that plan right and to make sure it's the same thing you have in mind before you continue. Because otherwise, what I see sometimes is people ask Quad for a little bit too much. Maybe it's a complex feature and then it wrote it in some way that it's not at all what you wanted. But the problem isn't that Quad doesn't know how to do it. The problem is that the description is just too low bandwidth. You only described in a few words what you want. And so the idea that Claude got of it is a very different idea than what you had in mind. And so I find that planning helps a lot. So you kind of iterate on the plan the same way that you would with anyone else you're working, working with. And then once that's ready, I'll ask Claude to write the plan to a file maybe, and then I'll tell it to kind of implement that plan and it'll naturally make a to do list for itself to implement it.

B (49:35)

All right, switching text a little bit. I'd love to talk about the space more broadly. So Claud code is a rocket ship within the anthropic rocket ship. But equally there are other products like Cursor, windsurf, REPLIT, Lovable, V0. The list goes on and on. And we've had a few of those CEOs on this podcast. What do you make of the space going forward? Do you think we end up with a bunch of different solutions, doing different things? Do you think there is, at some point a winner takes all kind of scenario? How do you think about the next couple of years?

A (50:19)

Yeah, my feeling is there's kind of two dynamics here. One is that this is just a giant market. The market you could think of it as all of coding. You could think of it as all of kind of creativity and kind of create. Creating things, because this extends at some point beyond coding to design and things like this. So I think there's room for everyone. It's a giant market, and the biggest thing that these companies should be thinking about is everyone that's not yet using AI for coding. Because if you only focus on people that use AI for coding already, these are kind of the early adopters, so you want to kind of get into that curve and get the middle and the late adopters too. And many of these don't even use AI today. So I think it's a big market. I personally use a lot of these products, and I use quadcode every day, but I also use Cursor every day, and I use other products every day. So there's room for all of these and they all kind of fit together into people's workflows. The second way to think about it is, like I said before, the model is getting better so quickly that the kinds of things it's able to do are just changing every few months. It's this exponential that just keeps accelerating. And this is really the feeling inside of the lab working on AI and kind of building this stuff. And hopefully it's also the feeling that users have as you get to use all these new products that are coming out every few weeks or maybe a few days at this point. So, yeah, it's really exciting. And I think my advice to companies building is definitely build for what the model will be able to do six months from now, not for what the model can do today. This is probably the single biggest advice, and this is something that we followed for Quad Code also. We started building Quad Code when it was still Sonnet 3.5, and it was okay. And then with 3.6 and 3.7, it was fine. It was pretty good. But then when Sonnet 4 and Opus 4 came out, that's when it really hit its stride. And we felt like the product was really good and we started to be able to use it for a lot of coding. And so this is the biggest way I would think about it is how do you build the product that captures the model capabilities six, maybe even 12 months from now, and the market for those capabilities is just going to be huge.

B (52:24)

Yeah. And to double click on that, if I'm a product builder or founder, how do I know that? How do I know what's in the six months horizon? You know, speaking of anthropic or in general, what is it that is going to happen in the next six months that I should plan on talking about? The coding capabilities?

A (52:50)

Yeah, I think the biggest thing is just use all these products and see where they stumble and try to get a feel for the model itself. I think QuadCode is a really good way to do that. There's probably other ways too, but try to kind of get away from all the scaffolding and all the products people have built around it and just get a feel for the model's capabilities in as raw form as you can and try to get your head around the limitations. Like where exactly does the model stumble today? What is exactly that frontier where it's not very good and then sometimes it's good and maybe 50% of the time it's good. You can kind of get a feel for this frontier. And with the models today, a lot of this is around kind of agentic work where it can use tools really well and then at some point maybe it'll fall over when there's too much context or too many tools or the trajectory is too long. Maybe if you've been running quad for two hours, it loses track after a little bit. So there's some sort of frontier here. Maybe there's another frontier around code quality, where today I have to maybe correct the model when maybe there's something that it does that isn't exactly the way I would have written it. And I think over time models will get better at kind of understanding this too. So I would just try to use the model in as raw a form as you can and get a feel for these frontiers in the domain you care about. So for coding, maybe it's kind of how long the trajectory is and whether the model can stay on track and then the quality of the code and probably a bunch of other stuff. And then for non coding domains there's a lot more.

B (54:11)

So still in the same vein of the AI coding wars, it seems that there is this competition, competition kind of dynamic, where Anthropic or others would provide their models to companies like Cursor or Windsurf at some point, but equally build cloud code, which is an application. Do you think that's the long term sort of way the ecosystem works? Or in a context where Cursor is saying that they're going to build their own models as well. The end result is kind of like full stack players where everybody has their own underlying model and application on top.

A (54:58)

I think there's probably room for both. And my personal take is probably there's more stuff built on top of the platform than there will be built in house just because there's so many things to build and there's just not enough time and enough people and energy to build all those things. So I think a lot of the innovation is going to happen on top of the APIs and SDKs that are built.

B (55:16)

As a last theme for this conversation, sort of the elephant in the room is what that means for coding and coding as a profession. What's your general sense for what coding is going to look like in a few years from now?

A (55:37)

Yeah, it's a little bit hard to say. A few years from now is in AI time. It's like decades in normal time. I think even today for a lot of professional coders, it's really easy to lament the state of coding and to think, you know, I used to write this code by hand and, you know, now it's this agent doing all of it. I think actually being the one that does this work, it's incredibly exciting to have an agent write the code. It feels very empowering as an engineer because I can explore a lot more ideas than I could before. I can do it much faster. I can work in domains that I know literally nothing about. You know, maybe I don't know iOS, but I can write an app because I can just generally code review the code and I can see it looks reasonable. But Quad actually does all the writing and all the testing of it. There's one engineer on the team, Lena, she still writes C on the weekend, sometimes by hand. She was telling me because as a programmer, this is one of the things that we enjoy. Sometimes you have to get down to the metal and you have to do it this way. But I see this as a transition, the same way that in the 60s there was this transition between punch cards and assembly and then later on between assembly and Fortran and COBOL and the first high level languages. And I think this is just another next transition. It's hard to know exactly how this is going to play out. I think one way it will definitely play out is it's going to change programming, where programming is no longer direct text manipulation, but it's more working with agents to get the work done. And I think it's going to be hugely empowering where a lot of people that couldn't create before can now create. And even if maybe you don't know anything about apps, you can use Lovable or you can use another platform to build cool stuff that you couldn't before, this is just hugely exciting.

B (57:25)

But If I'm a young developer today or I want to make coding or building applications my career, what would you say, what would you tell younger version of Boris of the beginning of your career for future in the field? What do I need to learn?

A (57:44)

I think for people that are learning coding today, it's actually harder than it was when I was running coding because not only do you have to know coding, because you still have to understand the languages, you still have to understand the frameworks, you still have to understand system design and all this stuff, but also you have to use all these tools and you have to do both. You have to hold both in your head at once. So you have to code so that you can check what the model does and you know how to direct it. Because you have to have, you know, still with the models of today, you have to know what you're doing in order to direct coding agents effectively. But at the same time, you have to be using all this new technology, you have to be using quad code, and you have to be using all these new agent encoding tools, because this is what the future is. And I think it's hugely important to understand, understand what these are and what it lets you do, and to learn how to function both when writing code manually and when using these tools.

B (58:35)

All right, it's been a fantastic conversation, maybe to close, give us a sense for what the next few weeks or months or year looks like for Claude code. Anything on the roadmap, Anything you're excited about? Anything you can talk about?

A (58:48)

Yeah, there's a lot of stuff we're working on. We landed native Windows support recently and we're working on single file distribution. So you don't need Node JS anymore. You can just use quad code and it's a single binary that you can use anywhere. So much more portable. We're working on getting quad code into more places, so wherever you are, you can use quad code more easily, the same way that you can on GitHub today. And expect a lot more agents so, you know, be able to launch agents, agents, managing agents, in a lot more kind of freedom, freedom this way. And continuing to level up the listed art and figure out what's next. But I would say, overall, we don't really know still. We're testing stuff out and we have a lot of ideas and we don't know what's going to work, but we're excited to show what we come up with and see if people like it.

B (59:38)

That feels like a wonderful place to leave the conversation and very fitting as we all try to figure out not only where we take AI, but where AI takes us collectively. So it's been wonderful. Thank you so much, Boris. Really appreciate your spending some time with us today.

A (59:54)

Yeah, thank you, Matt.

B (59:56)

Hi, it's Matt Turk again. Thanks for listening to this episode of the MAD Podcast. If you enjoyed it, we'd be very grateful if you would consider subscribing, if you haven't already, or leaving a positive review or comment on whichever platform you're watching this or listening to this episode from. This really helps us build a podcast and get great guests. Thanks and see you at the next episode.