Episode 5

Beyang: Whoever builds the most powerful, interesting AI coding agent, then that will steer how the next generation of models will evolve too, because that's where a lot of the training data will get generated.

Quinn: Yeah. And models for the most part were trained. And what we're seeing is they're very high affinity for the tools that we think that they're trained with. Like things like edit file and those kinds of things. Even we're seeing like Gemini seem to be more reluctant to run shell commands. And I mean, that gets to what we're talking about at the beginning. If you have MCP jam in like a hundred other tools, it hasn't seen any of those. And it's not nearly as good at invoking them. But, you know, that's where the next generation of models, they're probably going to kind of expand to, you know, more common kinds of tools to call.

Thorsten: It's kind of an arms race, right? It's this, the models are not, you know, coming back to what we said earlier, like if you have a model selector and just arbitrary tools, you won't get the same result as when you have tools that are optimized for one model with which it was trained. But then the big labs are incentivized to make their models work with a lot of different tool implementations and have them be as generic as possible.

Beyang: Welcome everyone to another installment of Raising an Agents. I'm here with Thorsten and Quinn.

Thorsten: Hello, nice to be here.

Beyang: And my name is Beyang, and we're just going to have a casual conversation about the latest on Amp and coding agents. And I think this time is a little bit different because we're all here in the SF office. Yes. So it's cool to be in person.

Thorsten: It's no Zoom. It's no 6 a.m. for you. It's no 6 a.m. for me. It's in the afternoon. It's nice.

Beyang: Yeah, awesome. All right, well, let's dive in. I guess it's been five weeks, five long weeks, since the last installment of this. So it feels like it's like an eon in terms of AI land. So what has changed in the last five weeks in the realm of coding agents?

Thorsten: You want to go or should I go? I'll go, I'll go. I'll say, I think, even though it sounds smug, I think a lot of the stuff we've been saying in the first four episodes have turned out to be true. Like, when you look around the landscape, there's more agents, there's more coding agents that are based on the same idea that, you know, unconstrained tokens, you have like a tool selection. I think if they would all open up the hood, you would also see that most of them also ripped out a lot of the stuff they built before and now replace it with Claude 3.7 and tool calls. And I think a lot of them are waking up to this. So yeah, I don't want to say everything we said is going to come true, but I think we were right with this a couple of weeks back.

Quinn: Yeah, you published the how to build an agent. You walk people through how to do that. Subtitle, The Emperor Has No Clothes. And yet still we literally publish all of our secrets we tell people how to build the damn thing and then it doesn't quite click for a lot of people they say, "there's no moat okay, but what is your moat?" Yeah why is that?

Thorsten: I don't know so the the blog post for everybody who hasn't read it is it explains like how to build your own coding agent in 300 lines of code and I wrote this first internally because people would use Amp and they would say like how do you do this when say it runs into a terminal error or how do you do this when it fails to edit a file or something or how do you do this or this and the response has always been we don't do anything really we just send the error message up to the model and then the model goes and decides to do something else like example the model decides to run a terminal command command not found there's no logic it's just command not found send it back up and then the model says let me try something else and the blog post explains it's like there's nothing it's just basically all text you send up to the model the model comes back down with text and yet still like I wrote in the blog post that you know everything in Amp like you know don't mistake this like there's a lot of elbow grease in Amp to make it work well and to tune the tools, to be more reliable and to make the UI look good. But ultimately, a lot of it comes down to the model. And still people read the blog post and they go, but how do you do this? There has to be something there. There has to be something of how you do this.

Quinn: Or they think that there's something in our system prompt that's genius. There's that repo that said, here's a trillion dollars of value. I've taken the system prompts from these tools. And what we've seen is we've gotten a lot more people on is people will try one thing in Amp and then the same thing in like Cursor or Windsurf or Claude Code and really it's like rolling the dice and if Amp gets it right because of you know total luck they're like wow Amp is really good and if we don't they're like oh this thing you know sucks and it's kind of crazy it's like you know if you went at blackjack you're not like smart, you know?

Thorsten: Yeah.

Quinn: Right?

Thorsten: Yeah. But it's just like, okay, how will the cards influence how the model worked? Or, oh, your cards work better at Blackjack or something. But it's not, that's not the case. I think there's

Quinn: And people want to think that it's the case.

Thorsten: Yeah.

Quinn: Because that is their mental model for how applications are built.

Beyang: Like there must be some "one weird trick" that you're doing that makes the agent work.

Thorsten: I think the system prompt does play a role, but I don't know, I think the model is the biggest thing that's still determining stuff. The prompt you throw in also has a lot of value, like a lot of influence. And the system prompt has like, I don't know how to describe it yet, but it influences maybe how aggressive or tame the model will be and what tools it uses for which occasion, stuff like this. But a lot of the things that people point out where here's where Amp worked, here's where it didn't work, or here's where Cursor worked, or Windsurf, or whatsoever. It's hard to pinpoint it. It's hard to say, you know, oh, it did this or it did this when, or this was the system prompt or it was this when in fact it was, you know, maybe the difference between you using a library that's, I don't know, has a new version out and the LLM is outdated. So in this case, there's nothing any system prompt could do.

Beyang: Yeah. Yeah. It's not one weird trick. It's a bunch of tricks and other things that we've implemented along the way in response to like failure modes, right?

Thorsten: Yes. I would say it's the most important thing is, and I, you know, not die on this hill, but it's a hill I'm willing to stand on right now, is that I think a good curated set of tools that's tuned and that has good prompts, I think that goes a long way, which is also why I don't really believe in the, you know, here, like, pick out of these hundred tools, pick the ones you like the best. I think that won't lead to the best result. If you just want to have a conversation with the model and you only have search available, then sure, only enable search. But if you wanted to actually do stuff in your code base, I think you want tools with prompts that are tuned to each other.

Beyang: Yeah. What doesn't work is here's a bunch of like, here's a hundred different tools where the prompts aren't tuned and just expect it to work.

Quinn: Yeah, most of what you see from people saying, I hooked up these seven MCP servers and it's amazing is a very nicely cherry picked demo path. Yeah. And in reality, if you go set up the MCP server for GitHub that everyone uses, it's got these like write file commands and the agent will get that mixed up with writing local files and it'll go like right to the main branch on your repo and you never see those in demos. Yes. So, you know, there's, I think when people don't understand that most of this comes from the model and they see these amazing demos, I can understand why they have a totally wrong mental model. But actually the beauty of understanding the mental model well is it's so simple. And so if the thing doesn't work, go and tweak your agent.md file that has the guidelines or go and change the prompt. It's not like other tools, they can do this amazing job of taking a really shitty prompt that lacks information and putting it in. Nothing can fill that gap, only you can. But that's really what's missing.

Thorsten: Yeah, I agree. I think there's also something that people often forget about is that every tool you add, if you add, I think GitHub, the MCP server, has like 40 tools. It has a lot of tools. And all of that gets added to your system prompt. And that also makes it slower. And it also, it's more stuff that the model has to think about. So you give it 180 tools because you added four MCP servers and then you ask it to do something ambiguous, it's going to try stuff, you know? But it won't lead to the best experience.

Beyang: Makes sense. So in terms of like how you would describe what does differentiate Amp from other coding agents, like we just said that there's no one weird trick. There's no like succinct way of describing it at the implementation level. I think one of the things that has emerged as we've been talking about this ourselves is just like what sort of like persona or what sort of like feedback we're optimizing for. So yeah, like how would you describe what the target audience for Amp is?

Quinn: It's the person who wants it to work well. When you can get out of the mindset of people who either don't put in the effort to make this new tool work for them or who try to catch it, like, you know, ha ha, I got it, when they have a really bad prompt. Those people, we want to help them eventually, but we want to work with and build it for the people that want to put in a little bit of work that know how amazing this can be if it does work well. And so there's so many piece of feedback we've gotten from people that are really well intended where if we had done that, that would have taken us down a route that would have overfit to today's model capabilities that would have optimized for that user who doesn't want to do any work. And it's like an LLM, it can be really smart, but if you're holding fingers behind your back, it can't count how many fingers there are does not know that information fundamentally yeah so we also think that the whole idea of agents is it can like magnify the impact a single person can have so if you've got a company with 100 engineers and five of them are really good at using agents like they will spread that gospel to the rest of the devs you don't need to win over all 100 you don't need to win over the detractors you know you can kind of let that soak you know seek kind of soak into them eventually yeah

Thorsten: yeah I'll add that I for me it's what I don't want to build or what I don't even what I'm not interested in is this tool with you know one line prompt and it's like build me a wedding website you know and then it just goes and does stuff and I don't that's not what I want to build what I want to build is this power drill, like a power tool that I can use to get more stuff done in code. And that helps me with the grunt work and the busy work and all of that stuff that you really only start to notice once you see the agent do it. Like a friend and I, we were talking this morning and he said, you know, he's been recently getting into AI and he made the honest effort and he's like, I tried to use it by just not writing any code and by really telling it what I wanted to do. And he said what I told him earlier that you need to accept that it doesn't know certain things. It's not wishing well, so you have to be explicit and then you instruct it. You send it off and it does stuff for you. And what he said was that he realized how much busy work he has to do with normal programming. Just fixing the parentheses here, fixing the braces here, moving the import up there, renaming this file, blah, blah, blah, blah, blah. And I basically, I want to have these agents that go off and do this stuff for me. I don't want like the building, the wedding website. I want move this over here and refactor this so it calls this and then go into it. That's what I want, like a power tool.

Beyang: It's like there's a difference between like good reading your mind and bad reading your mind. Like, good reading your mind is like, oh, you've been watching me as I've been doing stuff. And so you kind of anticipate what I want to do next because there's enough actual signal there. Bad reading your mind is like, oh, I just typed in like a five word prompt and I expect a whole application. Like, almost at like an information theoretic level, there's not enough bits of information encapsulated that prompt. So if you're using a tool that actually goes and builds the full app for you, it's kind of just relying on its own priors or what's baked into its training data to do that.

Quinn: Yeah. And then people say, oh, well, if it doesn't have the information it needs, it should ask me. And then, of course, if we went and built it, we said, we told the agent in the system prompt maybe, be more tentative, ask the user if you're not sure. We've actually experimented with some of this. And the problem is then people say, I don't want it asking me all these things.

Thorsten: Why didn't it do this? It should do this. It shouldn't ask me. It's an interesting thing where the image I have in mind is that it's a senior engineer that doesn't work at this company, that doesn't know the code base. But if it's a senior engineer, I can tell that engineer enough information so it goes off and does stuff. But certain things that are unspoken, I can trust it does the right thing. You know, like how to name variables and stuff like this. I don't have to spell this out. But I wouldn't expect a senior engineer that I pull off the street to know where our authentication system is used. Or that this folder is like an old folder. You shouldn't touch this. It doesn't say anywhere that it's deprecated. It's just something that we all know. So that's the mental model I have. And I think that's still super useful. Even though it's not even close to this like, oh, you know, it just knows your code base and it goes and does stuff magically. And you don't ever have to tell it anything.

Beyang: Yeah. So we're kind of optimizing for a user set of people who want to use AI as like a power tool. Yeah. Right. And so along with that, we've kind of curated the early access user base of Amp.

Quinn: We love our early access users. If you're listening and you're in that, thank you. We will keep the tokens flowing if you keep the feedback flowing.

Beyang: It's almost like, you know, we're training, like the process of building application is like a training process in itself. And we've purposely curated our training data, you know, like our early access user feedback group to be, you know, folks that give sort of the feedback that lead towards building a really good power tool rather than, you know, a read my mind kind of beginner shallow tool. Yeah. Okay, so I want to talk about some of the feedback that we receive because it's been really interesting. We have people who are kind of like pushing the frontiers of what is possible, I think, with agents and LLMs. And there's almost like an emerging set of best practices or like a meta for how to invoke Amp. Say a bit about that. What are some of the kind of like patterns you've seen emerge?

Thorsten: I mean, we have thread sharing built in. So internally we see how a lot of people use prompts, what they write in their prompts. So that's been useful to get like glimpses into this. And I think the first step that people take is they start by, you know, this is not meta, basically. This is pre, you know, anything. It's just they start writing stuff and then they watch the agent go and figure stuff out. And then they realize I didn't get it. So then the next obvious step is like everything I know about this problem, I'm going to put in this, you know, and all of the files that I mentioned, I'm going to put in this. Or that's the first step. Then I would say the second step is people optimize for feedback loops, and we've talked about this before here, that it's, okay, I wanted to solve this problem. Let me make sure that the dev server is running, that the URL is accessible for the agent so I can put it in and the agent fetches the stuff that it needs to fetch and it has like a feedback loop, blah, blah, blah. And I would say the next stage is what I think you've been doing so a lot and others, they have the agent write out plan files. It's like, first, write me a file with all of the to-dos that you have to do. And then they tell it to go and only do the first one. Then they maybe tell another agent, go and fix the next one. Tell another agent, go and fix the third one or something. Then I think there's like this other early access users. There's this even layer above where people just automate all of this and spawn different agents and have like their own supervisor and whatnot. And it's just, that's the ultimate level. But that's not meta that everybody uses.

Beyang: There's that one individual who's really pushing the boundaries.

Quinn: I mean, Geoff Huntley, he's been live streaming four or more agents, operating like 24-7 when he goes to sleep or when he heads out and he is on Twitter and there's like 500 people watching them. It's pretty amazing. And we're really lucky to have people like that that are pushing the boundaries there.

Thorsten: I would say there's like one other thing. What Geoff is doing is interesting. He built his own supervisor to restart the agents and to kick them into gear again and to resume them and make sure that nothing is ever idle, that the tokens keep flowing. And Indigo, who was just here, he also has multiple agents running at the same time. And what both of them do, which I think is, we talked about this before, this big question. What both of them do is they organize their code base so it's even possible to do this. So we were just talking to Indigo and he's saying, well, some parts of the code base, I know that I will have to write this because it's like high signal code and then it puts the lines in the sand where I can then have four other agents fill out the rest. So the feedback loop is that, you know, I want them to go for a really long time. How can I do this? Well, I have to organize the code base in a certain way. And I think Geoff is doing this. And I think even going back to the first few levels of meta, I think a lot of the users are also doing this. First obvious step, the models are, you know, that's not Amp, that's the models. I think the models are not that great at large files yet, even though they fit in the context window, but editing large files is an issue. So obvious steps split up large files. Like why have a 4,000 line test file when you can have two, three, four files?

Quinn: Going back to the users that we want to build for, this came up. We have a bunch of customers that for whatever reasons, they have very large files and they gave us this feedback that it just doesn't work well. Really nothing works that well in these large files. And I think that they deep down want us to be building for the people that care more about agents working really well than letting them have 9,000 line files. And they don't have a good reason. Why can't you break it up into multiple files? And we really believe that agents are so valuable that they will be good motivation to break it up. But it is so refreshing and frankly, it helps us move so much faster to just say, we are not going to try to solve that case. Or there's another person who had a good idea, totally plausible idea today to make it so that if we don't find our agent.md file, that it will read the claude.md file. Now, the problem is if we do that, then we have to read the .cursor rules, .windsurf rules, .cline rules, whatever. And then which one, what order does it do? And then it's confusing. And that's the kind of stuff that means we're not making the core agent better. Yeah. So that's, yeah, another example.

Thorsten: Yeah. I don't know when we talked about this. One of the first episodes about this, right? Like, will the code base bend to the agents or will the agents bend to the code base? And by now, my money is on the code base will bend for the agents. Like, I, you know, my argument is I've talked with, you know, we're in San Francisco. I talked with a bunch of programmers, met people for coffee. And there's been three people in the last three or four days that had the same CV as I have. They, you know, have like 10 years of Vim, hardcore Vim, only terminal. I love my editor. And now suddenly they use VS Code and Amp or other, you know, agents and other editors because it's such a multiplier that they now realize, I don't care really much that more about the editor. And is there a force stronger in the universe than the force that can separate the programmer from his favorite text editor?

Quinn: So let me ask you a question. I would say all the Emacs people I know, they've already switched to VS Code and Agents. And do you think that's because, and Beyang and I use Emacs, do you think it's because Emacs people are smarter and they saw the future earlier? Or Emacs is not as good of an editor, so they switch sooner? No, no.

Thorsten: They do it because they see it as another reason to write Elisp because then they go like, well, I could have the agent also program Emacs, and I could access Emacs. The other thing is a false rule. Yeah.

Quinn: Steve Yeggie, he might be working on Amp for Emacs. We'll see. That's true.

Thorsten: But one of our colleagues, Keegan, he's a hardcore Emacs guy, and for him, the big light bulb moment was going back to there's no moat and nothing. For him, he built an MCP server that does Elisp or something, like it connects to Emacs. And it turns out the models, they know Elisp well. So he had the agent connect to his Emacs instance and ask it, you know, because everything in his life is apparently Emacs, also emails. So he asked the agent, can you find the email that, you know, I first sent to Thorsten or something? And the agent went and it looked through Emacs because it's all text, so it's super easy to consume. And then it found the email. Like it used Elisp and it used text and it found the thing and returned it back. And for him, there was this, oh shit, like it's, you know, there's no magic. Like it's truly just text. And it's also this like finally the Unix philosophy coming true. Like you just have to send the content of the buffer back and it gets it. You know, it was nice.

Quinn: And for us, as we're thinking about adding support for more editors, I think in the old world, everyone would think, oh, let's go build a JetBrains plugin. Let's go build visual studio emacs neovim whatever blah blah blah um the way that we're thinking about it is VS Code let's make that really first class let's have a great web experience and have that work remotely so you can beat your kids soccer game and kick stuff off let's have a really great CLI and see how far we can get there and then any kind of hooks we have in other editors would be like not in the jetbrains UI it would just be having like Amp's get diagnostics tool call into the JetBrains API, but just a shim, no UI there.

Thorsten: Yeah. Yeah, I think there's something. I also talked with somebody about this this morning that, you know, we've been saying before that the game is you have to stay nimble, you have to stay fast. That also means you have to keep your surface low. That also means you cannot build elaborate integrations into large IDE surfaces because it kind of ties you this one thing.

Quinn: We know from experience. It's very difficult.

Thorsten: Yeah, it's very difficult. And so the question this person had was like, but how do you balance this if the agent gets better the more access to information they have or the more feedback they get from the IDE and the tooling? How do you balance this with not getting too deep into this other thing? And I don't know yet what the technical solution is, but I think there might be a way where you can wrap other stuff and kind of intercept stuff without being super integrated. But it's an interesting question.

Quinn: Yeah. All right. So a question came up from a customer today, which is, you know, if they got 20,000 or 40,000 engineers or whatever, will all of them get full agents that can run tools? Or will there be, from a cost point of view, some restrictions or security? Like, what does that look like?

Thorsten: What did you say?

Quinn: You first.

Thorsten: What I said, right? Like, for me, it's a tool that a programmer yields. It's like it's a thing that makes them more productive. It gives them more leverage. So I would say, yeah, like give every programmer access to this tool. Like why would you hold back? I mean cost, okay. But then it's still, I don't know, you know. Do some engineers get better computers than others? And, you know, like it's okay if they wait longer for it to compile. Then I don't know.

Beyang: I think it's like you look at the amount of time that this can save humans and it more than pays for itself for any role under the very large umbrella of software engineer. And I feel like asking that question, it's almost like, do you ask if some subset of your developers can access a compiler or something like that? I feel like in the very near future, this will become kind of like a must-have essential part of any programmer's tool belt.

Thorsten: Yeah, and before you answer, one interesting thing on the cost. I'm surprised by how many people, even I would say haters online that don't like AI stuff, when people say, I spend the weekend, I put like 50 bucks into this and I just let it rip or something, and then it did this. And even people that said, oh, this is the first time I'm using an agent and I just put, I think somebody was like, I put $70 in tokens and it fixed like this old code base. And instead of saying, wow, $70, like that's a lot. And, you know, when people would say, why would I pay for a text editor or something like this? Like $70 is a lot. But they would go, huh, compared to my salary, compared to a junior dev salary, that's not that crazy. Like to me, it's amazing how quickly people jump to this and say, actually, it's fine to pay for this because it is making me more productive. So what did you say to the customer?

Quinn: Yeah, I think that there's the reality of rolling it out. And most companies are not able to roll out something that all of a sudden means 20% higher cost or 10% higher cost across their entire software engineering team. So there's probably some phased rollout. But yeah, I mean, if you're going to pay for a human, which is way more expensive than any of these things and that has way more risk, you know, in some sense, then you're going to want to equip them with the best. But it's an interesting path between where we are today and there. And I think there are going to be a lot of engineering teams that say, if an agent costs 20% of a human developer's salary, it's probably in the high end, but let's say, if it gets into feedback loops, then they're going to have to change the structure of their engineering team. We've heard from a lot of companies that have kept engineering headcount flat for various economic reasons over the last few years, and now because they're looking ahead and they're saying maybe we don't need more engineers. And actually when you consider like, you know, actually cutting a team versus not hiring in the future, it's the not hiring in the future that has a much bigger impact on total employment. Because let's say you cut, you know, 10% or 20% or something. Obviously that's really tough, you know, and that's like a fair number of people. But if you look at all the people that you're not hiring because you're in a lower trajectory, that's actually a lot more people that don't have jobs. Yeah.

Beyang: Yeah.

Quinn: Back to the tech stuff.

Beyang: Okay, so I wanted to talk about, because earlier we were talking about curating the feedback that we get and being very intentional about what feedback we respond to. And it's almost like we've realized that in order to build for this new world, we're not just building a product. We're also building a set of best practices for invoking that product and getting the most power out of AI. And part of that is like the feedback loop construction. So say more about that. And I think one thing in particular is, you know, like when people use Amp for the first time, I think this holds for a lot of AI tools. You know, there's a general perception that it does better on like front end code, specifically like front end React code. But we've seen people have success with like back end code as well. So how does the feedback loop construction play into getting power and leverage out of this and beyond just the kind of like simple React app scenario?

Thorsten: Yeah, I think on the simplest level, it's, I said this before too, right? That if you ask a human to zero shot 500 lines, they can write you 500 lines, but they will not be correct. You need compiler feedback. You need some indication that what you're doing is correct. The squiggly lines, the diagnostics, you run the tests, you run the compiler, or you look at it in the browser or something. Turns out that's the same thing for agents. You need to give them feedback about what they're doing and whether it's correct or not. If you don't show them compiler errors, they might as well think you're using Svelte 4 instead of 5 because you just don't tell them and the code looks correct. So that's the whole idea behind this. And the first step is that languages that have type systems can often produce more helpful errors because it kind of gives you constraints about what you can put where and it kind of makes the agent use the code more correctly. And then I think beyond that, it's about surfacing diagnostics, meaning from the language server, making sure that the agent knows how to build and test this and constantly reminding it of it, which we now do with the agent file. You even tell it manually, which is what I often do. If you work on this, constantly run this test, just this test, ignore the others. And then it also knows whether what it's doing is right or wrong. And then my favorite bit is, and this is coming back to React, is when you work on front-end components and you tell it to open the browser and look at the browser, it's surprisingly good at this. And it's surprisingly good at JavaScript. So with like Playwright integration, it can query the DOM, it can navigate the page, and it, you know, modify the page. And my favorite experience was when, who was it? I think we were on a call with somebody else, and I built like a Space Invaders game, like as a demo. And then I said, can you make sure that this still works? And it opened the game in the browser, and the game would say, press space to start. And the agent would press space to start. And then would shoot something at the alien to make sure it works. So you built a weapon system. I mean, Ender's Game, you know. Yeah. Yeah.

Quinn: Yeah, when people say AI doesn't work, then there's always things that you can do. Because, again, there's no moat. These things are not complex. So if it doesn't work for your project, the first thing to ask is, is it actually doing the build? And 90% of the cases I see, because a lot of people will try something that doesn't work and then they can share the thread with us in Amp. 90% of the time, it's not actually running the build. And then we can help them. We write the agent.md file or something like that. Then it does that. And then it's, can it run the build in a granular way? Can it run the test in a granular way? And you've got to get it in those feedback loops. And if you do, it's not like it's going to be perfect, but it is going to be so much better. And so, yeah, I mean, I don't know. I think it's still just such a puzzle for us. And that's why we're saying this over and over again to try to explain how these things work and how moldable they are. Because you should never stop at, oh, it doesn't work for this.

Thorsten: Yeah. And talking about build tools, you know how some build tools, they spit out a lot of warnings and, you know, they're super verbose. Turns out that's not good for the agents. And it's also not good if I hire a new junior engineer and say, build this web app, and it shows up eight warnings. Then I have to go over and say, you can ignore those eight warnings. They're harmless. But they wouldn't know. And the agent also has this other thing with everything goes into context. Everything is under the attention mechanism. So you can trip it up by putting unrelated stuff in the context we know. And so there's this incentive that they're just like us. The agents profit from having good build tools that have clean and actionable output.

Quinn: Yeah. But as we know, sometimes some error that seems unrelated actually is related. And part of being a programmer with a lot of intuition and experience is knowing when that is the case.

Beyang: Yeah.

Quinn: So that's why, you know, you can't be like, oh, the model should have ignored that because as humans, you know, you can't always ignore that either.

Thorsten: But there's good moments where in our project we have like multiple subfolders that are pretty independent of each other, like the, you know, different packages, extension CLI, for example. And then sometimes what it would do is it would run the build. And because I didn't PNPM install or something, so somebody added a dependency to some of the other projects that I wasn't working on, the model would go, there's an unrelated error because, you know, but that's unrelated to our changes. So that's a nice detail.

Quinn: Yeah. But just thinking, like, that's a really valuable feature. But I'm pretty sure that the models were trained on some examples where it had errors that were unrelated.

Thorsten: Yeah, yeah, yeah.

Quinn: And if you're thinking of the, I don't know, like, you know, 50,000 examples that the models were trained on to be really good at this kind of tool calling, it's just kind of a shame that like 700 of them had to be for this kind of thing because these people were so fucking stubborn where they're like, I wanted to know. And what are we being robbed of? Because that's what the models were having to do.

Thorsten: That's a good point. Yeah, that's a good point. Like, what if they were only trained on code bases that were optimized for the agents? Like, how fast could they go? Yeah. Like if everything was standardized, you know?

Quinn: Yeah.

Thorsten: Yeah. But yeah, not the real world.

Beyang: Yeah, I mean, I think over time you might start to see this feedback loop between the model behavior and the application layer in terms of like what workflows or what routes to the code base the application kind of like steers you toward. You know that at some level generates the training data that then gets fed back into the next round of like model training. And so yeah, it's almost like whatever the most compelling like AI coding agent, like whoever builds the most like powerful, interesting AI coding agent, then that will kind of like steer how the next generation of models will evolve too, because that's, that's where a lot of the training data will get generated.

Quinn: Yeah, and models for the most part were trained, and what we're seeing is they're very high affinity for the tools that we think that they're trained with, like things like edit file and those kind of things. Even we're seeing like Gemini seem to be more reluctant to run shell commands. And I mean, that gets to what we're talking about at the beginning. If you have MCP jam in like 100 other tools, it hasn't seen any of those, and it's not nearly as good at invoking them. But, you know, that's where the next generation of models, they're probably going to kind of expand to, you know, more common kinds of tools to call.

Thorsten: It's kind of an arms race, right? It's this, the models are not, you know, coming back to what we said earlier, like if you have a model selector and just arbitrary tools, you won't get the same result as when you have tools that are optimized for one model with which it was trained. But then the big labs are incentivized to make their models work with a lot of different tool implementations and have them be as generic as possible. So, you know, there's like this back and forth and we'll have to see where we end up. But it's right now, I think the state is that you have to get a feel for what the model was trained for. And I think, you know, Paul from Aider, like he's been blogging about this since I think a year at least, where I noticed that in this benchmark, this model likes this format of diff a lot more. And that's even pre-agentic, like he uses his own way of tool calling or did, and his own format for diffs, and the models work with different ways. And I think he had this anecdote that he posted somewhere where he was using one format of diff for one model because he thought the model would notice, but then the people who trained the model came back to him and said, actually, we also trained it on your other thing. And then he switched and had a performance improvement. So, yeah.

Quinn: But we want to know what did they train on. Yeah, I want to see this thing. You know, we can remember when we were talking and we can bleep that out. And they said, oh, no, you should be able just to take all the stuff you had for Claude and it should work just fine. Yeah. And we don't want that. We want to know what are the tools they trained on because they're really smart there. We want to spend time building deeply into what they did. Yeah, yeah, yeah. And when you look at Anthropic, I think one of the reasons why Claude 3.5 and 3.7 Sonnet are so good at a tool calling agent for coding is because I gotta imagine they had some precursor to Claude Code for quite a while in advance. And so they had ironed out all the bugs and they knew what to train the model with. And I want the other labs to do that same thing. And then I want us to tell, I want them to tell us all the tools they did, how the tools accept the arguments. Why do people not think that information is critical?

Beyang: So much of like quote unquote "prompt engineering" could be obviated by just like conveying like, here's the general flavor of, or like here's a sample of what the training data looked like and like the structures that were present in that. So you know like, okay, here are the general like tools or here are the general patterns that will work really well.

Thorsten: Here's a training, you know, the piece of training data where it nails it a hundred percent of the time. Like that would be super valuable.

Beyang: And I think one thing that you've also said, which really resonates, is like you do not want to go against the grain of the model. There's this notion of like the model wants to do what it wants to do. And I think we saw already some of this in like people's reaction when like 3.7 Sonnet first came out. For some of the other coding agents in the market, there was a general perception where like it was worse than 3.5. It's like 3.5, I think the general consensus is it was not as good at tool use and general reasoning, but it was much better at following instructions. So like the way that a lot of these tools worked is, you know, like Cursor, you have like a bunch of rules that you kind of create. And so like a lot of those rules are followed to a T by 3.5 Sonnet, but then 3.7 Sonnet has a greater tendency to ignore them and just want to do more, like write more code or get further along in the kind of like agentic chain of operations.

Thorsten: Yeah. There's like this interesting thing where you, I don't know, I've never trained a large language model, right? But it's on one hand, you have them trained to be this, you know, chat bot that you ask questions and it gives you answers. But that's not really what you want from an agentic model. From an agentic model, you want to give it a task and it wants to go. But at the same time, they cannot destroy the one flavor of this and making this other better. So they have to balance this. And I think that's a hard thing to do. It's what we're seeing, too, with users where they're like, sometimes I just want to ask it stuff. But then it went off and changed some files or something. But that's the same. What you're seeing is how it was trained. You know, like it was trained to be super aggressive or something. And it's a really interesting challenge.

Beyang: Yeah.

Quinn: Yeah. Oh, that gets me to another kind of common feedback we get, which is people say, I just wanted to know if it would do something, but it went and did the thing. And you look at their prompt because they share it with us. And it's like, you know, hey, I want you to, you know, I want to do this thing and whatever, you know, can you do it? Or how would you go about doing this? And then they're shocked, shocked that it went and did that thing.

Thorsten: Yeah.

Quinn: And for a lot of people, they argue to the end of their dear life that it was wrong.

Thorsten: Yeah, yeah, yeah.

Quinn: So I did this thing where I went and I put exactly one of those prompts on Twitter and I said, if someone came up to you and said exactly this, would you go and edit the files or would you just tell them? And like 70% of people said I'd go and edit the files. And it just gets to that ambiguity of language.

Beyang: Yeah, I feel like there's a lot of conventional product development wisdom that you have to question.

Quinn: The user's always right.

Beyang: Yeah, exactly. So that's a piece of conventional wisdom, right? It's like the user's always right, the user can do no wrong, and you have to go build something that works around the user's existing mental habits. But I think in the current age we're living through, things are moving so fast, what happens is if you have one set of users that want to invoke it some way, and they're set in their ways, and they don't get value out of it, they're unhappy. But this other set of users will be like, "Oh, I'll just try something different." then they'll unlock some capability and then they'll get like you know an order of magnitude more productive and then the first set you know has this like they're looking over at this like other set of users and they're like oh maybe I should copy what they're doing and so like the user behavior kind of evolves to follow whoever is able to develop this coupling of like product and best practices that...

Quinn: The product is emergent from user behavior from people like Geoff Huntley and Indigo and like us and these awesome people we have

Thorsten: Yeah but it's I think another really big thing here is that you know it talks like a human which is that that makes this hard right because then you fall into the trap of saying uh could you please do this and I always say please and thank you right but it's still like if you just instruct it and say use this to do this sometimes it's less typing and it will do it more correctly. It will use this tool that you instructed it to use, but it feels weird to do this because it feels like you're commanding this to do something. And I think there's a big challenge here where the interface, and some people say maybe that's not the best interface, you know, like RLHF models that talk back to you and want to be nice to you. Maybe that's not the best interface to instruct an agent, but it's a interesting challenge.

Beyang: Yeah, definitely. So I want to talk more about what's actually changing the product. We've talked a lot about the persona that we're optimizing for and the best practices. But how has that guided the actual product evolution? So when you think about the past couple of weeks, what have been the biggest interesting features that we've shipped?

Thorsten: I think one of the interesting or biggest things that changed the last few weeks is that our CLI, Oscar has been working on the CLI. That's been...

Beyang: We got a CLI now?

Thorsten: Yes. And I mean, it went from what you built, which was like a basic REPL, I would say, to an actual interface that actually looks good and displays stuff. And as of a couple hours ago, you can do file mentions and whatnot. I think that's the biggest piece. And then from my perspective, besides that one, it's a lot of bug fixes, tuning, changing this tool again, like fixing this other thing evaluating other models under the hood and seeing whether another model is better can we switch over um yeah that's from my perspective I don't know what you

Quinn: yeah we've got a lot more people on, and so it's also been interesting how often we need to say no or kind of subtly help the product get people to the right thing or explain that so like our frequently ignored feedback or manual and other things like that

Thorsten: yes today I think maybe I think it was the first user today we got you know we're adding more people from the waitlist and we're gonna add more people today and all of that but today was the first person that said oh you have command enter instead of enter to submit the message I love this you know every time I hit enter I'm like thank god this saved me like yes finally you know so yeah it's it's more people constantly evolving I don't think we have like a big oh it's completely different yet but it's you know also the reality of the situation is you have a team you have people working on this they all need to learn how to use it and to best work on this and we're getting to a good place here where now there's a lot of people that you know get the idea behind this and they get how to use it and they get how to make it better or also what not to do you know like we had a lot of no more features you know like no no feature make the call loop better do this keep it simple what you see is what you get don't hide this yeah simplify this

Quinn: and so we want to avoid overfitting on today's model capabilities and if we add a bunch of modes and here's how you define this and you know granular natural language rules files and you know blah blah blah, then if a great model comes out tomorrow yeah we're going to be in a tough situation because we have a lot of users who've invested a lot in all of these complex configurations and these workflows. And we would not have set the expectation that we're going to be opinionated and change. And a lot of the stuff that they put in is not going to work in the new world. We don't want to be in that situation. We don't think our users want us to be in that situation. We think people want to get on Amp because they see that the models are moving so fast and they want to see where this is going. So that's why we have literally a text area. So, so many other AI agents, they've got one of those rich text areas with like lexical or prosmere or whatever. And we've done that enough to know that's like a thousand X increase in complexity. Yes.

Thorsten: Got to keep the surface small, got to keep it simple. And I got a new metaphor. I think I said this before, like, you know, you want your product to be like this wooden scaffolding around the model so that it, that it falls off when the model gets better like it just jumps out of it and Yeah but the new metaphor is it's um maybe it's wrong but it's like say you have a broken leg and you have like a you know wooden wooden casting around it or something and what they do for animals or something like it falls off after a time like that's what this should be because we know that the new model will get better at certain things and then you have to do less and yeah the product should be ready to handle a better model

Beyang: I think this this also makes me think of one of the maybe like surprise hits in terms of features which is the the thread sharing which is in some way it's like we're not trying to build a bunch of like tightly coupled um like over optimized things around the model to get it to do the right thing it's almost like you know whatever model we integrate we want people to be able to explore what that model can do and then have that knowledge disseminate to other parts of uh like your team right like you just the best way to like get as far as you can with AI is just to see how like the the people you respect the most in your team are using it yeah and for me at least it's been like a huge learning experience because I look the way that like you both are using this and I've learned a good deal uh about you know

Thorsten: what did you learn like what what stands out for you?

Beyang: I think like one of the the realizations I had was when we had that pair programming session a couple weeks back and seeing you use it for the first time and giving it more structured input to complete larger more complex tasks uh that was kind of an aha moment because I I feel like it like I had grokked some aspects of this but I hadn't fully kind of like internalized or made explicit the the meta strategy here so I was doing it intuitively in some cases but in other cases I was falling into this failure mode where you know I'd ask it to do too much and then it would try to do stuff and uh the first few changes it made were incorrect and so it would go off the rails Yeah but having it first you know write out its plan and then anchor what it's doing against that plan helps keep it uh much more sort of like on the rails and makes makes its output a lot more auditable so like that was something cool that I learned from just like watching you do it um and yeah like you know now I just like hop into like the the team thread view every now and then and see how my favorite fellow Amp users are using it and what sort of use cases they've had recently.

Thorsten: I think there's also this, you do this a lot, when people say, oh, it didn't work for this, then the answer is that's the model. There's nothing we can do.

Quinn: It feels super dismissive. Every time I say that, it feels like I'm literally saying, fuck you, you're an idiot. Do you have any brain cells? It's the model. We're not going to fix it because we hate you and your whole family. That's what it sounds like.

Thorsten: Yeah, but it's an example that everybody knows is Claude 3.7 really loves to leave comments when it removes stuff. And we try to prompt this out of it. And somebody was saying, I have a rule file especially for this. Do not leave the comments. Do not do this. Do not ever do this. And it doesn't work.

Quinn: Well, they would show one example of it working, and then we said, okay, let me try. And then it would add comments. And you're like, oh, add this. And then it's like. Yeah, yeah.

Thorsten: And it's the grain of the model. Like they somehow trained it to leave comments when it removes an import statement no longer needed. And I'm like, dude, you put it there. Don't tell me.

Quinn: But it's possible that that in the transcript of the chat might actually be an important kind of like thought marker for it. So you don't even know if you were to get rid of that, what else would you lose? I'm not saying, oh, we can never get rid of it. Scientists don't know how. But it's this whack-a-mole thinking that we see so often.

Beyang: So earlier we talked about model choice, and we sort of made the explicit decision to not let the user decide in this case for exactly the reasons that we just talked about, because we want to build something that unlocks the capabilities of a specific model. That being said, we are trying out other models as well. So you mentioned Gemini Pro. Can you talk a little bit about how that's looking? Do we think we'll have Gemini up for all or part of the use cases we want to support? And how might the scaffolding, that wooden scaffolding that we just described, change for Gemini versus Claude?

Thorsten: I think that when a new model comes out, a lot of the other companies are like, oh, no, a benchmark, it did this. The evals. Evals, yeah. And, you know, evals are good. Like, I want to have evals. But I think this is untuned evals. Because what we just said, like, Claude has a certain way of using certain tools. And Gemini has a certain way of using other tools. And you, in order to get the most out of each model, you have to do an honest effort to tune your prompt and the tools for that specific model. Which, you know, ideally they give us like an instruction manual. This is the way you should implement your tools. Anthropic is doing this, so shout out to them. Right now, we're exploring Gemini, and it's looking good. It feels smarter in some sense, but it also feels less like a workhorse than Claude 3.7 because it's contemplating. It's like, here's what I would do. I'm like, how about you do it? How about you do it? And Claude 3.7 just goes and fixes it for you.

Quinn: And there's some weird things like Gemini will spit out in the markdown kind of content, the text content block, the whole code file that it's going to write out, and then it'll go do an edit. And that's like kind of annoying.

Beyang: Like Claude just makes the edit. Gemini is like, here is the entire file with my edit. Now let me go and like apply it. And then like reading through it, you're like, well, why don't you just...

Quinn: It's noisy. And then you waste more tokens. And it just makes me think that was the AI coding agent tool use use case kind of bolted on.

Thorsten: Yeah.

Beyang: Yeah.

Quinn: But I don't know. We'll see. I mean, I've had some pretty awesome experiences with it too. Yeah.

Thorsten: Full transparency, like we said no model selector, right? But then you can see the strength of each model and you kind of want to switch sometimes and have this model do this and you want to have this model do this. I don't think the model selector is the answer to this because it's often things that you want in the same task. Like ideally you switch the model or the models can talk to each other. You know, like if Claude 3.7 could talk to Gemini and say, what do you think I should do? And then Gemini does it and then Claude 3.7 goes and implements it. That would be ideal. And also, you know, Aider again, like they had the concept of architecture and implementer. Yeah, but it's interesting to feel the characteristics from both models.

Quinn: Yeah, I get what you're saying where I've seen that they have different strengths and it's like, oh shit, it would be nice to have a model selector if every single user knew exactly when to choose the right one and we could take them away at any moment. And so I think it's best to think about our commitment to, we are not committing to having a model selector. We are not committing to not having any kind of model selection or multimodel usage.

Beyang: I think the way it'll look is if there is this notion of like choosing a model, it's really you'll kind of like select a sub agent of sorts that will have a different model as part of its like core reasoning loop or implementation. But from the user's point of view, it's like you'll be selecting an agent rather than a model. Like taking an agent implementation and swapping out the internal model it's using, it's almost like I'm taking a robot and changing the OS and changing the brain and expecting it to work as well. It's like if you stick a fly brain into a dog robot, it's not going to work well.

Quinn: Or a Ford engine into a BMW.

Beyang: Yeah, exactly. But maybe we will have this notion of you use the Ford for some tasks and you use the BMW for other tasks or something like that.

Quinn: Both are great.

Beyang: Yes. Okay, so we've talked a lot about past state, current state, not wanting to over-optimize for this generation of models. What about the next generation like we want to we want to be skating to where the puck is going so where do we think the puck is going with respect to to coding agents?

Thorsten: Do you want to go first?

Quinn: Yeah I think that this remote execution idea that I can for my kids soccer game go and kick off threads and the agent can go do that and then there's two ways I think that I want to do in some cases it's going to be these simple tasks that it's going to have a really high accuracy and I have good intuition about what it'll do like nearly 100% on and I'll just want to merge them from there. And then in some cases, I think of the person who's playing those like 10 chess games all at once and they're going, you know, blah, blah, blah, where you kind of want to pop in. And that's really hard to do in your local state if you have like Git checkout, even Git Work Tree and you have like nine different VS codes open, that's a pain. So there's got to be some other workflow stuff around that and there's got to be some remote execution, I think. I think that's a really interesting step and that's not like having the agents necessarily communicate with each other that's just parallelizing the single agent thing

Thorsten: Yeah I think that's you know we talked about this and it sounds like a joke where it's like oh I'm at my kid's soccer game and I want to kick off an agent but the reality is that everybody who started using agentic editing bumps into this problem of well do I watch this now like do I watch it do this stuff and then everybody like I have an attention problem now like it's just the the agent is going up and it's command tab and I'm gone and then I the bing sound comes on and go back and it's like oh did you do the right thing so you immediately go into this I want to start them and then have it do stuff and then later on revisit it and everybody so far on our team who started using agentic editing came to this where they like I want to start it off while I'm using my phone and sitting and having lunch and then I want to come back

Quinn: Yeah my favorite is no names someone was going on a weekend trip with their wife and they had a list of a bunch of independent things they wanted to kick the agent to do so that when they got back from the trip, they wouldn't have wasted that time and they'd have all the diffs ready for them.

Thorsten: Yeah, yeah. I'm going to put money into this, kick it off, and then I go on the trip. So I think that's big. The other thing that's really big is where we should definitely work on, and it's just multi-agent workflows where, sure, you can launch multiple instances. You can do the thing that Geoff is doing and build your own orchestrator. But ideally, you know, this is what we do. And I think two steps further along, it's, okay, do we need to escape from the editor? Do we need to go in some other thing? Because right now the editor is mostly a diff viewing utility, right? Like, I mean, it's, I don't know how far ahead it is, but I think that's definitely something that comes up again and again. Like, how do you see the value of the text editor? When do you do multi-agent? How can I watch the agents do this stuff? And yeah.

Beyang: Yeah. What you said about, like, focus and attention, that's an interesting point. I wonder if there's, like, analogy to, like, the self-driving car, which, you know, it's a maybe overused analogy at this point. But, like, you know how, like, people said about, like, self-driving, it's, like, this middle ground of, you know, like, the human's just controlling the steering wheel completely and doing everything. It's fine. Like, you'll get to your point safely, assuming you have, like, a safe human driver. And if it's, like, fully automated, that's also fine. You don't have to worry about it but like this in between area is where you have to think about the experience a lot because what you don't want is to communicate like over communicate the level of automation and then you're in your like supposedly self-driving car you kind of like take your hand off the steering wheel and your focus off the road and then all of a sudden there's like an edge case that comes up because you're no longer like maintaining that focus and I feel like I've I have had to adjust my expectations for like flow state a bit and yeah it's not like all bad it's almost that I I feel like I've I've reached like almost like a different kind of flow state where it's like you figure out I don't know for me it's like different modalities like sometimes I'm doing you know several kind of like lightweight tasks and then it's like all right you know I'll kind of like round robin between these two but then sometimes it's like I'm I'm working on something like more focused or nuanced and so like I'll have one main thread and then my kind of like auxiliary thread is just like reading more about what it did or understanding like adjacent parts of the code base or something like that

Thorsten: Yeah but it's an actual issue it's an actual issue that everybody reported you get distracted a lot like somebody not related to us in any way but somebody tweeted yesterday that um they have like a big phone addiction problem now because like they send of stuff and then they scroll yeah it's crazy and then you know so what we're working on is eyeball tracking if we see your eyeballs going somewhere else red light comes on electric shocks you got to keep your fans on the keyboard

Quinn: an ad supported model yeah there you go yeah yeah

Beyang: I thought you were going to say like yeah like along the the line of ad supported it's like oh we're actually going to bring Twitter into your editor yeah there you go then you don't have to switch

Quinn: Yeah but even in the near term code migrations are now possible that were never possible before or code review is a much bigger problem. If there's 10 times as much code being written, you think humans are gonna do a good job of reviewing all that? They never doing a good job in the first place.

Beyang: Yeah.

Quinn: And even, I think that there's a role for letting you specify deterministic hooks so that, like common thing, if you're using Svelte 5 and the model was trained on Svelte 4, if it ever tries to do an edit file tool call that contains this literal string, in the simplest case, you wanna essentially auto interrupt the model and say, "Hey dummy, we're using Svelte 5." And little things like that can help close the gap in a pretty, I think, predictable and consistent way.

Beyang: Yeah.

Thorsten: And that's accepting the flaws of the model, right? Which is realistic and honest. And it's not expecting, "Oh, it should get it right." It's, no, no, we know that it will leave comments when it removes something.

Quinn: And it also falls away because you can imagine the next model will not try to do Svelte 4.

Thorsten: And it won't trigger it, yeah.

Beyang: It's like these almost like very lightweight guardrails that don't interfere with the core reasoning ability of the model. What you don't want to do is shove a bunch of guidelines into the context window, because then what you end up doing is confusing it, and then it does a worse job on what it's really good at, which is the core loop, like "go do stuff."

Thorsten: It's like more feedback loops when it happens versus rules up front. It's oh you just did the wrong thing you know correct this please and it probably will do it

Beyang: yeah yeah yeah cool um I think you know we're about uh out of time but like uh last thing I want to ask is you know the delta between where we are now and like where the puck is going what are kind of like the next couple things that you think we should improve or or build and like you know no commitments here but like just based on current experience and feedback that we are not ignoring?

Thorsten: Yeah, I think obviously make everything more rock solid, stable, the UI, you want it to feel nothing can ever go wrong. Like you want it to feel rock solid where the only, you know, uncertain thing is the model. Like you want the rest to feel stable.

Beyang: Yeah.

Thorsten: That's one thing. Then I think, you know, exploring what's on my list is, for example, can we add like, you know, Claude Code recently added this support for this task list management, like turning the meta into something that's now supported by the product. And again, in a lightweight way, everything else server side is interesting and being worked on. Yeah, that's like immediate, you know, switching the model, tuning the other model, more agent-to-agent stuff. Like I did something a couple of weeks back, but it didn't really work out. So now I'm thinking, can we do something else where two agents talk to each other? Can we have a supervising agent? And I think, yeah, that takes a lot of work. But yeah. Yeah.

Beyang: Yeah, we'll get there though. I think that's where I'm thinking towards too. It's like longer chains of automation, more robustness and reliability.

Quinn: Yeah. I've been working a lot on ampcode.com, the server side of it. But also that has a front end and a back end. It's database stuff, it touches on authentication. So it is, I think, a pretty good test case for a real complex app. That's what's got me thinking about the deterministic hooks. And one example is I would feel really good knowing that the agent wouldn't actually edit any files related to auth unless it got my permission to do so, or afterwards it flagged it. So, you know, just making the site better and then making it so that the agent gets better at making the site better. And with the whole Amp team, the way that we work is we're constantly using the thing. Every single person who is working on Amp is also working with our users. And we have zero issue tracker. We have zero plans. It is literally, if you're on the Amp team, we trust you to work on the thing that you think is most important. And we curate the right people so that it's not a bunch of people working on like random dumb shit

Beyang: yeah and I think that also speaks to our belief that you know if if we if we execute properly here you know stuff is going to flow out word from the editor as well and a lot of the like you know your traditional issue tracker or code review tool that might be an antiquated uh thing now with with how like coding agents work so

Thorsten: yeah

Beyang: yeah I don't know

Thorsten: lots to do

Beyang: yeah lots to do

Quinn: all right happy hacking