I Was the Bottleneck

Everyone in engineering is saying some version of the same thing right now: AI has moved the bottleneck. Writing code is no longer necessarily the slow part; deciding what to write is.

It’s true. It’s becoming consensus. And a lot of people saying it have never actually been the bottleneck.

I have.

I spent much of my career at Mercedes-Benz as one of the people the process flowed through: technical lead and architect for production cloud platforms, responsible end to end. I co-led multiple engineering teams across several external vendors. I ran refinement meetings. I approved technical changes. I was one of the human routers between delivery partners, product organizations, engineering teams and corporate approval structures.

When people write that handoffs and approval loops are the enemy of velocity, I don’t nod along in theory. I lived the timelines: features whose implementation was measured in days could spend weeks in alignment before anyone was allowed to start. The next opportunity to unblock them was often whenever the next meeting happened to be.

Here’s what nobody tells you about administering the constraint: it feels like diligence. Every meeting has a reason. Every approval catches something, occasionally. The overhead is almost invisible because it is load-bearing, until the thing it was balancing against disappears.

Last year, it disappeared on my desk.

Becoming the Constraint

Since the first serious coding-agent CLI tools appeared, I’ve been building with them heavily in my free time.

Not demos.

I built desktop applications I actually used. I built distributed tooling around agent workflows. And I built ZigQueen, a chess engine written from scratch with coding agents doing much of the implementation while I drove architecture, experiments, evaluation and release decisions.

ZigQueen is now independently rated at ~3570 Elo on the CCRL Blitz list: verified superhuman playing strength.

One detail from that project matters for everything that follows: my own internal strength measurements predicted the independent external result to within about 25 Elo. That matters more to me than the rating itself, because it meant the evaluation loop was calibrated. I wasn’t trusting generated code because it looked plausible; I was building a system that could tell me whether the output was actually improving.

Then I started running agents in teams: Claude, Codex and Gemini instances working on the same codebase concurrently, with different roles.

Within days, a familiar feeling arrived from an unfamiliar direction. Building the thing was now dramatically faster than deciding where the thing should go. Implementation was rarely the queue. UI decisions, architecture decisions, product-direction calls and reviews of what had just been built stacked up behind me. Agents could finish a feature faster than I could decide whether I actually wanted it.

My backlog was no longer code. It was direction.

My team worked at machine speed. I still worked at human speed. Every pattern I had administered at enterprise scale reappeared with me as its sole executor: the review gate, the clarification loop, the “let me get back to you.” The enterprise decision cycle had not vanished. It had compressed into one person sitting in front of terminal panes, being the delay.

I had spent years being the bottleneck by role.

Now I was the bottleneck by physics.

Most people who reach this point write a think-piece. I’m an engineer, so I did the other thing.

Engineering the Constraint Away

Over roughly eight weeks I built taurhaus, a desktop application for supervising multi-agent development: live session monitoring across projects, persistent agent teams, recovery, project history and a coordination layer I called Mesh. I built it, naturally, with the kind of team it manages.

What I actually learned was that almost every management problem I knew from human organizations came back as an engineering problem. This time it had to be made explicit, because agents do not paper over process gaps with goodwill.

Workers With Amnesia

Agents lose context. Compaction happens, sessions restart, and a process survives while the useful mental state does not. So context loss became an onboarding problem: taurhaus detects relevant lifecycle events, reconstructs a bounded operational snapshot of what the agent was doing and re-briefs it, with guards around freshness, membership and task state so stale context is not blindly injected.

Human organizations can survive fuzzy handovers because people compensate. Machine-speed teams force you to specify what a handover actually means.

Silent Stalls

A process can be alive while useful work has stopped. That sounds obvious, but once I had several agents running concurrently, “the process exists” became almost meaningless as a health signal. So worker health became explicit state: recent output, task progression, messaging, validation evidence and runtime state treated as separate signals. An agent producing text is not necessarily making progress.

That is the machine version of a management lesson most people already know: there is a difference between someone answering your message and the work actually moving. At machine speed, you have to encode that distinction.

Crashes and Turnover

A team member could not be the same thing as a process. Processes die, tmux panes disappear, daemons restart, model sessions are disposable. The role had to survive. So taurhaus separates durable team identity from volatile runtime attachment: an architect remains the architect even if the underlying session has to be recreated and reattached.

I did not invent the organizational pattern. I simply discovered that it remained load-bearing when the workers were software.

Job Descriptions Became Executable

Roles eventually became behavioral contracts. What does an architect do? What is an adversarial reviewer for? What does “done” mean? What is the escalation policy? These were no longer vague organizational expectations. They were configuration that directly affected system behavior.

I iterated role definitions in versions, experimented with different models in the same conceptual roles, and eventually built evaluation around the role definitions themselves. That was one of the stranger moments of the whole project: I had version control and tests for parts of my org chart.

One measurement stuck with me. A role definition written as narrative prose scored 71 percent on my benchmark when a different model held the role. Rewritten as explicit procedure, the same role scored 93. Role definitions, it turns out, interact measurably with who, or what, fills them.

Two years earlier I would have found that sentence ridiculous. Now I think it points at something important.

The Cost Function Changed

One architectural observation quietly changed how I thought about software decisions. At some point I wrote a principle near the top of the architecture documentation:

Cleanest solution wins: implementation effort is not the primary constraint.

Traditional engineering judgment contains a huge amount of implicit cost balancing. Do we build the proper abstraction or use the quick enum? Do we model the state machine properly or add another flag? Do we clean up the architecture now or tolerate the debt because implementation time is expensive? When the implementation delta collapses, some of those instincts stop making sense. If an agent can implement the cleaner version in roughly the same human-attention window as the shortcut, the trade-off changes.

Effort is not literally free, of course. Tokens cost money, compute costs money, review costs time. But the resource I ultimately ran out of was none of those.

It was my own attention.

Then I Stopped

One month into a long-planned career break, I shut the project down, not because it was failing, but because I had noticed something.

Being the sole decision engine for a machine-speed team may be one of the most concentrated forms of work I have experienced. It is certainly not rest.

When building becomes cheap, direction becomes what you spend. Every agent can continue if you answer one more question; every finished implementation creates another review, and every review creates another branch of possible work. Unlike a human team, the machines never become tired enough to create a natural stopping point for you. You can always push the system forward.

One more decision.

One more prompt.

One more review.

One more experiment.

Eventually I noticed that my tooling had removed almost every natural boundary between “working” and “not working.” That was not a productivity victory. It was a finding.

Direction fatigue is real.

Organizations planning AI-augmented engineering teams are budgeting for models, tokens, tooling and infrastructure. I am not convinced enough of them are budgeting for the decision stamina of the humans upstream. That was the resource my little laboratory exhausted first.

What I’d Tell an Engineering Organization

Everything above comes from one person and an unusually intense home lab, and skepticism about scale is fair. But the mechanisms were not hypothetical. The system ran and shipped releases. The agents worked concurrently; they lost context, stalled, recovered, disagreed, and created work faster than I could absorb it.

From that experience, there are four conclusions I would defend in an engineering leadership meeting.

1. Price Your Decision Latency

When implementation was slow, waiting several days for a decision could disappear inside a multi-week delivery cycle. When implementation takes hours, the same delay becomes the cycle time.

Most organizations measure engineering activity in extraordinary detail and decision latency barely at all. That increasingly looks backwards to me. If a feature can be implemented in an afternoon but spends the next week waiting for clarification, approval or prioritization, developer productivity is not your primary problem.

Measure the waiting. Measure the handoffs. Measure time-to-decision, and idea-to-production rather than just implementation throughput.

The constraint has moved.

2. Push Authority Toward the Work

The usual argument for decentralized authority is velocity. I think AI adds another one: human cognitive capacity. Every decision you centralize lands on someone whose judgment is a finite resource. A machine-speed organization with human-speed centralized decision-making does not create leverage. It creates an extremely expensive interrupt handler.

I have run the handoff-heavy version at enterprise scale, and I have run the zero-handoff version alone. Both broke, in opposite places.

The profile that becomes valuable is someone who combines enough technical depth, product context and decision authority to act without constantly handing work elsewhere. Governance does not go away; it gets redesigned around the new cost structure. Reversible local decisions should not require the same machinery as irreversible, externally visible or security-critical ones.

Authority should follow risk.

3. Trust Gates, Not Vibes

The most useful lesson from ZigQueen had almost nothing to do with chess: AI-generated output becomes trustworthy through measurement, not confidence. Nothing survived because the implementation sounded clever. Changes survived because they passed tests, benchmarks, consistency checks and repeated empirical evaluation.

Chess happens to give you unusually clean referees, and enterprise software does not. But the principle transfers: characterization tests, canary metrics, production telemetry, contract tests, security gates, independent recomputation, evaluation suites. If implementation volume rises dramatically, review based primarily on humans reading generated output cannot scale indefinitely, and the answer is stronger automated evidence rather than lower standards.

The point of evaluation is not to prove that the AI is smart. It is to give the humans the right to trust the system.

4. Your Organization Design Is Becoming Testable

This is the idea I find hardest to stop thinking about. In a human organization, changing roles, reporting structures and working agreements is slow, politically expensive and difficult to evaluate cleanly. Hybrid human/agent organizations are different. Agent roles are executable. So are escalation paths, review structures and decision policies. And executable things can be measured.

If changing a role definition or coordination rule produces a reproducible improvement in team output, you have done something very close to an organizational experiment. Human organizations are not about to become YAML files. But part of organizational design is moving into software, and software can be versioned, observed and evaluated.

I think we have barely started exploring what that means.

The Next Bottleneck Is Human Attention

My earlier view was simple: AI moves the bottleneck from implementation to requirements and decisions. I now think that is incomplete. Bottlenecks keep moving.

Accelerate implementation and requirements become the constraint. Improve requirements and review becomes the constraint. Automate review and security or release governance may become the constraint. Improve those and product judgment may become the constraint. Eventually you arrive somewhere uncomfortable: human attention itself.

You can parallelize execution much faster than you can parallelize one person’s judgment. Ten agents do not make one engineering leader ten times faster. They may simply create ten asynchronous sources of interruption.

That suggests a different design objective for AI-native development.

Not:

How many agents can we run?

But:

How much useful machine execution can one human sustainably direct?

That leads to very different systems: decisions batched instead of arriving as constant interruptions, explicit autonomy boundaries, escalation driven by confidence and impact, reversible decisions handled without asking. Work-in-progress limits sized to human review capacity rather than available compute, agents returning decision briefs instead of questions, repeated human choices hardened into policy, and a protected attention queue rather than another notification stream.

The human should not be “in the loop” for every action. Otherwise the human is the loop.

And eventually the loop saturates.

Where I Landed

The constraint has moved upstream. I have watched it arrive from both directions: from inside a large engineering organization where human coordination often determined delivery speed, and from a home lab where machine execution became fast enough that the constraint landed directly on me.

That changed the question I care about. I am no longer particularly interested in arguing about whether AI can write good enough code. It can write useful code. The interesting question is what happens after that becomes normal.

How do we design engineering teams when implementation is cheap? How do we make decisions fast without making them reckless? How do we build evaluation strong enough to absorb far more generated work? How do we protect the attention of the people whose judgment becomes increasingly leveraged? And how do we redesign organizations whose processes were created around a cost function that may no longer exist?

The organizations that win the next several years will not necessarily be the ones with access to the best model. They may be the ones that redesign the slow part: themselves.