The 206× experiment

Most people use AI like a faster search box. You ask, it answers, you copy the useful part. I use it like a staff. I keep about twenty AI agent threads going, each on its own job, across three companies and a few projects of my own. At the busiest moment last month, 18 of them were working at the same instant.

I studied machine learning before any of this was a product, so I don't treat agents like a chatbot. I treat them like a system to engineer, and engineers measure. People ask what my setup is actually worth, so I went back through 35 days of my own logs, from September 22 to October 26, 2026. Every message, dictation and click had already been recorded with a timestamp. Then I had the work my agents finished priced, blind, by three AI estimators who never saw how long I took.

The answer: one hour of my instructions produced about 206 hours of skilled work. Here's exactly how I got there.

• 206×

  skilled hours per hour I spent talking and typing to agents

• 118

  finished projects with proof they shipped, in 35 days

• 11min

  of my instructions per shipped project, for about 37 skilled hours each

• 18

  agent threads working for me at the same moment

Most AI productivity claims are guesses, and people are bad at judging their own speed with AI.

In a 2025 randomized trial, experienced software developers using AI tools took 19% longer to finish real tasks. They believed they had been 20% faster.¹ How fast it feels tells you almost nothing.

So I set three rules to keep the count hard on me:

1. Count only what a log can prove. Every second I spoke, every word I typed and every click.
2. Count only work that shipped. A draft, a demo or a half-finished branch earns nothing.
3. Let someone else price the work, blind. Three AI estimators, each in a fresh session, never saw my input or the clock.

My work runs through one task board I built, called Helm. Each card on it is one meaningful outcome with an end condition: what has to be true for the work to count as done. "Redesign the customer emails" isn't a card. "All 41 customer emails on the approved design, in light and dark, released with no outage, and checked with real sends in Gmail and Outlook" is.

Each card gets its own AI agent thread, and only I can mark a card done. That gave the experiment its unit of output: a card I accepted, with proof that it reached production or the public. I explain the whole system in the Helm article.

This is the side most people guess at. I didn't have to.

• Talking. My dictation app times every second I speak to my agents.
• Typing. I know every word I typed: 95,170 of them. And I measured how fast I type when I write to my agents: about 98 words a minute, close to twice the average typist's 52.² Text I pasted in, 79,475 words of it, didn't count as my effort at all.
• Clicking. 1,242 button answers and approvals, at 3 seconds each.

Over the 35 days that added up to 21.2 hours of instructions. That's about 36 minutes a day.

I didn't count reading or thinking time, because no log can prove it. Most of the time my agents are working, I'm doing something else or I'm away from my desk.

The research group METR ran into the same wall. When it reran its developer study in 2026, it found its own time logs were unreliable for people running several agents at once, because they work on something else while the agents run.³ A stopwatch can't follow someone doing five things in parallel. Counting the instructions can.

One more thing tilts the count against me. My dictation app only started keeping a log in mid-October, so anything I dictated before then is counted as if I'd typed it, and typing is slower than speaking. That makes my time look bigger, not smaller.

I finished 141 cards in those 35 days. 118 of them had proof they shipped: a production release, a published page or video, a live system. Only those counted.

I had an agent pick 40 finished projects for a closer look, to criteria I set, and write an evidence packet for each: what was asked, what was delivered, the quality bar, and links to the actual changes. Then three AI estimators, each in its own fresh session, priced every packet: 120 blind estimates, each with a low, likely and high figure. Each played one role, pricing the skilled hours people who already know my systems would need without AI:

• A skeptical engineering manager, told to push back and price only the minimum version that met the bar.
• A senior engineer, the middle view.
• An agency, pricing the billable hours across its team.

None of the estimators was given how long I took or how long the agents took. The skeptic struck padded evidence and rework, and a project nobody would plausibly pay for, like a personal tool, was dropped.

The 81 shipped cards outside the sample were each given the typical value for their business, using the median rather than the average, and I used the lower of two ways of scaling. Every minute I spent, including research, coordination and work still in progress, is charged to the shipped cards.

That put the work at about 4,374 skilled hours by the senior engineer's estimate, 2,477 by the skeptic's and 9,859 by the agency's. The lowest bound any of them gave was 1,528 hours.

Divide each estimate by my 21.2 hours and you get three answers:

• The skeptic: about 117×. Its job was to push back.
• The senior engineer: about 206×. The middle view, and the number I lead with.
• The agency: about 465×. What an agency would likely quote for the same work.

The full spread runs from the skeptic's lowest figures to the agency's highest, scaled to all 118 projects: 72× to 753×. I quote the middle and show the range both ways.

In plain terms: every hour I spent telling agents what to do produced, by the middle estimate, about five work weeks of skilled output.

First, these weren't toy tasks. The typical sampled project was worth 34 skilled hours, most of a work week, and the biggest was about two months of work.

Here's one of those projects up close. I asked my agents to redesign all 41 emails a software product sends its customers onto one approved design, in light and dark, built for Gmail, Apple Mail and Outlook, then released and checked with real sends. It shipped as seven separate changes.

My input was about 8 minutes: 31 short messages, 748 words and two clicks. The estimators put the same job at 55 to 144 hours for a senior engineer who already knew the codebase. Even the skeptic's lowest number, 34 hours, is more than 250 hours of work per hour of my input.

The pattern held across sizes: small fixes and two-month builds came out at about the same ratio.

The obvious worry is that speed costs quality. It didn't. Since my agent system went live in July, my merged code changes went from about 1 a day to 23. Reverted changes stayed flat at about one every 25 days, and failed production releases fell from 7.1% of attempts to 2.2%.

• 24×

  more code changes merged per day than before July

• Flat

  reverted changes, about one every 25 days

• 2.2%

  failed production releases, down from 7.1%

That's the opposite of what teams usually see. Across 22,000 developers, teams that adopted AI heavily shipped more, but their bugs per developer rose 54%.⁴ The checks in my system are why mine didn't.

The interesting part isn't the agents. Anyone can open a chat window. It's what makes a few words enough.

Twelve words from me once got a headline bug fixed, checked on all 13 live articles at three phone widths, and closed in 28 minutes. My typical message to an agent is about 10 words. Short doesn't mean hands-off: only about one comeback in seven is a plain "yes." The rest steer the work or ask a question.

Those short messages work because the hard thinking is already written down where the agents can see it:

• The card says what done looks like. An agent with a clear end condition doesn't need me to steer every step.
• A rulebook says how I work. Every lesson goes into it once, with a date and the reason, so I never explain it twice.
• Skills hold the know-how. I've written 77 of them: how to ship to production, how I like a summary written, how to check a video before it goes out.

This is where a machine learning background pays off. A model is only as good as the context and feedback you give it, and agents are no different. Articulation is a superpower. If you can say exactly what "done" means, in plain words, an agent can do hours of work on it. If you can't, no model is smart enough to guess.

There's a second reason it scales. The computer scientist Gene Amdahl showed in 1967 that running parts of a job in parallel only helps as much as the part that can't run in parallel allows.⁵ In my system that part is me. Running many agents at once only pays off if each one needs very little of my time. So I spend my effort shrinking the minutes each outcome needs from me, not on making any single agent faster.

The model is the engine. The system around it is the rest of the car.

Careful studies of everyday AI use find real but modest gains. Customer support agents with an AI helper resolved 14% more issues an hour.⁶ Consultants given GPT-4 finished tasks 25% faster, and did worse on a task outside what the AI was good at.⁷ Across three companies, developers with an AI coding assistant completed 26% more tasks.⁸ The biggest team-level result on record is about double.⁹ The closest method to mine, METR's look at its own staff's agent transcripts, found 1.5 to 13 times, counting every 10-minute window with a message as attention.¹⁰

So why is mine so far off the chart? Mostly because I'm not doing what those studies measure. They mostly test one person working alongside one assistant. In a 2026 survey, 69% of developers who use agents at work run just one.¹¹ I run a system: up to 18 agent threads at once, each with its own job, its own end condition, and rules it already knows.

Three things worth knowing, in plain terms:

• It's an estimate. AI estimators priced the work; nobody timed the same work done by hand. An outside human estimator and a few stopwatch tests are next.
• It counts my instructions, the part of my time a log can prove: every second I spoke, every word I typed and every click.
• It measures hours, not dollars. It's the skilled labor I'd otherwise have had to hire.

This is the point I most want you to take away. Nothing here depends on a secret model or a big budget. When Microsoft gave tens of thousands of its engineers the same kind of command-line agent I use, the ones who adopted it merged about 24% more code changes.¹² Mine went up 24 times. Same tool, very different result. The leverage comes from the system around the tool, and every part of that system is something I built, broke, fixed and wrote down. You can learn it.

You don't need twenty agents to start. Begin with five habits:

1. Write down what "done" looks like before you start. One sentence on the end result beats a page of instructions.
2. Keep a rules file. Each time you correct the AI, write the correction down once, where it will read it next time.
3. Talk instead of typing. You'll give far more context in the same minute.
4. Ask a second AI to check the first. Have one model try to find what's wrong with the other's work before you accept it.
5. Measure yourself. Note how long you spend and what actually shipped. Feelings are a bad stopwatch.

Then go deeper. Each of these is one part of the system behind the number:

• Helm: the task system my agents run. How every piece of work becomes a card with an end condition, how Slack, email and my own words feed it, and how each card gets its own agent.
• The art of context switching. How I get up to speed on a complex project in seconds and move between very different kinds of work without losing the thread.