The Agent Is Not Your Coworker

AI agents can research, write code, run tests, operate infrastructure, coordinate sub-agents, and automate increasingly complex workflows. That does not make them coworkers. The useful distinction is between giving an AI more capability and giving it more authority. I want tools that amplify human judgment, architecture, and intent rather than replace them with an autonomous approximation of the same.

There is a strange linguistic shift happening around AI development tools.

We increasingly talk about agents as coworkers. They are given identities. They are assigned tasks. They spin up other agents. They coordinate work. They report progress. They are described as teammates, employees, assistants, or increasingly autonomous participants in the development process.

I understand why. The tools are becoming remarkably capable. They can read a codebase, find a problem, implement a fix, write tests, inspect infrastructure, query databases, operate command-line tools, search documentation, and continue working through a surprisingly complicated sequence of tasks. They can take an environment that would otherwise require several tools, terminals, browser tabs, notes, and a fair amount of human coordination and turn it into something much more manageable.

That is useful. What I disagree with is the leap from useful and capable to coworker.

Those are not the same thing.

Capability Is Not Agency

A power tool can dramatically expand what a person is capable of doing without becoming another carpenter. Software has always done this. Compilers automate enormous amounts of work.

Databases organize and retrieve information at scales no human could manually manage. Build systems coordinate complicated dependency graphs. CI systems run tests, produce artifacts, and enforce release requirements.

None of these systems need to become organizational actors for them to be extraordinarily valuable. AI changes the magnitude of the capability, but I do not think it changes the basic relationship.

An agent can be capable of performing a task without being the entity that should decide why that task matters, how it fits into the architecture, or what should happen next. Those are different responsibilities.

I Still Want the Human in the Middle

My preferred model of AI-assisted development looks something like this:

Human
  ↓
Idea
  ↓
Architecture
  ↓
Plan
  ↓
Constraints
  ↓
AI-assisted execution
  ↓
Review
  ↓
Iteration

The AI may do a tremendous amount of work inside that process. It may even manage several sub-agents of its own. One agent might investigate an API while another reviews database behavior and another runs a test suite.

That is fine.

The important part is that all of them are operating inside an intentional system created by a person. The developer establishes the mission. The agents manage workloads inside it. The system enforces the boundaries. That is very different from handing an agent a broad environment and saying:

There are circumstances where that might be useful. It is not how I want to build software.

The Magic-Wand Problem

There is an increasingly attractive product pitch around AI:

Tell it what you want and walk away.

The system will plan the work, decompose it, assign agents, write the software, test it, deploy it, monitor it, repair it, and continue improving it. It sounds wonderful. It also quietly removes the part of software development I consider most important. The hard part of building software was never typing the syntax. It was understanding what ought to exist. It was deciding where boundaries belong.

It was discovering that two apparently unrelated problems are actually the same problem. It was knowing when an abstraction is useful and when it is simply hiding complexity. It was understanding the business, the users, the infrastructure, the failure modes, and the consequences of a decision six months later. It was taste. It was judgment. It was architecture. AI can participate in all of those conversations.

It can challenge assumptions, expose blind spots, research alternatives, and accelerate implementation. But removing the human from that loop does not automatically improve the system. Sometimes it simply removes the person who understood why the system was being built in the first place.

I Want Agents in a Box

That probably sounds more restrictive than I intend it to be. The box can be enormous.

An agent might be allowed to:

• read an entire project
• edit thousands of files
• run builds and tests
• query development databases
• inspect infrastructure
• use cloud APIs
• coordinate sub-agents
• execute deployment procedures
• work through a multi-hour implementation plan

That is a very powerful box. But it is still a box.

Its scope exists because someone deliberately established it. Its capabilities exist because someone deliberately granted them. Its authority ends somewhere understandable. That distinction matters more as the tools become more capable, not less.

Automation Without Surrender

There is also a difference between autonomy and unattended execution.

I am perfectly comfortable defining something like:

1. Inspect these repositories.
2. Identify dependency updates.
3. Apply safe patch updates.
4. Build each project.
5. Run the tests.
6. Spawn additional agents where useful.
7. Stop if a major upgrade is required.
8. Stop if tests fail.
9. Ask before touching production.

Then I may walk away. That system could operate for an hour without human intervention. I would still consider it human-led. The human established the objective, architecture, scope, constraints, and stop conditions.

The system was autonomous inside an explicitly delegated envelope. That is very different from giving the system permission to redefine the envelope while it works.

The distinction I keep coming back to is simple:

Tools Should Make Experts More Capable

There is another reason I care about this distinction. A lot of AI product design seems focused on reducing the amount of expertise required to operate a system. That is a legitimate goal.

But there is another equally interesting question:

What happens when an experienced engineer can explore five architectural options in the time it previously took to explore one?

What happens when a systems architect can keep several repositories, environments, databases, and infrastructure layers in context simultaneously?

What happens when a developer can delegate implementation work while continuing to reason about the larger system?

What happens when mechanical work becomes cheap without making judgment cheap?

That is the version of AI-assisted development that interests me. Not replacing expertise. Leveraging it.

The Agent Does Not Need to Be the Center

A development environment does not have to revolve around an agent. The persistent thing can be the project. The persistent thing can be the architecture.

The persistent thing can be the team's knowledge, operational history, policies, connections, decisions, and tooling. Agents can come and go. One model may be better at research. Another may be better at implementation. Another may be cheaper or faster. Another may not exist six months from now. The project should survive all of them.

That suggests a different hierarchy:

Human intent
    ↓
Project
    ↓
Knowledge + Memory
    ↓
Architecture + Policy
    ↓
Capabilities
    ↓
Agents
    ↓
Execution

The agent becomes an exceptionally capable participant in execution rather than the organizing principle of the entire environment. I think that distinction will matter increasingly as models become more powerful.

More Power Should Require Better Boundaries

There is a temptation to respond to more capable AI by simply giving it more access. If an agent can operate a terminal, give it the terminal. If it can deploy software, give it cloud credentials. If it can query a database, give it the password. If it can coordinate other agents, let it decide what they should do. I would rather move in the opposite direction. As capability increases, the surrounding system should become better at expressing intent and authority.

An agent should be able to request:

deploy-production

without necessarily possessing the SSH key used to perform the deployment.

It should be able to use:

bitbucket-production

without knowing the password stored behind that connection. It should be able to delegate database investigation to a sub-agent without granting that sub-agent permission to modify the schema. More capability does not require less control. Good architecture can give us both.

The Human Is Still Doing the Creative Work

Software development is often described as an engineering discipline, and of course it is. I have always thought there is quite a bit of art in it too. You start with something that does not exist. There is a vague shape in your head. You explore it. You discard parts. You discover better abstractions. You realize something you designed yesterday was wrong. You notice patterns that were not obvious when you started. Eventually the thing becomes coherent. AI is proving to be an extraordinary material to work with during that process. It can dramatically accelerate the translation from idea to implementation. But I do not want the material deciding what I should make. I want better tools for making it.

There is a very large difference between:

and:

Both approaches will produce software. I suspect they will produce very different kinds of software. And for now, at least, I know which side of that line I want to work on.