Idea for Agents in Larger Codebases
Happy Friday,
I don't want to be an AI influencer or anything like that, but ignoring its impact would be ridiculous.
I want to share some ideas I had that are untested about how you might put AI agents to work in larger code bases.
If you'd like to pilot this with me, reply back.
My free webinar is coming up on the 21st called "Lies Our Engineering Metrics Tell Us." Spread the word and sign up!
Esther Derby and I are offering a private workshop to leadership teams to show them how to use data to inform their decisions. Because we'll work with one team at a time, we can focus on the real issues and data and not just the classroom concept. Learn more here.
Domain Agent
Ok, so many companies organize their teams by component, where you have a front-end team, a back-end team, or a database team, and so on. These correspond to larger "components" in a system. This means work gets split up across the teams and then integrated.
There are numerous issues that come up with this, but the real question is, if AI is that much faster, do those issues matter?
So, you start with an orchestration/architect agent. Its job is to oversee the other agents and enforce standards. That agent begins by analyzing the codebase and interviewing the user as to critical paths, nuance, hotspots, etc. The architect agent builds out documentation about its findings.
Then, for each major domain component, you build a domain-specific or component-specific agent. Constructing this agent takes the information the architect produced, as well as any additional interview questions. The domain agent digs further into their area to develop a specialized context and documents it.
Why do this? A major element of success for using AI and agents is how much context they have and can keep. Busting a context window is a bit like your agent having a stroke, so we want to avoid it, and agents get their own context. So smaller specialized agents fill up their context slower and run out slower.
With all of these agents in place, a user brings a feature in and works with the architect. The architect uses their ability to break work down and then coordinates its delivery across all of the domain agents. It keeps an eye on the overall SDLC process and makes sure the agents adhere to their instructions. Work is done when the feature is complete and verified.
Pair Agents
One of the problems with component teams is that it causes integration issues. A useful formula for component teams is "n+2". This means that the actual work is the number of component teams (n) plus two more. The other two are to get it to actually work and to get it to work the way it was supposed to.
Again, though, if it's fast and cheap enough, this may not be a problem.
So, what would be a way to avoid the n+2 issue? Pair agents. This is based on pair-programming, which people love to scoff at, but is a very effective technique.
We have an architect/orchestration agent as always.
But then we create a navigator agent and a driver agent. The navigator will work to come up with the design and scan the code for where to work. It guides the driver by working one step ahead. It fills its context with the codebase and design.
The driver agent focuses on execution and writing the code well, correctly, and in a way that meets standards. It will take stock of the code it is working in and make suggestions, but leave the overall guidance to the navigation agent.
This pair's existence ends with the feature being complete, hopefully before its context pops.
Got multiple features? Send out multiple pairs. The orchestrator exists to manage these things.
Just an Idea
These are just ideas that I've come up with after my own experimenting on smaller codebases and how I might attack a much larger (1 million+ LOC) system.
Again, if you're interested in talking through these ideas or piloting them, reply back.
Oh, and here's a beekeeping video!
Here's my weekly update for May 15th, 2026…
🎥 Installing Buckfast Queens While Getting Attacked!
Beekeeping isn't always sunshine and calm flights, especially when the temperature drops into the 60s.
In this video, I am heading out to the apiary to install my new Buckfast queens, but the resident bees are not making it easy!
Since most of the foragers are stuck inside due to the weather, the hives are extra defensive and ready to protect their home….
Enjoy,
Ryan Latta