The Spectator Trap: Staying in Control of AI-Assisted Development

My feeds have filled up with a new genre of engineering content: a screen recording of an agent writing code, narrated by the person watching it. Twenty minutes of tokens streaming into an editor, an occasional "wow," an accept-all at the end. The energy is real and I share it — I hand meaningful work to agents every day, and this whole series exists because that changed how I engineer. But I want to name what that recording actually shows, as kindly as I can: it is not a productivity boost. It is spectating. The tokens stream fast enough to feel like progress, which makes it the most comfortable way ever invented to not be working.

The discomfort is worth examining, because the posture is new. A compiler never tempted anyone to watch it. Code generation today is fluent, legible, and narrated — it performs competence in real time — and so it invites an audience. Sitting in that audience feels like supervision. It is closer to abdication with the lights on.

This post closes a line of thinking I started in Engineering Before Inference — every AI call is an architectural decision — and continued in The Handoff Is the Unit of Design — delegation sized to the review you can afford. This one is about the posture underneath both: my perspective on what AI-assisted development looks like when it works, today, not in some projected future that keeps moving.

The control plane is the job

The mental model I keep returning to comes from the systems I build. Every serious network and every serious distributed system separates a control plane from a data plane: the data plane moves the packets, the control plane decides the routes. Nobody confuses the two, and nobody staffs the control plane with people who watch packets go by.

Agents are a data plane for software change. They execute: they write the diff, run the tests, chase the compile errors. The developer is the control plane: deciding what should exist, in what order, under what constraints, and verifying that what came back is what the system needed. Watching an agent type is abandoning the control plane to go sit in the data plane's audience — the one place in the architecture where a human adds nothing.

The industry even named the audience mode honestly at first. When Andrej Karpathy coined vibe coding in February 2025, the tweet said to "forget that the code even exists" — and, in the same breath, that the mode was fine for throwaway weekend projects. That second half fell off as the phrase went viral. The first half became a workflow. By 2026 Karpathy himself was drawing the professional line elsewhere, talking about agentic engineering rather than vibes — the version where a human stays in the loop with intent. The coiner of the term moved on; the audience stayed seated.

What being in control looks like this year

My own answer has two halves, and neither of them is "type faster."

The first half is parallel, bounded delegation. I stopped handing agents features and started handing them tasks — small, explicitly scoped, with done-criteria — several at once when the tasks are independent. While one agent migrates a repository interface, another drafts the contract tests for an endpoint, and I am not watching either of them; I am preparing the next brief or reviewing the last result. The mechanics of sizing those handoffs are the whole subject of the previous post, so I will not rehash them here. The posture point is different: parallelism is what the control plane does with its time. A router does not follow one packet across the network. The moment I catch myself watching a single agent work, I have dropped from operator to spectator, and the queue of decisions that only I can make is growing behind me.

Being in control also means the diff never gets an accept-all. Every change is read before it lands — not because the agent is bad at writing code, but because acceptance is the one act that transfers ownership. The agent produced the change; merging it makes it mine.

The second half is where I think the real speed lives, and it gets far less airtime than code generation: research ahead of implementation, automated. Before any implementation handoff, I run a separate, cheaper kind of delegation — agents that investigate rather than write. What does this change touch? Which services consume this contract? What breaks downstream if this field changes semantics? What did the last three incidents in this area have in common? The output is a requirements-and-side-effects document I review in minutes, produced while I was doing something else. Mistakes get caught at the stage where they cost a paragraph edit instead of a rollback window.

This is, in my reading, exactly what the DORA research has been converging on. The 2025 State of AI-assisted Software Development report found AI acting primarily as an amplifier of whatever organizational system it lands in — strong foundations amplify, weak ones amplify too, in the wrong direction. The May 2026 follow-up on ROI is blunter: returns come from the surrounding system, not the tools, and adoption follows a J-curve whose dip is driven by a learning curve, downstream process adaptation, and what the report calls a verification tax — the review burden that generation-heavy workflows push onto humans. Their model even prices the failure mode: in a 500-engineer reference organization, a change-failure rate drifting from 5% to 6% costs an estimated $344,000 in instability. The report's framing for what to measure is the one I would put on a wall: not the code AI writes, but "the bottlenecks it clears." Front-loaded research clears my actual bottleneck — confidence in what a change will do — which is why it buys more speed than watching code appear ever could.

The last time nobody read the code

Here is the part I most want to call out, because the industry has run this experiment before.

In December 2021, Log4Shell landed. One logging library, one vulnerability — and Google's analysis of Maven Central found 35,863 artifacts affected, more than 8% of the entire ecosystem. The detail that matters for this post is not the count; it is the shape. Only around 7,000 of those artifacts depended on log4j directly. For more than 80% of them the vulnerability sat deeper than one level down the dependency tree — for the majority, five levels down; for some, nine. The same analysis estimated ecosystem-wide remediation would take "likely years," and years is what it took.

Log4Shell was not a story about one bug. It was the moment the industry discovered, all at once and under attack, how much running code nobody had ever read or even knew they were shipping. The lesson was institutionalized: SBOMs, dependency scanning, provenance, an entire supply-chain security practice built to answer one question — what is actually running in production, and does anyone understand it?

Now look at the spectator workflow with that question in mind. Code generated in bulk, skimmed at best, accepted because the tests are green and the demo works, by a developer who could not explain the error-handling strategy in the diff they just merged. That is the log4j blindness being rebuilt one accept-all at a time — with one difference that makes it worse. Transitive dependencies were at least someone's understood code; the maintainer knew it, even when the consumer did not. Unread generated code has no maintainer anywhere in the chain who understands it. The industry spent a decade building tooling to answer "what is running?" for code other people wrote. It would be a remarkable own goal to make that question unanswerable for code shipped under a developer's own name.

I am not predicting a specific incident, and the parallel is structural, not literal. But when the next systemic scramble comes, the teams that answer fast will be the ones where a human can still explain every consequential change — and the difference between those teams and the others is being decided now, one review at a time.

What the conscious handoff costs — and buys

Staying in the control plane is not free, and pretending otherwise would undercut the argument. So, the trade named honestly.

It costs per-task latency: a handoff with a written brief, a plan review, and a read diff will always lose a race against an accept-all on a single task. It caps parallelism: my concurrency limit is not how many agents I can spawn but how many results I can genuinely verify — review capacity, not generation capacity, is the scarce resource, which is precisely the verification tax DORA describes. And it costs discipline that tooling does not enforce: nothing in any coding agent today stops a tired engineer from skimming.

What it buys compounds. Speed that survives contact with production, because side effects were mapped before the change existed. Debuggability, because someone understands what shipped, and incident response starts from knowledge instead of archaeology. Skills that are still there in five years, exercised on every review instead of atrophying in the audience. And a delivery rate that holds as the system grows, instead of the throughput-up-stability-down bargain that unreviewed volume tends to strike.

The checklist I actually hold myself to, kept short enough to survive real weeks:

• Research first: before an implementation handoff, an agent has already mapped requirements, impact, and side effects — and I have read that map.
• Small handoffs, in parallel, each with explicit scope and done-criteria; concurrency capped by what I can review, not by what I can spawn.
• No accept-all, ever. Every merged diff has been read by the person whose name is on the merge.
• If I catch myself watching tokens stream, I stop and do control-plane work: the next brief, the last review, the architecture note.
• The 3 a.m. test: if this change pages someone tonight, can I explain what it does and why? If not, it does not merge.

AI made developers faster. The spectator posture spends that speed on comfort; the operator posture invests it in control. Same tools, same models, same year — the difference is only which seat you take.