From pair programmer to executive

I didn’t even hear about the bug until after it was fixed.

A Researcher agent found a problem and reported it to a Software Director agent. The director recorded the problem, assigned coding agents to work on separate parts of it in parallel, reviewed what they returned, rejected work that did not meet its requirements, combined the accepted changes, and delivered the result back to the Researcher. The Researcher checked whether the original problem had actually been solved and, when the fix fell short, sent it back around the loop.

I had defined those roles. Early on, I sometimes told one agent to consult another. But I was no longer copying every message, tracking every coding session, or personally moving the work through every handoff. The agents had started collaborating through the responsibilities I gave them.

That’s the part I’m still trying to get my head around.

What surprised me wasn’t that an agent could write code. It was watching one piece of software supervise another.

Kanbus organized the work. It did not manage it

In Cybernetic Development, I described the move from pair programming with one coding agent to delegating work to several agents at once. That created an immediate management problem: the agents were fast, but every assignment, clarification, result, and next decision still passed through one human.

Kanbus gave that work a shared structure. It is the project-management system I use for software and editorial work. On the Kanbus board, each task, bug, user story, or other piece of work gets its own card. A person or agent can claim the work, record what happened, update its status, and leave evidence for whoever comes next. Unlike a conversation hidden in one tab, that shared record survives and can be read by everyone involved.

But Kanbus organized the work; it did not manage it.

It did not read the code and form an opinion. It did not decide that a test result was inadequate, reject a change because the documentation was missing, or determine which specialist should take the next step. Those decisions still belonged to me.

Once I had more than three or four agent conversations going at once, I started losing track. That is not a universal limit. It is an observation about my own attention, made worse by moving among Codex, Claude Code, Cursor, cloud agents, local agents, different computers, and whichever sessions happened to be pinned in each application. I was copying information between conversations and trying to remember which tab belonged to which project.

The answer was not a faster model. It was management.

Software can now supervise software

The Software Director is not merely accepting bug reports and turning them into cards. It is doing the work represented by the verbs in the first paragraph: assigning, tracking, reading, questioning, rejecting, combining, and reporting.

That distinction matters. Dispatch alone is a queue. Supervision includes judgment.

I explicitly instructed the Software Director to be hard on coding agents when it reviews their work, and it is. It can require test results, code coverage, documentation, security checks, and project-specific evidence before accepting a change. It works alongside automated systems such as CodeQL, Snyk, and Dependabot; it does not replace them. The difference is that a capable reviewing agent can interpret all of that evidence as part of a defined acceptance procedure and keep asking questions when something does not add up.

Smart coding agents can be remarkably good at catching problems in code written by other coding agents. In some circumstances, they can be more thorough than a human who is excited about the feature and wants to get it deployed. That is not because the human is obsolete. It is because the reviewing agent has one job, a written procedure, and no urge to declare victory at 5:30 on Friday.

The Researcher is not a ceremonial client, either. It has checked delivered work and sent it back for changes many times. The point is not to make an org chart that looks sophisticated. The point is to create a working cycle in which one role notices a problem, another role coordinates the fix, and the original requester checks whether the result solves the problem.

The org chart changes the work

This is the same number of coding agents arranged in two different ways:

Before: four direct agent conversations

After: one supervised software team

The coding agents didn’t suddenly get smarter in the second diagram. The difference is that I don’t have to sit inside every conversation.

The human still chooses what matters. The human defines the roles, the boundaries, and the acceptance requirements. The human remains responsible for the consequences. But the human no longer has to notice that a test suite finished, switch back to the correct tab, interpret the result, decide on the next iteration, and restart the work every time.

That delay sounds small, but it adds up fast. Some agent tasks take hours, but many return in a few minutes and larger ones often take 20 or 30 minutes, depending on the test suite. When I run the loop myself, completed work waits until I have attention available. The Software Director can make the next decision as soon as the evidence appears.

Here is the shape of the loop without any product names:

Right now, I’m doing this with Grok Bot and a local Software Director that coordinates Cursor sessions on my Mac. The director could run in the cloud; I prefer the local machine for reasons I discuss in those field notes. Grok Bot is a glimpse of this operating model, not its final form and not the only way it will work.

Two 2026 trends met here

For me, this operating model became practical because two changes arrived together.

First, coding agents became much better at long-running work. They can continue through tests, review, corrections, and another attempt instead of stopping after one code change and waiting for a human to push the button again. The Year the Coding Agents Went Remote covers the infrastructure shift that helped make this possible.

Second, high-quality coding became cheaper. In my own work, Composer 2.5 is inexpensive enough that I can keep a development farm working throughout the day and night without treating every model call as a budget decision. That is my current operating posture, not a promise about anyone else's plan or future pricing.

Neither change would have been enough on its own. Cheap agents that stop at every decision leave the human carrying every handoff. Long-running agents that are prohibitively expensive remain impressive demonstrations. Cheap, capable, long-running agents make a persistent software organization possible.

This is where Jevons Paradox appears. When a useful resource becomes cheaper, we often consume much more of it. One coding session becomes four. A task that was not worth starting becomes worth attempting. A reviewer rereads the workers' output. Total AI usage can rise precisely because each unit of usage became cheaper and useful in more places.

I call the resulting operating style "tokenmaxxing for fun and profit." By tokenmaxxing, I mean keeping many inexpensive agents productively occupied and optimizing for useful work completed rather than minimizing model usage. I wrote more about the economics in The Year Coding Became a Commodity and about the practical operating habit in Never Use Fast.

The scarce resource is increasingly human attention: deciding what deserves work, defining what good looks like, and examining the outcomes that matter.

This category is escaping the lab

Grok Bot isn’t the first attempt at an always-available personal agent. OpenClaw is the most vivid prior example: powerful, flexible, difficult, and willing to operate close to the edge of what many people would consider comfortable. Its own introduction says it runs on the user's machine and acts through chat applications, while acknowledging that prompt injection remains a security problem. That makes it useful prior art and a useful warning.

Now the major platforms are absorbing the idea. Microsoft describes Scout as an always-on system powered by OpenClaw, with governed access and human signoff. Google describes the next Gemini app, including Gemini Spark, as proactive and available around the clock.

These products aren’t all the same, and their existence doesn’t prove that any of them is safe or mature. They do show that persistent agents which act, coordinate, and return with results are becoming a product category rather than a hobbyist stunt.

A confidently wrong manager is still wrong

Of course, these agents aren’t actually employees.

Agents do not have tenure, ambitions, incentives, dissatisfaction, professional pride, or legal accountability. Calling an agent a Software Director doesn’t magically give it good judgment. The name only helps define its responsibilities, its tools, the evidence it must demand, and the limits on what it may do.

Grok Bot has enough agency to do something materially different from what I asked. It has worked in the wrong repository. It has encountered a blocker and found a workaround I did not approve. The exact capability that lets it keep a team moving also lets it amplify a bad decision without waiting for permission.

The risks compound through the hierarchy. A worker can return bad code. A manager can accept it. Summaries can distort information as they move between roles. A confident manager agent can direct several workers down the wrong path at once. The extra review consumes more AI usage, even when that usage is cheap. And there is no software equivalent of a human accountability chain when the result causes harm.

So I monitor new arrangements closely at first. I give the agents clear guardrails. I require durable evidence rather than trusting a conversational assurance. I keep consequential decisions and final accountability with a human. The goal is not autonomy at any cost; it is to spend human attention where judgment and responsibility actually matter.

Reporting lines are becoming system design

There is an old observation in software engineering called Conway's Law: the structure of a system tends to reflect the communication structure of the organization that built it.

With agent teams, that relationship becomes something we can design directly in software. Who assigns work to whom? Who can reject it? What evidence must travel with a result? Who checks whether the integrated change solved the original problem? Which decisions require a human?

Those sound like org-chart questions. Increasingly, they’re also engineering decisions.

Prompts still matter. Tools still matter. Models still matter. But once several agents can work for long periods at low cost, the performance of the whole system depends just as much on reporting lines, shared records, acceptance procedures, and feedback. A brilliant worker inside a confused organization can create confusion faster. A good organization can make capable, inexpensive workers surprisingly effective.

The one-person software company has acquired middle management. That sounds ridiculous. A few months ago it would have felt ridiculous to me.

Now I have watched that entire loop operate without me standing inside it—and watched it reject inadequate work before asking for my attention. I was still responsible for the system. I just was not standing inside every handoff.

That is the shift: not from human control to machine control, and not from one magical model to an even more magical model. It is a shift from operating individual agents to designing an organization of agents—and deciding exactly where the human belongs.