# Self Coding Agents

Colin Flaherty, Augment Code | AI Engineer Summit 2025 | 17:23

Source: https://www.youtube.com/watch?v=Iw_3cRf3lnM
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/self-coding-agents
Published: 2025-04-21
Tags: agents, coding-agents, context-engineering, testing, tool-use

## TL;DR
- Augment Code's agent wrote more than 90% of its roughly 20,000 lines of agent code under human supervision.
- The agent improved its own performance by profiling its code, finding synchronous file hashing, adding a process pool, and writing a stress test.
- Agents become more autonomous when they have strong context, safe code execution, organization-specific knowledge, and the ability to run tests and respond to feedback.

## Summary
Colin Flaherty describes how Augment Code built an AI coding agent that also helped build and improve its own codebase. The agent added integrations, wrote tests, profiled its performance, changed synchronous file hashing to use a process pool, and created a stress test. Flaherty argues that these systems are useful across many software tasks, but their abilities are uneven and they do not yet match senior engineers in messy production environments. The agent needs access to code, Slack, documentation, tools, and a safe execution environment. A knowledge base can fill gaps in what foundation models know about a company's tools and practices. Tests matter because they let the agent inspect failures and try fixes repeatedly. Flaherty says this changes product planning as implementation becomes cheaper. Teams may spend more time on product judgment, design, and customer feedback, while engineers supervise several agents working across the software lifecycle.

## Key ideas
### Augment's agent wrote most of its own code under supervision
[01:19](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=79s)
Augment Code's agent had reached about 20,000 lines of code, with over 90% written by the agent while humans supervised it. Flaherty gives third-party integrations as an early example. When asked to add Google search, the agent found the right file, identified the interface, and edited the code. While adding Linear support, the model did not know the Linear API, so it used the Google search integration it had already written to find the documentation. The agent also added unit tests when asked. Flaherty presents this as supervised implementation, rather than an agent working without people.

### The agent can use tools to inspect and improve its own implementation
[03:01](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=181s)
When Augment's agent seemed slow, the team asked it to profile itself. It added print statements, ran subprocesses containing copies of itself, inspected the resulting output, and found that repository files were being loaded and hashed synchronously. It then added a process pool and a stress test. The example depends on basic process-management tools, including starting subprocesses, reading their output, and preventing an infinite test loop from hanging. Flaherty uses this example to move beyond agents that only write features and tests. The agent changed its own architecture after investigating observed performance.

### A coding agent coordinates planning, retrieval, editing, execution, and memory
[03:58](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=238s)
Flaherty shows a workflow in which a master agent plans work and calls tools that interact with the environment. For a request to instrument the Google search tool, it searched the local codebase, found a deeply nested integration file, and edited it. It then ran a copy of itself to produce example logs. When credentials were missing, it asked the user for clarification. After the user explained where the credentials were stored, the agent saved that fact with a memory tool. The workflow combines Google search, codebase retrieval, file editing, clarification, and memory rather than relying on generation alone.

### Strong context and execution access made the agent possible
[06:55](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=415s)
Flaherty says Augment did not begin by trying to build an agent. The team had spent years building an enterprise context engine and thinking about how software should work with human users. That foundation helped them build the agent quickly. He names three requirements: access to many forms of context, strong reasoning from a foundation model, and a code execution environment that can safely run commands in a customer's environment. Context can come from a codebase, Slack, or other sources. Flaherty says these sources combine multiplicatively, so access to both the codebase and Slack can be much more useful than access to only one.

### Agents should be judged by task complexity, not human job categories
[07:53](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=473s)
Flaherty rejects the idea that teams should build separate agents for backend programming, frontend work, and testing. The technology is general purpose, so Augment instead works on increasing capability across different complexity levels and software areas. He also warns against treating agents as human engineers with the same strengths and weaknesses. An agent may be unable to do basic mathematics while implementing a complete frontend feature faster than a person. The agent's useful abilities do not map cleanly onto familiar human skill levels.

### Organization-specific knowledge fills gaps in foundation-model knowledge
[09:49](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=589s)
When asked to create stacked pull requests with Graphite, the agent did not know Graphite and fell back to Git. Augment could not retrain the foundation model immediately, so the team created a knowledge base with Markdown files. The files explained Graphite commands, the company's tool stack, test instructions, and its style guide. The agent could search this material when it encountered an unfamiliar concept, then use the correct command after reading the Graphite documentation. Flaherty compares this with onboarding a new software engineer, who needs explanations and documents instead of being left alone with the codebase.

### Cheaper implementation changes product planning and software work
[11:58](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=718s)
Because agents could build several integrations in parallel, Augment could explore product options without first choosing only a few based on guesses. Flaherty says this changes the bottleneck in product management. Engineering hours may matter less when implementation is cheap, while product insight and design matter more. The agent also handled work outside direct code writing, such as reviewing recent pull requests, generating an announcement, and posting it to Slack. These tasks still required integrations and enough codebase context to understand what had changed.

### Tests give agents a way to correct mistakes and work with more autonomy
[14:13](https://www.youtube.com/watch?v=Iw_3cRf3lnM&t=853s)
Flaherty describes a concurrency bug in a cache-writing function. The code used a lock around JSON writing, but it did not read the existing cache before writing. Multiple agents could therefore overwrite one another's caches. The issue was difficult to catch because it involved parallel execution and an under-tested edge case. In Augment's internal bug-fixing benchmark, upgrading the foundation model over about six months improved the score by 4%. Giving the agent a loop in which it proposed a fix, ran tests, inspected feedback, and tried again four times improved the score by 20%. Flaherty's conclusion is that better tests allow more agent autonomy.

## Notable quotes
- "Over 90% of that was written by our agent with human supervision." (01:19)
- "These agents make mistakes and this is a hard to test situation." (15:00)
- "Better tests enable more autonomy." (15:36)
- "Code isn't going away because it's a spec of our systems but our relationship to it is changing." (16:01)

## Tools & references mentioned
- Augment Code
- GitHub Copilot
- Slack
- Linear
- Jira
- Notion
- Google Search
- Graphite
- OpenAI
- Anthropic
- Cicero

## Who should watch
- You are building a coding agent and need concrete examples of tools, context sources, process control, and test loops.
- Your team wants to use agents in an existing production codebase rather than in clean demo projects.
- You are deciding how agent-assisted implementation could change testing, product planning, and engineering supervision.

## Related talks

- [Agentic Engineering: Working With AI, Not Just Using It](https://aietalks.com/talks/agentic-engineering-working-with-ai-not-just-using-it) (Brendan O'Leary, Kilo Code, 27:03)
- [The Emerging Skillset of Wielding Coding Agents](https://aietalks.com/talks/the-emerging-skillset-of-wielding-coding-agents) (Beyang Liu, Sourcegraph / Amp, 35:06)
- [Developer Experience in the Age of AI Coding Agents](https://aietalks.com/talks/developer-experience-in-the-age-of-ai-coding-agents) (Max Kanat-Alexander, Capital One, 18:20)
- [Beyond the Prototype: Using AI to Write High-Quality Code](https://aietalks.com/talks/beyond-the-prototype-using-ai-to-write-high-quality-code) (Josh Albrecht, Imbue, 17:59)
- [AI Engineer Code Summit 2025](https://aietalks.com/talks/ai-engineer-code-summit-2025) (Jed Borovik, Google & Swyx, AI Engineer & Barry Zhang & Mahesh Murag, Anthropic & Dex Horthy, HumanLayer & Lee Robinson & Naman Jain, Cursor & Jacob Kahn, Meta & Rhythm Garg & Linden Li, Applied Compute & Will Brown, Prime Intellect & Will Hang & Cathy Zhou, OpenAI & Kitze, Independent & Kath Korevec, Google Labs & Eno Reyes, Factory AI & Beyang Liu, Amp Code / Sourcegraph & Natalie Serrino, Gimlet Labs & Jake Nations, Netflix & Eiso Kant & Jason Warner, Poolside & Aparna Dhinakaran, Arize & Nik Pash, Cline & Joel Becker, METR & Kevin Hou, Google DeepMind & Benjamin Dupy & Leah McBride, AI Engineer, 8:57:06)