Stop Treating Agents Like Developers

I don't like being contrary. But I find myself drifting that way more often these days, and I suspect it's a symptom of my encroaching years.

Recently, I heard discussions about shifting left, a practice which involves moving testing, security, and quality checks earlier in the development cycle and closer to the developer so problems get caught and fixed where they're cheapest to address. Yet why are others talking about shift-left for agents? It makes no sense.

I was, and in many ways still am, a believer in shifting left. The logic was sound. Developer time is valuable. The further from the developer an issue gets raised, the longer it takes to fix. So you bring everything closer to the developer. You shift the tool chain left. That made total sense.

But that was about developers; agents are fundamentally different. Recognizing this difference is crucial for effective deployment strategies.

The Anthropomorphization Problem

Humans like to anthropomorphize everything. I don't know where it comes from, but I see it all the time in how people talk about agents. They treat agents like developers. They aren't. Really, they aren't. They aren't human, and they don't work as humans do.

Here's why that matters.

Developers have extensive access to pretty much everything. They need that access to do the job, and you extend them a huge amount of trust to go with it. The implicit bargain is that trust comes with responsibility. Developers are accountable for the trust allotted to them.

Agents are not. That's the stuff of CISO nightmares.

So the problem becomes: how do we give agents the kind of trust we give developers when they can't carry their half of the bargain?

A Million Agents in a Million Jail Cells

Stop thinking about agents as developers. Stop intermingling the two. Things get more interesting when you do.

Deploy your agents in highly siloed environments with clear hierarchies and defined handovers. This practice drastically reduces each agent's scope. You can build narrowly focused agents with narrowly defined authentication and authorization boundaries.

Run a million agents in a million jail cells. Abandon shift left. Embrace centralization of specialized services in nailed-down environments.

In a traditional development environment, this would kill productivity. Forcing a human developer to switch between multiple environments and jump through hoops to get anything done would create a hellish landscape that even the most grizzled enterprise developer would find hard to endure.

But agents don't have those hang-ups.

You can define a siloed agent-based development lifecycle. (Which is not the same thing as the agent development lifecycle. I know. Bear with me.) You can break the development cycle into tightly scoped units, with agents responsible for one unit at a time.

This practice mitigates a lot of the probabilistic behavior problems that come with non-deterministic systems. And it solves a large chunk of the trust issues we're currently wrestling with as we try to plug agents into developer environments.

Keep shift left for developers. For agent development, I'd push for the exact opposite. Agentic development works best in a highly defined, highly constrained environment. The sooner we stop designing around the fiction that agents are a new kind of developer, the sooner we can build systems that actually hold up.