Mentoring the Machine — Eric Hou, Augment Code

Channel: aiDotEngineer

Published at: 2025-07-24

YouTube video id: Zniw5c9_jx8

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

[Music]
My name is Eric, member of technical
staff at Augment Code and today's talk
is about mentoring the machine. Uh now
the talk today is a personal story uh a
glimpse into how we at augment use AI to
build production grade software and how
that's changed how we operate both as a
team and as a business.
So at Augment we build for real software
engineering at scale in production.
Before Augment, I spent six years
building products and standards for the
automotive industry. And my peers and I
have created and maintained systems that
tens of thousands of engineer engineers
have touched where not one person fully
understands even how 5% of the system
works. So we kind of understand the get
your hands dirty kind of work we as
engineers have to do sometimes.
Now that's why we have all the line
items that you would expect but are kind
of shockingly rare in today's vibecoded
world. Uh if you wanted to learn more uh
please come visit our booth or visit us
at augmentcode.com.
Now let me walk you through our journey
which is broken into four sections. The
first two go through my personal journey
as an engineer at augment and how I as
well as other engineers learn to use
agents most effectively. And the second
two discuss the gaps that most
organizations and even our own face when
trying to adopt Agentic AI and how we
can address those gaps to solve both our
current problems and unlock new
opportunities in our businesses.
So without further ado, let's dive into
my own journey to realization which
actually happened a few months ago as we
were first rolling out the augment
agent.
So picture this. It's Tuesday morning.
Uh for me it's about to be one of those
days. You're all probably going to
recognize this day. In fact, most of you
have probably lived it many times. But
at the moment, for me, just another
Tuesday. Now, it's 9:00 a.m. I'm behind
on a critical design system component
that was supposed to merge last Friday.
The design team's waiting. Downstream
teams are waiting. I'm feeling the
pressure, but I'm determined to knock it
out. So, clear calendar, cup of coffee
in hand, and my fingers are just hitting
the keyboard. 9:30 a.m. My phone buzzes.
Staging emergency. Uh the main API
endpoint is completely broken. There's a
request format mismatch between our
client and server. Uh blocking all QA
testing and blocking deployments. So the
primary is on vacation at this point.
I'm the service secondary and I'm
responsible for the on call process and
seeing that through. So my carefully
planned day just evaporated like that.
10:15 I'm starting to wrap up some
service log exploration and the new hire
engineer that I'm mentoring slacks me.
Hey, when you have a minute, can you
help me understand how our extension
system works? I'm stuck.
Now, if you've been an engineer before,
we you know, you've been here. That
sinking feeling when your day derails.
You're pulled in three different
directions. You go home feeling like
you've accomplished nothing even though
you've worked for 12 hours. And you know
that when you wake up the next morning,
the on call remediation is going to put
another week or two of work on your
plate. And if that scenario felt
familiar, you're not alone. This is not
just your team, not just your company or
bad luck. Every single interruption
costs us 23 minutes of recovery time.
And as an industry, we're spending 23 of
our time maintaining code instead of
building new features. That translates
to $300 billion annually spent on
context switching and firefighting. So,
we've normalized this chaos and we've
accepted that days like this are just
part of being an engineer. Of course,
this is an AI, you know, conference. So,
what if I told you it didn't need to be
that way? In fact, what if I told you it
already isn't? I'm going to show you
exactly how.
So, let's see if I can bring this over.
Uh, this is our product, the Augment
Extension. It's got everything you like
in your favorite AI coding assistants
and more. But today we're Oh, today
we're focusing on the agent. Uh now,
uh here what we have is uh I want the
agent to take on a personality. I want
it to go ahead and talk to me about uh
you know the AI World Fair, the energy
and excitement uh of San Francisco. And
I'm going to go ahead give it this
prompt. And here are some guidelines
that I'm going to give it. Uh, if you
notice what these guidelines are,
they're not telling it exactly what to
implement. They're really drawing the
boundaries for the agent itself. So, I'm
going to go ahead press run and let it
run in the background. And we're going
to in the meantime go back to the talk.
So, this seemingly simple example of
working with the agent has kind of
fundamentally transformed how we work.
Uh, and a few months ago, it transformed
what should have been a terrible day for
me.
So, to see this in action, let's take a
look at my Tuesday a little bit more in
depth. What actually happened and how
this approach exemplifies the changes
we've taken at Augment to integrate the
growing capabilities of agents into our
team. So, it's Tuesday morning, 9:00
a.m. Before I grab my coffee, I start
scoping out the design system component
with an agent. And instead of
micromanaging, what I'm doing is I'm
scaffolding and providing context. I'm
giving AI the outcomes, the context,
constraints, and I'd have it perform the
same tasks I'd expect of any other
engineer. And so, while AI goes and
explores the codebase and builds the
RFC, I'm taking my morning coffee break.
And when I return, it has a mostly
completed RFC that follows our
architectural patterns. At 9:30 a.m., my
phone buzzes. The staging emergency is
on my plate and instead of dropping
everything for six to eight hours of
firefighting, I parallelize my
parallelize my work to parse through the
noise. And so I take the component, hand
it off to an agent, and it's working in
the background for me. Two AI agents are
working with me to help me parse through
logs and performing a git bisect. And
the augment slackbot helps me manage
communications with the teams that are,
you know, annoyed that they can't
deploy. So in this world, I'm not
fighting fires anymore. What I'm doing
is I'm orchestrating parallel AI work
streams while I get to focus on the
critical path of solving the on call
issue.
At 10:15, the new hire interrupts my on
call flow. And here, our knowledge
infrastructure really starts to kick in.
I direct the new hire to the augment
Slackbot, which has access to our
context engine, our codebase, all of our
documentation, linear, etc. Now the new
hire can have personalized realtime help
while I can stay focused on on call
response.
By 11, I'm evaluating agents work and
coordinating the next steps. The design
system component is complete. There's a
storybook link and my agents have found
the bad commit and already reverted it.
They've started writing up a postmortem
doc and already started exploring
remediation.
In this world, my role has shifted from
implementation to evaluation.
So now I get ready to manage the
deployment of the fix and the agents are
setting up off to tie up some loose
ends.
Now it's 12. Lunch food. Uh I go eat
while the agents are doing work for me.
After lunch, I complete what should have
been impossible. The augment agents have
executed the entire remediation process.
The problem was with a gRPC library
upgrade and it touched 12 services,
20,000 lines of code. It has tests. It
has a writeup. And actually one of my uh
engineering peers told me that uh it was
quite surprising and and really thanked
me for pushing this across the line uh
when really it was all the agents doing
the work. So here what a normal
organization might estimate as maybe
three weeks of engineering work to
upgrade the gRPC services is complete,
tested and you know almost ready for
deployment. But of course, it needs one
final round of human polish.
So the real transformation here is not
just that I've completed this work in
parallel. The real transformation is
that I've unlocked time that I
previously did not have.
Now that's not a dream. That's not a
pitch. This scenario that I just
described, all three of these challenges
was something that I personally had to
face and solved in around half a day of
active keyboard time. Same problems,
same complexity, same time pressure, but
instead of it being one of those days,
it became a normal Tuesday.
Now, what I just show kind of the crux
of how we at Augment work with agents
today by leveraging its unique strengths
while compensating for its weaknesses.
And that can be summed up in one core
realization.
To make the most use out of AI, we need
to work with it as we would work with
junior engineers. Not assigning tickets,
but mentoring.
Now, I know we we've all heard this.
We're all rolling our eyes a little bit.
You know, AI has the intelligence of a
junior engineer. Let's actually break
down uh how this analogy applies and
more importantly where it doesn't. Both
AI and new engineers start with no
context of your systems. They lack your
organizational context and most
importantly they lack years of
experience working with systems and your
systems. So they're able to implement in
isolation but they kind of need a
structured environment to work in to
perform best. These three pieces make up
what we call the context or knowledge
gap.
Now in learning and speed is kind of
where they differ really drastically. A
junior engineer learns and executes
fairly slowly, but they can retain and
synthesize knowledge while if given the
same information, AI can process it and
implement what you want in minutes or
even seconds, but forgets things between
conversations.
So for us, that means that AI is
effectively a perpetually junior
engineer, but one that can work on
multiple tasks simultaneously and
incredibly quickly. So to make the most
use out of AI, we must become perpetual
tech leads. We need to become mentors to
our AI apprentices just as we would
become mentors to our juniors.
Now you might be thinking this sounds
great for individual engineers. What
does this mean for teams my
organization? Uh and that's the right
question to ask and where a lot of
organizations struggle including
augment.
So we've seen this pattern repeatedly.
Individual engineers can achieve
remarkable productivity gains with AI
but when the teams try to scale progress
stalls.
Even when we first started working on
the Augment agent, actually I remember
people were saying, "Your agent is so
good. How can I get what Eric has. Now
this is kind of indicative of two bigger
problems.
How do we replicate individual success
with AI across teams? And how do we turn
team productivity into sustainable
business advantage? What's actually
blocking real organizations from using
AI effectively?"
This answer turns out to be fairly
simple. Remember the context of
knowledge gap we were just talking
about. This is not a new blocker. It's
the same problem that makes new hires
take 6 months to ramp up in your
standard or why four out of every five
engineers across our industry site
context deficit as the biggest blocker.
So the the core problem here is context.
And we've had this problem for decades
even without AI in the mix.
And so a paradox kind of arises in our
industry. How can we hope to solve the
knowledge infrastructure problem when
it's still this bad for human teams? And
how can we scale AI beyond an individual
when we don't have the requisite
knowledge infrastructure to do so?
This doesn't mean writing more docs.
This doesn't mean doing knowledge
reorgs. This doesn't mean you know
completely rebuilding your organization
for AI. In that world, humans are
serving AI, not the other way around.
It means kind of choosing the right
tools and systems that can
institutionalize knowledge
infrastructure for you.
So, here's how to get started. Companies
that you successfully use augment and
other AI tools tend to follow a fairly
similar pattern to get started, which
we've distilled into three steps. The
first step is knowledge gathering. Start
by exploring your existing knowledge
bases. What do you have documented? Map
out your key knowledge sources, Notion,
Google Docs, GitHub, etc. Fill in the
critical knowledge gaps specifically
around meetings and decisions with
meeting intelligence tools to capture
that knowledge that would otherwise be
lost.
In fact, actually most of the uh
meetings that I personally uh attend
outside of engineering nowadays start
and end with a granola AI recording and
uh comes with basically a list of tasks
that we can directly put into our task
tracker at the end of it.
Uh and finally, begin integrating data
sources using things like MCP and
augment native integrations to create
the beginnings of your knowledge
infrastructure.
Step two is starting to gain familiarity
with your tools. This refers to both you
gaining familiarity with the tools, but
also letting the tools gain familiarity
with you and your organization.
More broadly, introduce these tools
across your teams and enable them to
explore the strengths and weaknesses of
AI in your specific contexts.
This is where you build up the muscle of
working with AI and start teaching your
platform of choice about things like
coding patterns, architectural
decisions, business logic, etc.
Step three is leaning in. Expand the
successful patterns you've discovered.
And you can at this point start to
entrust more complex tasks as you've
built up trust and as your confidence in
these systems grow. Share your
successful memories and task lists
across teams. This is where compound
learning starts to really take off. When
people were asking me about the, you
know, how can I get Eric's agent? We
have a a feature called memories and I
basically just shared that file with
them.
This is where again compound learning
can take off and knowledge uh and
individual successes can start to
multiply and spread across your
organization.
So while us as engineers are working
with AI systems by providing missing
structure and guidance, successful
organizations as a whole are enabling AI
systems by institutionalizing their
knowledge infrastructure.
So now if these things are possible now,
how is that actually changed the way we
operate at augment? What future is
actually available to us? Let me bring
you back to the agent here and show you.
So I have a development environment up
here. So this is uh uh on the real
augment codebase. This is our a dev
version of our build. You can see in the
top that's the extension development
environment. And hopefully when I type
at I can okay personalities AI engineer
world fair Auggie. Awesome.
You can see it even created a little
icon. It's uh it's a little rough but
there it is. Uh what is your favorite
city?
Let's see what it says.
Awesome. There we go. Uh easy question.
It's absolutely hands down San
Francisco. I mean, are you kidding me?
The city is the epicenter of the AI
revolution. So, that's awesome. Uh, you
can see that, you know, as I was giving
this talk with just a simple prompt, we
were able to create a new personality.
This kind of exemplifies, uh, some of
the agent personality stuff, uh, that
was talked about earlier. Um but this
you know really starts to change when
you know if I can give a talk and also
implement a feature it really starts to
change how we think about the economics
of developing software.
See once we solve the knowledge
infrastructure problem everything starts
to change. When information transfer
becomes instant and scalable, we unlock
AI's true economic potential. Parallel
exploration of your business. The
traditional approach to building
software starts with designing then
building than testing. And each
iteration locks us out of potential
decisions at every single step. But when
knowledge infrastructure exists,
prototyping is cheap and building takes
fewer resources. We can do something
drastically different. Instead of
guessing at what might be the best
approach, we can rapidly prototype,
iterate, test, and then converge on a
real decision based on real metrics and
by putting our products in front of
people.
At Augment today, we have constantly
have prototypes floating around. We have
a prototype of a VS code fork in case we
need it. Uh, Augment itself became uh uh
or sorry, agents itself began as a
prototype as well. And many of the
features in our product that our users
love uh began as a prototype when an
engineer at augment just decided hey I'm
going to try this and with an agent and
by trying multiple approaches
simultaneously again we can quickly
converge with real data on the best
approaches that we should actually
invest in productionizing without
arguing you know in a room talking to
each other about what might be best.
As an engineer, we've all had to justify
a designi decision to leadership,
complained about tech debt, or cursed
our past selves for doing something in a
particular way. And as leadership, we
all wish we could go back and redo some
critical decisions or enable our teams
to do more strategic work instead of
constantly throwing fires at them to put
out. But with parallel exploration, we
can turn these wishes from retroactive
to proactive. By measuring and testing
divergent approaches from the start, we
can start making decisions better
informed by data. And when we can
measure hypotheses of designs,
prototypes, and architectures early on
and validate them, we reach a
fascinating conclusion.
If we use AI effectively to augment our
organizations, we can make the creation
of software more of a science, not less.
And that begins with all of our
engineers, organizations, teams choosing
the best tools for our jobs that most
effectively allow us to mentor our
machines.
Thank you all so much for your time. If
what we talked about today resonates
with you, please visit the augment booth
on the explo uh expo floor. Go to
augment.com, try us out for free. And
remote agents is out this week. Let it
parallelize your work for you. Thank you
so much.
[Music]