I stopped trying to out-review a robotic army

Mik Bry · 2026-07-21 · ~9 min read · AI

For years, a good chunk of my job looked like this: add a console.log, reload, stare at the output, and mutter something I wouldn't put in a client-facing blog post.

I loved that part. Debugging is detective work — you build a theory, run a small experiment, and watch confusion turn into an answer you can defend. My clients, understandably, loved it less. They were paying for a working feature, not for the hours I spent reconstructing what a program secretly believed about itself.

Then AI got good enough to write a lot of that code for me. Fewer hours staring at logs. Problem solved?

Not quite.

01 — When the machine stopped being the bottleneck

With a coding assistant, I describe a feature and get a plausible implementation in minutes. It never gets tired, never loses patience, never needs to go for a walk to untangle a stubborn function.

But the responsibility for what ships stayed exactly where it always was: on me. I still had to understand the architecture, catch the wrong assumption buried three files deep, check that a test actually proved something instead of just running, and be able to explain the result to whoever was paying for it.

The assistant could generate the next hundred lines before I'd finished making sense of the last hundred.

I hadn't removed the bottleneck. I'd relocated it — from typing code to reconstructing it in my head, one plausible-looking pull request at a time. And unlike me, whatever was producing those pull requests didn't need to sleep.

02 — I've seen this before — just not at this speed

There is also something strangely familiar about coding with AI.

The code does not feel like it came from another planet. Most of the time it looks like code I have seen before — the same patterns, shortcuts, abstractions, clever ideas and occasional bad assumptions I have seen from human developers for decades.

That makes sense. These systems learned from an enormous body of software written by people. Working with them often feels less like meeting a new species and more like working with an impossibly fast development team.

The difference is scale.

A developer can send me a pull request at the end of the afternoon. An agent can produce the equivalent of several of them while I am still thinking about the first one. Run several agents at once and the amount of plausible work arriving for review can exceed what one person can meaningfully absorb.

I recognise that feeling too.

During crunch periods, long before coding agents existed, a team could produce changes faster than anybody could properly review them. You ended up tired, context-switching constantly, approving things with less understanding than you wanted.

AI did not invent that failure mode. It removed the human speed limit from one side of it.

If you try to compensate by reading faster and watching everything, you eventually fry your brain.

The solution is the same lesson good engineering organisations learned before AI: structure the work so that human attention is spent where it changes the outcome.

03 — The bottleneck was never the typing

Here's the part that took me longer to admit than I'd like: the constraint was never how fast code got written. It was how much of my attention any given way of building spent — and how much it left over for the parts that actually needed a human. Every way of building software is really a bet about how much human attention it spends. The winner is whichever one spends the least on the routine, so there's more left for what matters.

Coding by hand spends attention on typing and recall. AI under constant human review spends it on re-reading someone — or something — else's output, fast enough that understanding never quite catches up. Neither is free. The useful question about any workflow isn't how fast it is. It's where the attention goes, and whether that's where you want it.

Today I run something that coordinates a handful of coding agents: it splits an objective into pieces of work, hands them out, requires tests and a separate agent review before anything merges, and keeps a record of what happened and why. An internal system, nothing you'd install — think of it less as a swarm and more as a foreman who never lets a shift end without a log of what was done.

The part that actually changed wasn't speed. It was what reaches me. Instead of reading every generated line, I see the objective, what passed and what failed, a separate agent review, anything that smells like an integration conflict, and the handful of decisions that touch money, architecture, or a customer's data. Everything routine gets checked by something that isn't a human running on fumes at 11pm. I stopped using my own attention as a polling loop.

Some of that work can run while I sleep, because a test suite is willing to check it for me. Some of it can't, because only my judgment can — and knowing which is which turned out to be most of the actual skill. In one recent run, an agent finished most of a tested implementation overnight. My active time the next morning went into confirming the target was still the right one and reading the evidence it had left behind, not re-reading every line it had written.

04 — Programming was never the whole job

The strange consequence is that I now spend less of my day programming — and more of it doing the other parts of the job that were always there.

Architecture. Understanding the product. Deciding what should be built. Reading unfamiliar systems. Learning a new technology quickly. Thinking about security and cost. Designing tests. Investigating production behaviour. Explaining trade-offs. Deciding whether a shortcut is harmless or will become expensive six months later.

None of those responsibilities appeared with AI. They were already most of what distinguished an experienced engineer from someone who could simply write code.

But there was a commercial problem: as a freelancer, programming was the thing I sold.

A client could understand "five days of development." They could understand a feature, a sprint, a day rate. Architecture, judgment, risk reduction and knowing what not to build were harder to put on an invoice.

AI is forcing that model to change.

If an agent can produce in an hour what used to take me a day to type, charging primarily for my ability to type the implementation makes less and less sense.

My value moves toward the things the faster implementation makes more important: deciding what deserves to be built, structuring the system around it, finding what the automation missed, and deciding whether the result deserves to be trusted.

05 — Verified by system, owned by a human

I used to think the real split was human-built versus AI-built. It isn't. I've seen AI-generated code better tested than something I wrote myself in a hurry, and I've seen "reviewed" pull requests rubber-stamped by someone as tired as I used to be at 11pm.

The distinction that actually holds up isn't human-built versus AI-built. It's what gets checked systematically and what doesn't. Verification doesn't mean a human reads every line. Routine checks can be automated and repeatable, as long as a named person still owns the decisions that are hard to undo: payments, access to customer data, and what gets deployed tonight.

06 — What I sell is changing

That is one of the reasons I started building the Trust Report.

It is not an attempt to sell code review by the hour. The automated system does the repetitive analysis. My work is increasingly about building the method around it: what should be checked, what evidence matters, which risks deserve escalation, and when a machine's answer needs human context.

In other words, the software does more of the programming. I increasingly sell the judgment around the software.

The system I use keeps more than the code. For any change, it can show me the decision trail across roughly the latest 200 commits — not the entire history since the beginning, just enough working memory to answer the question a client actually cares about. Not which function an agent touched. Why the change was necessary, what was checked, and what happens if it's wrong.

I can't out-type a robotic army, and I've stopped trying to out-review one by hand. What I can still do is decide the rules it works under, and keep enough of a paper trail to explain, to another human, why the result deserves to be trusted.