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

How's everyone doing today? Yeah, cool. Pretty cool conference, huh? Um, so yeah, my name is Beyang, 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 experienceright now, living in this weird world we're living in, where agents are writing an increasingly, uh, 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 try to strike in, in this UI is we try to show theright 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 bottomright-hand corner there, you'll see a little Emacs 30.1 thing that also connects to the editor that you're using, where it collects diagnostics.

So Emacs, Neovim, JetBrains, 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 ha add a little help button in the bottom left-hand 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, butright now, this installs into VS Code or any of its derivatives, Cursor, Windsurf, uh, Antigravity.

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 parallelizing, you know, 2, 3X, uh, the number of agents that I can run at, at, uh, a given time. So we built a, a review 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 and 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 thinking 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 levers 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 scriptions 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 use, 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 re-retries the same thing over and over again.

And so the way to solve this is really with, uh, subagents. So subagents are the analog to subroutine calls in regular programming languages. It's how you can factor out the context window used for a subtask into a separate context window, which is the subagent's 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 subagents are effectively a way to conserve and extend the context window of your main agent.

Uh, so subagents. Subagents are great. I think everyone, uh, building agents has probably heard of or, or used subagents, uh, so far. But I think we have a unique take on subagents, which is we're not really doing generic sub, uh, subagents where you kind of like tweak the system prompt and tweak the tool set a little bit.

We've really leaned into our subagents. Uh, and so we have, uh, three to four really core subagents 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 code base, uh, search subagent.

It's gone through, uh, 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 from the code base.

Another subagent 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, uh, is really through a subagent.

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 plant something very nuanced, it drops into this oracle subagent 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 oracle.

So I 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, uh, out of five times, it just magically finds, uh, uh, the, the underlying issue.

We also have a librarian subagent, which is meant to fetch context beyond the code base, so from libraries and frameworks that you depend on. And then there's a new experimental subagent 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 subagents. And, uh, that's really in contrast to a lot of the existing, uh, 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 in 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 subagents 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-level 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, 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 to 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 it in Amp. We did a lot of testing in the week before the release to optimize the, 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, uh, again, moved the frontier of what's possible. Okay, so we talked a lot about, like, agent construction and 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 opinionated takes, uh, in each interface. So in the editor, I think of my editor now more as a, a readitor, 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 theright-hand side or theright-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 just figuring out where to start.

So the GUI 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 Amp TUI. So one of the nice things that we can do is just to point out a, a little detail, uh, 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 JetBrains 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 macOS 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 in 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 just 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, 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 costright 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 ex-CEO of HashiCorp.

He's building 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, uh, folks like Hamal 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, who is a 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 Ryanright there.

Um, it, 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 in-person 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 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.