The 10× Experiment

I have a confession that is slightly inconvenient for an engineer writing an AI blog: I do not entirely trust AI agents.

I have watched them miss obvious things, confidently solve a neighbouring problem, and produce code that looks respectable until somebody asks what happens on Tuesday when the database is slow and a user presses Back twice. So whenever an agent finishes a task, my first instinct is still to open the diff and inspect what the little bastard has done.

This is not an excellent foundation for delegation.

But it is an honest one, and it led our team to a more interesting question than “Which model is best?” We decided to run an experiment: can we redesign engineering work around AI strongly enough to multiply our delivery speed—not by twenty optimistic percent, but by several times, perhaps eventually ten—without quietly converting that acceleration into bugs, rework and operational pain?

In other words: can we make the whole system faster, not just the typing?

Ten agents are not a 10× engineer

The seduction is obvious. Open ten agent threads. Give each one a task. Look terribly futuristic while your laptop sounds like it is preparing for take-off.

It works—up to a point. One of us is already running roughly ten parallel agents and burning a weekly usage allowance in a day. Another has replaced Instagram Reels with watching agents work, which is either professional development or merely a more expensive addiction. The output is real: three or four times more work with roughly the same personal effort is not fantasy.

But parallelism is not created by opening windows. It is created by finding independent, well-bounded problems. If your entire job is one uncertain product flow, ten agents mostly give you ten conversations about the same uncertainty.

AI does not remove the bottleneck. It reveals what the bottleneck actually was.

Sometimes it is code. More often it is missing context, an unresolved product decision, an external system that cannot be tested, or a piece of architecture nobody has thought through. Once implementation becomes cheap, ambiguity becomes expensive.

The work moves left

The emerging workflow is almost comically inverted. Instead of spending an hour describing a task, three days coding and another day reviewing, we may spend much longer on the specification and let the implementation happen quickly.

A serious specification is not a heroic Jira paragraph. It forces decisions about the business outcome, data ownership, security, architecture, failure modes and test strategy. The agent should be able to say how it will prove its own work. If it cannot, the task is not ready—or the environment is missing something.

This is where “AI-native engineering” stops sounding like a vendor webinar and starts becoming uncomfortable. The skill is no longer producing code from a ticket. It is constructing a context in which producing the wrong code is difficult.

We are even experimenting with turning technical conversations into inputs: arrive with alternatives, argue through the unclear parts with another human, let the notetaker preserve the questions, and give that richer record to the agent. A meeting is useful when it resolves ambiguity. A meeting that merely reads status aloud remains what it has always been: calendar-shaped vandalism.

Make the world testable

One objection came up immediately: what about flows an agent physically cannot complete? Identity checks, signatures, third-party widgets, selfies, and all the other places where software eventually asks a human to stare into a camera and prove they are not three raccoons in a coat.

The answer is not to give up on end-to-end testing. It is to build a world the agent can operate: high-fidelity mocks around external boundaries, with the same API contract and a representative UI. Test those boundaries carefully against reality; then let agents exercise dozens of internal scenarios without asking a human to perform the same ritual ten times a day.

It will not be a metaphysically perfect end-to-end test. It can still deliver most of the confidence at a fraction of the recurring cost. The remaining sliver gets a smaller number of real happy-path checks. Engineering has always been the art of buying the right confidence, not all possible confidence.

Quality needs its own machine

More code means more opportunities for defects. Pretending otherwise is how a productivity experiment becomes a very efficient bug factory.

Our working model has three loops:

1. Decide well. Humans and agents build and challenge the specification before implementation begins.
2. Deliver automatically. Agents implement, test, review and prepare the change through an explicit workflow.
3. Repair continuously. Other agents search for regressions, compare expected with actual behaviour, and feed reproducible failures into parallel fixing loops.

The third loop matters because bugs are unusually agent-friendly: there is an expected result, an actual result and a gap between them. That is far easier to delegate than “invent the correct product”. The ambition is not zero defects by declaration. It is a system that detects and removes defects faster than increased output creates them.

Review changes too. Multiple fresh agents are already better at finding certain classes of issues than one exhausted author rereading the same diff. Human review remains essential for high-risk changes, new data models, security boundaries and architectural decisions. It is less valuable as a ceremonial approval of a thousand lines whose behaviour has already been proven.

The human job does not disappear

During the discussion I asked the uncomfortable question: if agents write the code and review the code, what exactly are we here for?

The answer I believe is this: to decide what deserves to exist, make trade-offs where no expected answer is available, and remain responsible for the outcome.

An agent can mirror your reasoning with enormous breadth. It cannot always tell when the problem labelled “architecture” is actually an unresolved business rule. Another person sometimes can—especially when they ask the annoying question that reorganises the whole problem. Teams will spend less time debating naming and more time discussing product behaviour, system boundaries, risk and money. Frankly, that sounds like an upgrade.

Judgement becomes more valuable, not less. The engineer who understands customers, economics, operations, data and architecture can direct a much larger amount of execution. The engineer whose entire identity is translating predetermined tickets into syntax is standing on shakier ground.

Our experiment, without the bullshit

For the first phase, we are deliberately making the experiment small enough to observe:

• Run several independent workstreams in parallel instead of polishing one agent conversation forever.
• Require an approved specification with explicit data, security, architecture and verification decisions.
• Make blocked external flows testable through controlled mocks.
• Use independent agent review in multiple rounds, but stop when later rounds produce mostly noise.
• Keep human review for changes whose consequences demand human judgement.
• Review the process weekly and improve the harness—not just the prompts.

And we will measure outcomes rather than generated artefacts: lead time from idea to verified behaviour, completed business capabilities, escaped defects, rework, human attention per change and operational load. Lines of code will be ignored with the respect they deserve.

Ten times is not a promise. It is the upper edge of a hypothesis. Three times with the same or better quality would already be transformative. Ten times the pull requests with ten times the cleanup would merely be a novel way to work weekends.

The actual bet

The bet is not that models will become perfect. They will not. People are not perfect either, although we have built an impressive number of meetings to disguise the fact.

The bet is that we can build an engineering system in which agents are allowed to be fast because the surrounding process makes errors visible, recovery cheap and important decisions explicit. That requires better specifications, better test environments, better feedback loops and the psychological pain of delegating work you could do yourself.

For now, the rule of the experiment is brutally simple:

If I am doing something manually, I have to ask whether the system is missing a capability.

Not everything should be automated. But “I have always done it this way” is no longer a sufficient reason to keep doing it.

This is Experiment 001. I will write about what happens next—including the failures, because a 10× claim without the wreckage is just marketing with better typography.