A few people, a lot of agents

In February, on Barron’s Streetwise, I said I could imagine a team of five, maybe ten people soon building software very similar to what a team of 500 builds. I’d go further now. I think three or four engineers directing thousands of agents can build better software than a team of 500. I also think that only holds if the people keep the decisions. This post is mostly about the second half of that sentence, because it’s the half that tends to get dropped.

What the agents are for

Agents supply volume. They can read a whole codebase, draft a fix, write the tests, try three approaches and report back on all three, and do that for dozens of tasks at the same time. Work that used to be limited by how many hands you had is now limited by something else.

That something else is judgment. Somebody still has to decide what the product should be, which of the three approaches fits the system, what “done” means, and which shortcuts are fine and which ones will hurt later. Agents can offer an opinion on all of those. They can’t be accountable for them, and they don’t carry the history of why the team made the calls it made last year.

Why a small team can win

A team of 500 has a coordination problem before anyone writes a line of code. Intent gets diluted as it moves through planning, handoffs and meetings. By the time a decision reaches the person doing the work, it’s often a summary of a summary.

A team of three or four doesn’t have that problem. The people who hold the taste and the intent are the same people directing the work. When the agents bring something back, the person reviewing it knows exactly what was meant, because they meant it.

So the small team’s taste and intent filter through, and the agents supply the volume. That’s the whole bet. It isn’t that agents are smarter than 500 engineers. It’s that a few people with a clear idea and a lot of help can stay coherent in a way a large organization struggles to.

Where it goes wrong

The failure is easy to fall into: let the agents decide by default. Accept what comes back because there’s a lot of it and it looks fine. Merge the plausible change. Skip the question you would have asked a colleague.

When that happens, a small team with thousands of agents doesn’t build better software. It builds more software, faster, with nobody really steering. The work drifts toward whatever the agents find easiest, and the product ends up shaped by defaults instead of choices.

Keeping the decisions means a few concrete things to me:

• Agents propose, people decide. An agent’s job is to bring a short, clear choice to a person, with the real context attached. The person’s job is to make the call, not to stamp it.
• Decisions get written down, with who made them. An agent that runs into the same question next week should find the answer, and know whose answer it was.
• Some calls stay with people. Direction, spending, credentials, and anything that’s hard to undo.
• The system is auditable. If thousands of agents are working, you need to be able to see what they did, see why, and stop them.

What the people actually do

On a team like this, the engineers spend less time typing code and more time on the parts that were always the hard parts: deciding what to build, reading what came back, noticing when something is off, and saying no.

That’s still engineering. It might be more of it. Reading an agent’s change well takes the same knowledge as writing it, and choosing between three plausible designs takes more.

It also asks for a skill engineers don’t always get to practice: turning a pile of output into a decision someone can make. I wrote about that in Don’t be a meat proxy. Getting the agents to coordinate with each other, without taking the decisions away from the people, is its own problem; that’s Agent mail, and who gets the last word.

Why I care about this

The point isn’t to need fewer people. It’s that a small group with a clear idea can now build what used to take an organization, and build it well, as long as they stay in charge of it. I’d like more software to be made that way, and I’d like it to be better software, not more slop.

That’s the work I want to do: helping small teams run a lot of agents while the people keep the decisions. There’s more about me and how I work on the about page.