My name is Eric, member of technical staff at Augment Code, and today's talk is about mentoring the machine. Now, the talk today is a personal story, 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 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 vibe-coded world. If you wanted to learn more, 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. 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 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. The main API endpoint is completely broken. There's a request format mismatch between our client and server, blocking all QA testing and blocking deployments. So the primary's 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 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, 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 two-thirds 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 So 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. 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 focusing on the agent. Now, here what we have is I want the agent to take on a personality.

I want it to go ahead and talk to me about, you know, the AI world fair, the energy and excitement 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. If you notice what these guidelines are, they're not telling you 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.

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 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 code base 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 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 Slack bot helps me manage steps through 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 Slack bot, which has access to our context engine, our code base, all of our documentation, linear, et cetera. Now the new hire can have personalized real-time help while I can stay focused on on-call response. By 11:00, 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 post-mortem 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:00, lunch, food. 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 the gRPC library upgrade, and it touched 12 services, 20,000 lines of code.

It has tests, it has a write-up, and actually, one of my engineering peers told me that it was quite surprising and really thanked me for pushing this across the line when, really, it was all the agents doing the work. So here, when 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 policy. 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 showed you is 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'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 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.

In 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 is almost great for individual engineers. What does this mean for teams, my organization? 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 can I 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. It's not a new blocker.

It's the same problem that makes new hires take six months to ramp up in your standard org, and why four out of every five engineers across our industry cite context deficit as the biggest blocker. So 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 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 meetings that I personally attend outside of engineering nowadays start and end with a granola AI recording, and it comes with basically a list of tasks that we can directly put into our task tracker at the end of it.

And finally, begin integrating data sources using things like MCP and augment native audit 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 how can I get Eric's agent, we have a feature called memories, and I basically just shared that file with them. This is where, again, compound learning can take off and knowledge 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 has 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 on the real Augment code base.

This is our 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 Augie. Awesome. You can see it even created a little icon. It's a little rough, but there it is.

What is your favorite city? Let's see what it says. Awesome. There we go. 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. 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 some of the agentic personality stuff that was talked about earlier. 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, then 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 constantly have prototypes floating around. We have a prototype of a VS Code fork in case we need it. Augments itself became -- or sorry, Agents itself began as a prototype as well. And many of the features in our product that our users love 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 design 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 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.