As an engineer, I’ve gone pretty ‘agent first’ this year. The setup is Herdr (the icon is a ram, we all get a flock) running on a server, which then hosts many projects, each with Pi ready to spin up tasks at a moment’s notice. My day begins by launching into this platform and starting on some features/changes/fixes (too often, just features). I can call out to my herd of ready agents, each with their own project space, from anywhere. This system is extremely convenient as far as contemporary AI workflows go, but has introduced an issue: overwhelm. The overwhelm stems from the velocity at which one can build and iterate on projects.
It goes a bit like this: start work on some project, setting off a task for it to be completed by an agent. While the agent does its work, switch contexts into another project, figure out some changes to do in there, then repeat as the agents spin away… The number of projects being worked on in a given moment is limited only by the speed at which the agents finish their changes. If agents are spinning on three workspaces, why not start up a fourth? And so on.
Yes, I can ‘ship’ a whole lot of work this way. Much of the work can be reasonably good, and looks better implemented than anything I would have built in a day or two. But a fair amount of it is actually quite poor, if I were to hold it to the standards of, say, a respected co-worker’s PR. Often, features or elements of code are duplicated instead of refactoring and expanding upon the general codebase architecture. At other times, code gets overwrought and over-engineered with dozens of extra tests and an edge-case obsession verging on ‘wild goose chase’ that make later changes more consumptive of time and energy. Often the plot gets lost in the name of preserving some legacy behaviour that was only a rough draft in the first place. At other times, a bunch of gobbledygook explanatory text gets dropped into the UI to explain what a button does (in the most opaque language possible). Often, after completing work, the agent commits everything to the main branch and calls it a day, contravening my carefully written AGENTS.md instructions about branching and PRs. Throughout, the context grows, both for myself and any future agent for whom ‘context management’ is a lot of the job in the first place.
I could go on, but the obvious comment at this point is ‘well, fix your prompts and AGENTS.md file and put a system of checks and balances in place to prevent this’. Another voice may chime in with ‘models will get better and stop having these issues’. A third may say ‘the quality of this code doesn’t even matter anymore, really’.
I heard someone on a podcast the other day say that AGI has been here for a year already, just in the software development world. I agree that these tools are unfathomably powerful and quick, and it’s unlikely that I’d ever create a codebase again without using them. However, the notion that coding is ‘solved’ and ‘easy’ and I can spend my time on other concerns hasn’t been true at all.
Paring down, minimizing, editing, guiding, dare I say ‘mentoring’ the agent, these are my daily activities as an engineer now. I think for some, the answer has been to really de-emphasize code quality and just ship fast until someone buys your thing. I don’t have a counter-argument to that, as maybe that’s how software has always been for people of a certain mindset (which I don’t share and probably never will). Solve problems now, worry about implementation details maybe never. This might be right. At this stage of my career, I can’t say I know. What I do know is that I am burning out in this ‘herding’ system and need to change it up to ensure I can remain a productive engineer (which, hey, I still want to be).
Trying to be a ‘general manager’ of a handful of contexts at once, all day, bouncing back and forth from issue to issue, is a special skill and part of the reason people pay CEOs a lot. I don’t particularly want to be a CEO, and I doubt that a world full of tools built by CEO-types with little care for engineering is where we want to live.
My plan for now is to slow down. Try to collect some thoughts and ideas together before rushing features into four projects at once in a coding ‘frenzy’ day after day. Maybe do a bit of human stuff like writing text, taking breaks, seeing faces and making plans. I might even wait a minute for an agent to finish their work, have a look at it, guide, massage and iterate. This is more or less how I worked before, switching between composition and the edit stage. Staying in the context of the work being done is what I’m missing. That context is where I want to do my engineering. A flock is nice to have, but chasing them in all directions is not the behaviour of an experienced shepherd.