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

Channel: aiDotEngineer

Published at: 2025-12-22

YouTube video id: gvIAkmZUEZY

Source: https://www.youtube.com/watch?v=gvIAkmZUEZY

[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.