Stop worrying about duplicated agents

I skipped my high school senior year Algebra class 39 times. In my defense, it was right after lunch. My teacher, bless her heart, really tried and it’s not her fault I was not the least bit interested. I chuckle thinking about what she’d probably say if she saw my masters thesis…¹

What I recall from the bits of that class I did attend, though, was that we had homework. All of us were supposed to do it, even though all of us were doing the same assignment with the same questions. We also all took the same tests and quizzes. No one would ever suggest that our class would be more productive if only one person did the homework or took the tests.

I’m seeing hundreds of people go through a learning journey with AI coding. The way I see them navigating that process reminds me of learning math. You can’t learn multiplication before you learn addition. Addition, subtraction, multiplication, division, exponents, etc. Each builds on the concepts of the last.

Well-intended engineering leaders across the industry are asking if we can accelerate AI adoption by encouraging re-use of agents rather than having people write these prompts and workflows over and over. After all, why have two people build an agent that writes automated tests or ushers a PR through the release process?

I think we want them to do that because people can’t skip learning addition and go straight to running a completely autonomous AI driven software factory (called a “dark factory” in industry parlance). If we want folks to evolve their skills and become “parents” of agents, or forward deployed engineers, or agent stewards, or however you’re envisioning their roles, they need deep understanding of how these agents work. What kinds of context are important? How do you check on their work and what kinds of mistakes do they make? Only then can you hope to manage an orchestration system that automates those tasks.

But Lee, you think, if the dark factory works well then the operator won’t need to deal with any of that stuff. They should just be focused on the business value it produces!

It’s tempting to think of something like a dark factory like it’s a scifi movie prop. It’s the med bay you just get in and it fixes whatever is wrong with you. It’s the food materializer. The tricorder. Nobody knows how it works but somehow it never breaks.

I think of these factories more like a steam locomotive in the 1800’s. The aptly named engineer who drove it was qualified because they were learning how the engine worked when they were 15 years old. For years they shoveled coal into it, helped more experienced people fix the pipes, and they knew what every gauge meant. That gave them insight into the machine that allowed them to operate it in many contexts. They knew the pressure gauge was finicky when the train was going around a curve so they could feather the throttle a bit to compensate.

That’s a much more apt analogy to me for how these agent orchestration systems work when producing software today. Maybe in ten years we’ll be in Star Trek land, but woe be unto you if you try and skip learning your multiplication tables and act like you’re there today. You aren’t.

So in the meantime if you see engineers writing really similar agent prompts, that’s probably good evidence that they are progressing on their journeys. That they want to share these things is also probably evidence of a good engineering culture that wants to maximize re-use. The problem I think we want to solve here is in how we manage the lifecycle and promotion of prompts and workflow automation.

I say embrace the chaos and celebrate that lots of engineers are learning how these things work, and treat the agent prompts they are writing like you would a student’s math homework. It’s an output of the learning journey.