Don’t distract the engineers #
In January, I wrote about how best-practices make software development agents work better. Now, six weeks later, we’re in a position where we’re not just talking about individual developers with a coding agent, but teams of developers with fleets of agents. So, it’s time to update my thinking.
If we accept that coding agents will continue to improve, allowing an individual developer to manage a fleet of agents who are each building entire software components or projects, we can imagine a few repercussions:
- These developers will be burning tens of thousands of dollars worth of tokens a day. We can imagine a world where companies simply can’t afford to have many developers. Even if they were volunteers, companies simply couldn’t afford giving paying for access to the coding agents.
- The developers attention becomes the bottleneck. Distracting a developer is like stopping the entire production line. They’re distracted from fleet-management tasks: queuing up the work, validating output, improving the production line.
- A team of “fleet developers” is then particularly expensive to disrupt. Every meeting, formal or informal, stops multiple production lines. Every core dependency breakage stops multiple lines. It’s like how a core system disrupting Amazon shopping or Azure can cost millions of dollars per minute.
In the future we might imagine the team is busy doing all the pre-work to load up the fleet queues with work, leaving a small handful of engineers keeping the line going. But for now, solo engineers are loading up their own fleet queues, keeping the fleets running, and improving the fleets–and human distraction is costly.
My team is building one of these frameworks (that gave me an existential crisis and I can tell you, the struggle is real.
Best-practices don’t matter #
In a previous post I talked about how using various best-practices while working with software coding agents resulted in better outcomes (linting, tests, in-line comments, intent documentation), it’s starting to be clearer to me there are a category of best-practices that don’t actually matter.
Working with teams who are managing fleets of agents is different than working with a team of human developers. Much of what we have learned as best-practices are really only there to manage human limitations to keep the team productive. Humans write buggy code, so we developed TDD. Humans get lost in code, so we developed design guidelines for coders. But many of them are no longer relevant when you work with agent fleets. Let me give some examples:
“Encapsulation”. It becomes hard to reason over code when you have to think of the entire code base at once. From the very early days of software engineering, we have created techniques to pack the code away into places where you won’t mess it up. Encapsulation treats entire sections of code like a “black box”. If you just use the public interfaces to the encapsulated code, you don’t need to worry about what is in it. This can be turtles all the way down… encapsulating encapsulated code into larger and larger modules and packages. Encapsulating the right code requires thinking hard. Some engineers encapsulate in an evolutionary way, just creating it as the project needs it. Other engineers like thinking through the abstractions up front, creating the capsule and then filling it in. Engineers fight each other over the “right” way to do this.
Similarly “clear abstractions, light-weight implementations” is another mantra that has served us well. It’s one more design step above encapsulation that tries to keep the encapsulation grounded on the overall system design. When you get a good abstraction, the code falls into place like magic. Engineers suffer under bad abstractions. It’s like fighting your way through a thicket to get some fresh air. Engineers will bleed for their idea of the best abstraction it often sets the dynamics of an entire effort.
“Simple systems, no simpler” encompasses a whole bunch of practices around YAGNI (you ain’t gonna need it), DRY (do not repeat yourself), “the best code is no code”, and on and on. Engineers learn over decades of building systems that “complexity kills”. It’s why the first weeks of a project produce faster than at any point later. After a few months, or a few years, the same product development teams on the same product seem to hit a wall. The system has become too complex (incidentally). This is “technical debt”. The complexity account is full. The fight for simplicity needs to be waged from day one. Investment in refactoring needs to be made consistently as new features are added. The effort for simplicity creates a class of battle-hardened devs that defend the systems from chaos, like knights fighting off dragons.
There’s probably no greater issue that drives dev teams apart than the fight over syntax and code documentation. Should we mandate a documentation framework, or treat our code like poetry, or fly free. “Self-documenting code!” one will scream; “document intent!” retorts another. The best we could do in most cases is just try to stay consistent with whatever already exists in a code base, like adding some strokes to another person’s painting and trying to keep it cohesive.
The thing is, agents don’t really need much of this. They don’t have the problem of being able to only keep 3-7 items in their working memory. They don’t take hours to re-establish their “mental stack” after a disruption. They don’t get confused by unfamiliar syntax. They don’t take days to “learn a code base”. So, if you’re working with a fleet of agents, you don’t really need to concern yourself with any of this (for the most part). And if you’re working with a team of devs using fleets of agents, you also don’t need to concern yourself with this (for the most part).
A month of technical debt can be cleaned out with a single prompt. An abstraction can be revised throughout the code base in minutes of tokens. The entire project becomes the “black box” for an agent.
So what? #
Now, if you tie the first and second principles above (“distraction is expensive”, and “best-practices don’t matter”) we can see one important way that working with teams who use agent fleets for making products breaks precedent for experienced developers. The hard-learned lessons for keeping product development on track, the lessons that gave you and better products, and battle-scars, and promotions, might just be the same lessons that, in the fleet environment, burn literal “man-years” (we won’t need that term anymore) of development productivity.
It’s been a hard lesson for me. And in this moment, it makes me feel like decades of experience that have made me valued on teams is now irrelevant. But, I also believe if we stay flexible, and adapt to the situation, we’ll soon find these skills haven’t actually disappeared; they’ve just been relocated. We’ll find that design sensitivity will help us apply the old lessons to our new context. After all, systems are systems and they all work better or worse depending on how you build them. The battle for simplicity (Cynefin) will continue to show up in unexpected places and it will be those who know how to think about it, from a haggard, embodied place, that will fight hardest for new solutions.