Amp Code: Next Generation AI Coding – Beyang Liu, Amp Code

Key Takeaways

[music] How's everyone doing today? >> Yeah, cool. Pretty cool conference, huh? Um, so yeah, my name is Vang. I'm here to talk about AMP. AMP is an opinionated frontier agent. Uh so before I get into what that means, uh who are we? Uh we're the bunch of weirdos downstairs at the booth with the weird pied piper dude on the floating golden fish. Uh and I think that kind of captures the ethos of what we're trying to do uh with AMP. We're trying to lean into that sense of awe and absurdity that I think we all experience right now living in this weird world we're living in where agents are writing an increasingly large amount of of our code. Uh and it's just kind of like weird and magical. Like if you imagine how you were working like a year ago compared to how you're working now, it it feels completely different. And so we're embracing that sense of change and we really want to be the agent research lab that's sort of like living one year in the future and figuring out how this all kind of pans out. Okay. So, what is AMP actually? Well, it's a it's a coding agent that you can invoke from the terminal. So, here's our terminal UI. Uh we actually ended up building a complete terminal UI framework up from scratch because we wanted to take advantage of all the capabilities of modern terminals. And one of the balances we tried to strike in in this UI is we try to show the right amount of information to the user that conveys what the agent is doing without overwhelming you with, you know, every single token of explanation uh that the model is generating. We stream the diffs that it's making. uh we show you what CLI commands it's using. And if you look in the bottom right hand corner there, you'll see a little Emacs 30.1 thing. This also connects to the editor that you're using where it collects diagnostics. So, Emacs, Neovim, Jet Brains. Uh you can connect the the CLI to your editor uh to collect additional information that's relevant to the task at hand. And so, this particular video is just AMP implementing a small feature to itself. Uh we asked it actually to add a little help button in the bottom lefthand corner. Uh and so that's just a quick demo to show you that uh the agent is pretty good at finding the relevant context and iterating towards that. Uh we also have an editor experience. Uh so we've not found the motivation yet to fork VS Code. Maybe we will in the future, but right now this installs into VS Code or any of its derivatives, Cursor, Windsurf, uh anti-gravity. Um and the idea here is you really write all your code through this agent panel. At least I do. Um I I actually spend very little time, you know, actually manually editing code now. And one of the bottlenecks we identified in the editor is I don't know about you, but I spend most of my time effectively doing code review now. Um just in the editor trying to read through all the agent output. That's the thing that constrains me from uh fully paralyzing, you know, 2 3x uh the number of agents that I can run at at a given time. So we built a re review reu interface that I'll talk about uh in more depth uh in a bit that uh kind of helps you streamline that process guides you through the process of understanding what the agent wrote so that you can ensure that you're not shipping something that's super sloppy or spaghetti. Okay, so I hear all of you thinking like, okay, yeah, yeah, it looks pretty, but what actually is different? You know, why is this better than the like 20 other coding agents uh here? And I think the best way to convey this is I'm not going to try to convince you that it's better. I think that is ultimately up to you trying different things out and seeing what actually works. But I am going to try to convince you that we're thinking about things in a very different, opinionated, and weird manner. So I want to take you on the journey of us building AMP and all the different sort of contrarian or spicy takes that we've made uh decision-wise in the architecture of of the agent along the way. Okay, so let's start at the beginning. Um hello agent. What is an agent at its core? Well, all an agent is as I'm sure most of you know uh is it's a for loop uh with tool calls and a model uh in the middle. And the reason I want to present this slide is because think of it this way really tells you what sort of levers you have to pull as a builder of agent. Uh there there's certain things that you can change. You can change the choice of model. You can change the tool descriptions and you can change uh how the model iterates with those tools and those are effectively your levers. Seems like a few amount of levers but you know just like programming languages all those are syntactic sugar around if statements and for loops. You know you can get a surprisingly wide variance of behaviors and complexity out of that. And so one of the key lovers in building any agent is the set of tools. And these days you cannot talk about tools without talking about MCP. So one of the early decisions we had to make in building AMP is how much do we invest in the MCP integrations? And MCP is this amazing new protocol that's gotten everyone and their mom thinking about how to provide context to agents. Um should we lean into that or should we start building our own custom tool set? And our very opinionated take, I think this is maybe, you know, less controversial now than it was, you know, back in in April, was that we should really actually focus most of our attention on the core uh set of tools within AMP. And that's really for two reasons. One is because the more you work with agents, the more you find uh out that what you're trying to do is identify these feedback loops and help the agent close them. And in order to do that, you need a refined tool set that is really geared toward helping the agent find those loops. And you cannot do that with MCP servers. The creator of the MCP server doesn't know what your agent is trying to do. And so they're not going to tune the tool descriptions to what you're trying to accomplish. And then the second piece of this is context confusion. So the more tools that you add into the context window, uh the more things that the agent has to choose from. And if the tools aren't relevant to the task at hand, it ends up getting confused. So we've leaned hard into this uh custom tool set. And you'll see a little bit more about that in just a little bit. But before that, I wanted to call out another issue with uh tool users, which is it's not just tool descriptions that eat up context. It's the tool calls themselves that also eat up context. And so, everyone who's built an agent has run into a context exhaustion problem where, you know, if you use any sort of coding agent, if it's good, it's going to go out and try to find a bunch of relevant context by grepping and reading files first. And by the time it gets to editing, there's only a small amount of context window left. And so, maybe it has to stop prematurely. And so the naive way to fix this is just to prompt it to, you know, do less reads so you can do more iterations on the edit side. But then this leads to another failure mode which I call the doom loop mode which is it doesn't gather enough context in the beginning and so it ends up not figuring out what it needs to do and just retries the same thing over and over again. And so the way to solve this is really with uh sub aents. So sub agents are the analog to subutine calls in regular programming languages. This is how you can factor out the context window used for a subtask into a separate context window which is the sub agents context window. Uh it can do all the things it needs and then at the end of the day it only returns the relevant results to the main uh agent window. So sub agents are effectively a way to conserve and extend the context window of your main agent. Uh so sub aents sub agents are great. I think everyone uh building agents has probably heard of or or use sub agents uh so far. But I think we have a unique take on sub agents, which is we're not really doing generic sub uh sub aents where you kind of tweak the system prompt and tweak the tool set a little bit. We've really leaned into our sub aents. Uh and so we have uh three to four really core sub aents that really extend the functionality and capability uh of AMP itself. The first one is something that we call the finder. This is effectively our codebase uh search sub aent. It's gone through an evolution of models and we've ended up at the point now where we're using a relatively small and quick model to drive a limited tool set that we found really is optimal for quickly discovering uh relevant context within the codebase. Another sub aent that we've implemented is the thing that we call the oracle. So this is how AMP does reasoning. So in contrast to most agents which uh you know implement reasoning in the model selection part of the experience, we found the best way to implement reasoning models is really through a sub agent. What that allows you to do is preserve the relative like snappiness uh in the main agent as well as its ability to to use a variety of different tools and then only when you need to debug a tricky problem or plan something very nuance, it drops into this Oracle sub agent and figures things out. And this is something that's like kind of magical. It's like anytime the main agent has trouble uh figuring out something and I'm like I don't want to spend like one to two hours going down this rabbit hole, I just like tag the oracles like invoke the oracle, think really hard, I go like alt tab, check my email for a bit and sometimes it takes a few minutes because it's thinking really deeply, but I think like four or out of five times it just magically finds uh uh the underlying issue. We also have a librarian sub agent which is meant to fetch context beyond the codebase. So from libraries and frameworks that you depend on. And then there's a new experimental sub aent that we call the Kraken. Uh its job is it doesn't edit code files uh one by one. Uh it really is all about writing code mods to do these kind of like large scale refactors. So we're leaning hard into the sub agents and uh that's really in contrast to a lot of the existing coding agents. I think almost every other coding agent implements a model selector as one of the core uh UX components and we just don't think that this is the architecture of the future. I get that, you know, developers like choice or at least the the possibility of choice. But the problem with choice is that there's also a paradox of choice. The more choices that you have, the more uh kind of like cognitive burden it is to choose from these different models. And that means at the architectural level, if you have n different models and one agent harness that you can only lightly customize each model, it means you're never really optimizing for what any one given model uh can do. And so AMP's architecture is much more agent-oriented. We have two top level agents, a smart agent and a rush agent. And the smart agent is the one that has access to all those fancy sub aents and can do a lot of things. It's it's a little bit slower, but you can hand it more complex instructions. And then the rush agent is for uh those kind of like in the loop tasks where you want to be tight in the loop and you're making quick targeted uh edits to to the code. And why do we have two top agents? It's really we're trying to kind of like pick points along the frontier of intelligence and speed that are meaningful to the user experience. So in in talking to our users, we found that there's kind of two modalities for invoking agents. Now one is you kind of like spin off a task and have it run and then review the code when it's finished asynchronously. Uh or you want to be in the loop, you know, quickly having the agent make edits while you quickly review them one by one. Kind of like babysitting the agent uh in the inner loop. And we're very intentional about the model choice here. We've only switched the smart model once and that was actually two days ago uh when Gemini 3 uh was released. And I think you know the the reaction Gemini 3 has been really interesting to watch. I think you'll see widely different behavior from Gemini 3 in different uh agent settings. So for those of you who've tried it out in other settings, I highly encourage you to uh try AMP. We did a lot of testing in the week before the release to optimize the smart agent to take full advantage of of its capabilities. And uh we're absolutely loving it. We're still working through some kinks obviously because it's a a new model, but we feel confident that it it's again moved the frontier of what's possible. Okay, so we talked a lot about like agent construction, the behavior. I want to talk a little bit about the UI layer of agents as well. So, you know, editor versus terminal, we're doing both. Um, and I think that's because both of them tackle kind of like different modalities of working. Uh, but we do have opinated takes uh in each interface. So, in the editor, I think of my editor now more as a reader uh uh more than anything else because uh I don't know like if you're using agents heavily, I don't think you're really editing all that much uh in your editor anymore. You're mainly driving edits through the agent panel, which is what you see on the right hand side or the right hand side here. And then what I do in in my editor is I pop over to the side panel, which is optimized for reviewing different diffs. So we actually built a custom diff viewer for the way that people are consuming agentic output. You can select any arbitrary commit range quickly view through the file level diffs. All the diffs are editable and you have full code navigation. So go to definition find references and there's a feature at the bottom that gives you a tour of the change. So it actually guides you through which files you should read first because I find half the battle when reviewing a large change is figuring out where to start. So the guey aspect of the editor allows us to build a very rich uh experience uh for for this type of thing. And then meanwhile in the terminal um we really want to take advantage full advantage of the the features and rendering capabilities of modern terminals. So uh we actually have one of the core contributors to Ghosty uh the open source uh terminal uh that built a uh a TUI framework from scratch to power the AMPU. So one of the nice things that we can do is just to point out a little detail the the green color of the diff rendering on the left hand side terminal that's actually we can have the terminal mix in the color green with whatever background color it's using. So that allows for a much nicer display. At the same time we know that people use all sorts of terminals uh including like terminals in Jet Brains or VS Code and other editors. And so we've added the ability to gracefully degrade. So even if you're using AMP in like the default Mac OS terminal, it falls back to the capabilities that uh are uh available in in that setting. Another aspect about how we're thinking about coding agents is really from the how do we get people to learn this new craft? Like we think that uh human developers are going to be around for a long long time, but we essentially have to relearn the craft of how to code uh together. And so one of the first features that we built in AMP was the ability to share threads with your teammates. So, if you're using AMP on your team, you can go and see like how much code people are changing with AMP over a given period of time. And you can poke into specific threads to see how they're doing things. And people love this feature because essentially like link threads to AMP and say like, "Hey, here's a cool prompting technique that I discovered. Try it like this." Or, "Hey, here it got stuck here. Can you help me, you know, uh think through how better to to connect the agent with the feedback loop to get further?" uh another aspect of of uh enabling more people to experience uh coding agents and learn how they work is by making it more accessible from an economic perspective. So um you know remember the smart and uh rush uh agents at the top level. You know smart models remain relatively expensive today but rush models are getting cheaper and cheaper but not yet free. And so we're thinking about you know more and more like one of the the biggest barriers to using agents fully is actually cost right now. Like if you go to like college campuses uh and talk to students, the actual number of people who have used a coding agent is actually much smaller than I would have thought given you know young people's uh propensity to adopt new technology. A lot of this cost. So someone had the crazy idea on our team like hey you know what we could do we could ship ads in your terminal. And at first it was like nah that'll never work. But the more and more we thought about it and the more and more like inference costs started declining we're like yeah maybe. So, we actually shipped uh a mini ad network that delivers ads for other developer tools uh in in AMP in the terminal and in the editor. Uh they're very subtle. So, I don't know if you can spot the ad in this screenshot, but we try to make them non-intrusive. But this effectively allows us to sponsor inference uh in in the Rush uh agent so that uh more people are able to experience this on you know their side projects and such. Okay. So, AMP is AMP. Uh we are like I said a we think of ourselves as like an agentic research lab. So we're not about uh hype. We don't do any sort of like paid developer influencer marketing. But I like to call out some cool people that I think are using AMP. Um because it it shows for the type of people that we're really selecting for. I I don't think AMP is for everyone uh at this point. We're really trying to target the the like small percentage of people who want to live a little bit in the future. Um, and so we have folks like Mitchell Hashimoto, the uh the founder and and excepting Ghosty now. Uh, that's his uh kind of passion project and he's using AMP to drive a lot of the changes that he makes uh to that terminal. And then we also have folks like Hamill Hussein who's I think probably like the leading authority on AI evals. Um, and at least as of a couple weeks ago uh he was saying that AMP was his favorite coding agent. And so, uh, neither of them are on the team or, you know, have invested us in any way, but we're just thrilled that, you know, they seem to like like what we're building. And then if other folks are interested in in kind of like coming along with us in in in this journey and trying to push the frontier of what agents can do, uh, we've also started a community of builders. Um, and using AMP is not a requirement to join this community. It's run by uh Ryan Carson whose former startup uh Treehouse taught over a million people to code and now this is his passion project. It's essentially like if you're building with agents and you're you're experimenting with how to push them further and further. There's Ryan right there. Um it it's all about kind of like tapping into that sense of awe and wonder with a peer group uh that is also uh leaning into that uh sense of of strangeness and and experimentation. So um what does this involve? It involves uh like regular interviews with people. We like to feature people who are building interesting things or using agents in interesting ways. Uh and we also do inerson events. We had a very nice dinner last night where we got a bunch of people together and had very interesting conversations spanning from you know actually building with coding agents to you know more philosophical discussions about uh the nature of AI and things like that. So um that's it for me. Uh hopefully this has in intrigued you. Again, I I don't expect all of you to be convinced that we are building the best Frontier coding agent, but at the very least, I hope I've kind of demonstrated how we're leaning into the weird and thinking about things uh differently. So, if that's interesting to you, come say hi at our booth. Just look for the weird pipe piper man riding the golden fish. Thank you. [music] >> [music] >> Heat.