Building Self-Coding Agents

[on hold music] Hi, everyone.

Thanks for coming today. So I wanna talk to you about something that sounds like science fiction, but very much is reality. An AI coding agent that helped build itself.

My name's Colin. I'm an AI researcher at Augment Code, a company building AI-powered dev tools for software engineering orgs, and I wanna share with you a little bit about my-- our journey working on AI coding agents.

So zooming out, AI dev tools is a fast-changing space. Everyone remembers in twenty twenty-three, we were all talking about autocomplete models, GitHub Copilot being the one that probably really comes to mind.

In twenty twenty-four, chat models really started to penetrate software engineering orgs.

In twenty twenty-five, though, we think AI agents are gonna dominate the conversation about h- how software engineering is changing.

So naturally, a few months ago, we started building our own agent at Augment. I wanna show you a sneak peek of what we built and share some hard-learned lessons about how this tech works.

And I just wanna, you know, reiterate, I've been really amazed to see the extent to which this agent has helped build itself. Uh, on the kind of fun statistic, so we have about twenty thousand lines of code in our, uh, agent code base, and over ninety percent of that was written by our agent with, with human supervision.

So what does it mean for the agent to write itself? Implementing core features, so one of the first things we ha- we had to add was third-party integration. So our agent, you know, if it's gonna work like a software engineer, it needs to interact with Slack, Linear, Jira, Notion, search Google, um, muck around in your code base.

And so we wanted to have the agent help us build these features. Uh, we had it-- uh, we found after we added the first few ourselves, when we a-asked it to, you know, give it an instruction, like add a Google Search integration, it was able to go look in our code base for the right file to add

it in, uh, figure out the right interface to use, and go add it. Uh, one kind of fun an-anecdote is when we were adding the Linear integration, uh, it didn't know the Linear API docs.

The foundation model we're using, uh, didn't have those memorized. And so it used the Google Search integration, which it had written previously, to go look up the Linear API docs, and then was able to add that.

Uh, we used it to write tests. So we found if we a-asked it something like, "Add unit tests for the Google Search integration," it was able to go add those.

Uh, in order to do this, we just had to give it some basic process management tools, things like running a subprocess, interacting with it, uh, not hanging if there's an infinite loop in some test it wrote, and, uh, reading output.

Um, I think this is super interesting, so everyone's seen the Twitter demos of these agents writing features and writing tests, but I haven't yet seen a compelling example of them performing some kind of optimization.

Well, over the course of our project, we no-noticed the agent was pretty slow, and we weren't sure why. So we asked it to profile itself, and what it ended up doing, using all these tools we'd given it, was add some print statements to its own code base, run essentially subcopies of itself, look through these print statements, and

it figured out there was a part of our code base where we were loading up all the files in the user's repository, uh, synchronously and hashing them synchronously. And then it added a process pool for these to speed it up and a stress test to confirm it was all working.

And by the end of this, we reached about twenty thousand lines of code, and again, over ninety percent of that was written by the agent with, with our help and supervision.

So let's walk through a quick examples-- a, a couple quick examples to see how the agent works. I focus on simple examples where it's reliable, so you can, uh, follow along easily.

So here I ask the agent, "Are you able to search Google?" And then it notes that it found a tool called Google Search. For those who aren't familiar with the notion of tools, I'm, I'm sure most of you are, but I'll just kinda quickly reiterate.

The idea is we have this kinda master-level agent that's doing all the planning, and it has access to certain tools that it can use to interact with its, its environment, whether that's the third-party integrations I talked about, like Google, or it's editing a file in the user's repository.

And then it wants to confirm this-- that this Google Search tool is working, so it sends a query to it of tests. And the agent, uh, uh, responds to us, "Yes, I can search Google, and I see the first ten results."

Let's try something a little bit more complicated. I ask it, "Instrument agent's Google Search tool with logs, and then generate an example." Then it uses our retrieval tool, which is, you know, al-allows you to search, uh, the local, uh, code base, and it's looking for a file related to Google Search integrations.

It finds this file deep in our directory hierarchy at services/integrations/thirdparty/google_search_tool.py. And then it calls its file editing tool to quickly and performantly edit that file to add those print statements.

Uh, this is a continuation of the last example. So it added those print statements, and now it wants to run, uh, a subcopy of itself, so it can look at the output of those print statements, uh, 'cause we asked it for example logs.

Uh, but in doing so, it finds that we don't have Google, uh, credentials authorized, so it uses its clarify tool to ask for clarification from the user. It asks, "I don't see Google credentials.

Would you like me to, one, add stub for Google API, or two, guide you through setting up credentials?" I know that the credentials are actually stored in .augment/googleapi.json. It, it had just missed this.

And then here's a, a really cool extra feature we have, which is we want the agent to continuously learn as it interacts with humans.

And so here it thought, well, it's probably a good idea to remember where the Google credentials are stored. So it called this memory tool to create a memory of the-- where, where the Google credentials are stored to save that for later.

This is another example of if you have that really good context engine, uh, it- it's really critical to getting the agent to, to work well. And so now we get our output.

So it prints out these logs that it searched with an example string, Python programming language, and it gives some, uh, uh, example URLs that were returned by Google, python.org, and wikipedia.org.

So we had the agent add logs to itself, run itself, learn from user feedback, and it used all kinds of tools: Google Search, codebase retrieval, file editing, clarification from the user, and, and memorizing, uh, useful learnings.

So let's fast-forward and talk through some of our lessons building this. Uh, I just wanna note, you know, we've been working on AI coding tools for a couple years now, and we didn't set out to build agents.

We've worked on things like completion models and chat and so forth, but our focus the whole time was around building a super powerful, scalable, enterprise-ready context engine because we knew no matter what, no matter how good these LLMs get, you're going to need that context.

And we also thought a lot about how do you build great UI/UX so AI can seamlessly, um, interoperate with humans. It turns out this context engine and all these thoughts around design provided a great foundation for us to quickly build this agent in just a couple months.

The three most important things were that access to context, so that context engine with all those different types of context sources, whether it's Slack or the codebase, the reasoning capabilities from a best-in-class, uh, foundation model, and that code execution environment, so you can safely run, uh, commands in a, a customer's, uh, environment.

So let's talk through a couple assumptions that we frequently fall into-- we, we have frequently fallen into and remedied and, and some of you might encounter as well.

Uh, so the first one is that, you know, L5 agents are here. The senior soft-- agents are at senior software engineering level. Uh, if you look at the Twitter demos, it, it oftentimes can seem like this.

You have an agent write an entire website all on its own.

In reality, professional software engineering is where-- rarely zero to one, and the environments that we're coding in are, are a lot messier than what those demos, uh, show you.

As a result, these tools, you know, aren't quite there yet, but they're still super useful.

Um, the way pe-- One framework I've seen people think through when they're trying to figure out, you know, how to use these agents and how to build them is they think agents will take over entire categories of tasks.

So first you build an agent that will, uh, solve back-end programming, and then you build an agent focused on front-end, and maybe one focused on testing. In reality, this technology is very general purpose.

And so instead of thinking about categories of tasks, we found it more helpful to think through levels of complexity. So our agent's, you know, kinda good, decently good at tasks across front-end, back-end, security, and so forth, and, and we're, we're improving the capability level along all those fronts at once 'cause, you know, again, it's a very general

purpose technology. Um, we've also seen people anthropomorphize agents, so they think they're just like human software engineers, and they map the characteristics of a weak software engineer to what they think a weak agent would look like and vice versa for strengths as well.

In reality, agents have different strengths and weaknesses than humans, and so you may have an agent that can't do math, but it can implement a whole front-end feature way faster than any human could, and it's important that we keep this in mind.

Uh, let's talk through a couple reflections and lessons.

Uh, so here I ask Augment, "Can you create a stack of two PRs for the new reasoning module using Graphite?" Unfortunately-- Uh, so Graphite is a, a version control tool for working with Git.

You can, like, stack PRs. It makes it a lot easier to review. Unfortunately, foundation models have not memorized how Graphite works, so our general agent responds, "I don't know what Graphite is, so I'll use Git," and then it calls our terminal tool to run a command running Git checkout.

Well, what do we do here? We wanted it to use Graphite. We can't necessarily go tell OpenAI or Anthropic to retrain the model to understand Graphite overnight. So what we came up with was this notion of a knowledge base, which is essentially a set of, a, a, a, a sort-- a set of information that we want the

agent to understand that it currently doesn't. We can kinda patch holes. Um, one thing we wanted to add to it was this Graphite knowledge, so we created this markdown file describing Graphite, how to, you know, run common commands, things like how to create a PR, use gt create, some things not to do.

Um, we created other files in our knowledge base for things like details on our tool stack, how to run tests, the style guide. And then we added this into the context for the agent, so it can dynamically go search in this, um, knowledge base when it doesn't understand something.

And, uh, once we added this, then, you know, we go ask it, "Can you create a stack of two PRs for the new reasoning module using Graphite?" And it calls that knowledge graph, reads about Graphite, and then can run the gt create command.

So what's the learning here? Well, onboarding the agent to your organization is crucial. The analogy I like to think about is if you just hired a, a new, a new hire software engineer, you wouldn't go tell them to just stare at the codebase for three days to figure out how your tech stack works.

You'd let them ask you questions. Maybe there's some things they didn't understand, and you add some additional documents to your notion. Uh, we should think similarly about agents.

Uh, recall I was talking about how we had all these, uh, third-party integrations we added, whether it's Linear tools or Slack tools and so forth. But when we, when we were working on these, we weren't really sure of which ones to prioritize and start with on our product roadmap.

In a normal world, we'd make some educated guesses, we'd implement a couple of them and go from there. But with the agents, we were able to iterate them, um, uh, build them all at once.

And so this starts to change the calculus around how product management works. Uh, if you can build everything at once, well then, maybe, um, maybe, uh, engineering hours aren't the bottleneck on what we build, and it starts to, uh, we start to be bottlenecked a little bit more on good product insights and good design.

So when code is cheap, you know, you can explore more ideas.

Uh, also recall earlier, we were talking through this example of, you know, instrumenting the agent's Google Search tool with logs, uh, and it was able to go find the file to edit.

Notice here how we didn't have to give a very precise instruction to the model. We just told it in natural language, like how we'd talk to another engineer to instrument the agent's Google Search tool, and it was able to go figure out the file to edit.

This only worked because we had that really good, uh, code-based awareness.

Um, we can also use the agent for tasks outside of writing code, but still within the software development life cycle. So here, we asked it to look at the latest PRs, uh, in our code base and generate an an- an announcement on them, and then we posted it to Slack.

And so, uh, it was titled New Tools for this, uh, CLI Agent, and we talked about some things around Slack notifications and linear re- uh, linear integrations. This only works as we had that Slack integration and, and understood our code base well.

This, uh, figure may look familiar from the beginning of the talk. Um, we actually had the agent make this as well. So we asked it, "Make me a plot of the interactive agent's line of code as a function of the date."

Um, and so good context is critical. In all three of these tasks, we needed to pull in some different context from some different sources, and it's not just the code base.

Context comes in many forms. And also note that it's multiplicative, so having access to the code base and having access to Slack is four X as useful as just having access to one of those.

Finally, I wanna, uh, switch over and talk about, uh, testing.

So, uh, here's a really, uh, hard-to-test edge case in our code. The agent actually wrote this, um, and we only caught it because of some unexpected runtime behavior. So we have these caches that the agents store relevant information for their runs in.

Uh, we can run multiple agents in parallel, and they all write to the same cache location. And the agent wrote this save function to save to that location. And it had this lock around the JSON dump, so there were no race conditions that would explicitly fail if you had multiple agents all writing to this cache at the

same time. But notice here how there's no read before writing to the cache, and as a result, you could hit a race condition where if multiple agents are running in parallel, they're all overwriting each other's caches.

And when the agent wrote this save function, why did it miss this issue? Well, these agents sometimes make mistakes, and this is a hard-to-test situation. There's some parallel programming.

There's a cache involved. And so we didn't have a test, and because we didn't have a test, the agent messed up. My learning here is we need to be very careful about having sufficient tests.

Um, we have this pretty incredible statistic. So we have a internal bug fixit- bug-fixing benchmark. Uh, we found when we upgraded our foundation model by about six months, our scores from this benchmark improved by 4%.

But when we added, uh, the, uh, ability to run tests so the agent could suggest a fix for the bugs, run tests, look at the feedback, suggest another fix, run tests, and do that four times, that led to a 20% gain on this benchmark.

So what's the lesson? Well, better tests enable more autonomy. You can trust these agents more, and it just makes them smarter.

What does software engineering look like in a world of agents? Well, agents didn't work last year, but now are pretty good. If you'd asked me two years ago if we'd be working on this tech, I frankly wouldn't have guessed it.

There's a compounding effect where these agents are starting, starting to help build themselves, and that's only going to accelerate the pace at which they improve. Code isn't going away because it's a spec of our systems, but our relationships to it is changing.

Good test harnesses are becoming more important than ever, and we need to be es- especially careful about those parts of our code bases that tend to be less well-tested.

And the calculus of product development is changing. If code becomes super cheap to write, then the focus-- our focus is more on good product work, gathering customer feedback quickly, building insights.

We're really excited for how this tech's going to positively transform our industry, and we'll be releasing our agent soon, so I'm really excited to share that with you. Uh, find me after the talk if you wanna discuss any more.

Thanks. [upbeat music]