100x is about using agentic AI to multiply the hours of work completed by a person to produce exponential outcomes. We all know using our favourite AI saves time, the question is how far can you really take this? This article shares my journey to date, a structured approach focused on speed, scale, and secondarily, learnings on how to minimise breaking things as you shift up through the gears.
I'd like to think of it as a gearbox. In first gear you're doing the work yourself, every gear thereafter hands a different part of that work to something else. Each shift accelerates what one hour of yours produces.
WHERE ×h IS THE WORK PRODUCED FOR ONE HOUR OF EFFORT
Scroll to see the full diagram
Output ×h is the work completed for every hour you spend. Your hours go three ways, directing, reviewing and waiting. Gears 2 and 3 take a bite out of one of those, gear 4 takes the waiting and stretches the job, and gear 5 grows the job a single hour of yours can command.
| Gear | What it changes | Gear | Output ×h |
|---|---|---|---|
| 1. Human only | the baseline | 1 | 1× |
| 2. Chat in a browser or app | the blank page | ×2 | 2× |
| 3. Voice in | the typing | ×1.5 | 3× |
| 4. Agents in many sessions | the doing and waiting | ×5 | 15× |
| 5. Orchestrator with workers | concurrency, and the job size | ×10 | 150× |
Each gear multiplier has been rounded on purpose, and in some cases this number may be more or less. The following outlines the rationale behind each multiplier to demonstrate how 100x or more can be attained.
Scroll to see the full diagram
Gear 1 is the time it takes a human to do the task, working alone with their usual tools and with no AI. That time is here defined as h. Every gear from here is measured by it.
Defining h seems easy, however knowledge workers have been found to be interrupted every two minutes during core work hours (Microsoft 2025), which makes measuring a clean baseline the first challenge to overcome when benchmarking and preparing business cases.
h is used to measure agents in other studies. METR's time horizons ask how long a task an agent can finish by itself about half the time, and answer in the hours a person would need for that task.
Scroll to see the full diagram
It's 'generally accepted' that using AI increases productivity, but measurements can vary widely given the user, task, and model to name just a few variables. So what does this space look like.
Evidence for a doubling exists, though it sits at the level of specific tasks rather than whole jobs at this time. Google engineers running code migrations estimated the work took half the time it had taken manually. At Procter & Gamble, one person working with AI matched the output of a two-person team working without it. In a controlled trial of GitHub Copilot, developers finished a defined task in 44% of the time the control group needed, which is 2.3 times the throughput on that task.
Whilst measurements vary, for purposes of this article I have defined that incorporating AI can multiply productivity by 2x.
Scroll to see the full diagram
You talk at roughly three times the speed you type, which is three times faster in communicating with the agent rather than three times the work done, which is why this gear is 1.5x.
Speech runs well ahead of typing. A 2025 study of more than a thousand clinicians across fifteen countries clocked dictation at a median 93 wpm against 21.4 wpm at the keyboard, and even after allowing for the time to correct transcription errors the effective rate held at 55.42 wpm, two and a half times faster. My own logs put nine days at 83,278 words spoken to agents, which at a keyboard would have been close to three hours of typing a day.
Communicating verbally with agents doesn't just increase speed, but delivers a range of other benefits, the subject of my next article.
Scroll to see the full diagram
This is the gear where you start to see real acceleration. Instead of interacting with one agent you interact with more than one at a time, in separate chats, browser tabs or terminal windows.
The practice is one git worktree per session, each on its own branch so no two agents write the same file. Boris Cherny, who created Claude Code, calls spinning up three to five of them 'the single biggest productivity unlock, and the top tip from the team', and describes his own setup as five sessions in the terminal with another five to ten in the browser, or in his words dozens of Claudes running at all times.
Most practitioners sit at two, the most upvoted answer on r/ClaudeCode, context switching, cognitive load and quality become key challenges.
Scroll to see the full diagram
The next gear is orchestration, instead of working with a single agent across each session, that agent becomes an orchestrator of sub agents on your behalf, how many depends on the task.
Ten concurrent sub agents per session may seem like a lot. Some recent examples of mine include: (i) OCR PDF to text conversion tasks, 70 concurrent agents, (ii) Quantitative analysis, 30 concurrent agents, and (iii) Research projects 12-24 concurrent agents.
Using multi-agent systems have been shown to outperform single agent systems, but conversely come with the overhead of increased token spend. Nonetheless, it's not unreasonable to set the gear and target here at 10x.
The gears show that these speeds and scale are attainable. What you get depends on who is driving, what the task is, and which model is behind it. The same setup that returns 15x on a well-specified job returns nothing on one you have not thought through.
The value is much more than getting work done faster, it is what a single hour of yours can now command. A task that used to take a day that now takes an hour changes where you can go as opposed to what you can do. Ideas that were never worth the cost of finding out are now worth a session.
This is where the conversation turns from speed and scale, to quality and value, i.e., the former is for nothing without the latter. I agree, but would also propose the former helps create the space to deliver the latter.
Scroll to see the full diagram
I see future ways of working incorporating runtime scheduling, enabling humans to efficiently work across multiple concurrent agent sessions whilst minimising context switching and cognitive load.
Scroll to see the full diagram
Every gear removes one constraint but exposes the next. That constraint is you, because everything the agents produce still waits on your review. Scaling production without scaling reviews only moves the queue closer to you.
Scroll to see the full diagram
One way to scale reviews comes in the form of loops. A loop runs the work until a check passes, run → check → fix → repeat until pass. Much like a human review they reduce speed, but they do enable scale.
Scroll to see the full diagram
Lusser's law holds that a series is only as good as the product of its steps. The fix is structural rather than a better prompt: check the output before it becomes the next step's input.
Scroll to see the full diagram
A model reviewing its own output shares its own blind spots. At minimum use a new session and context window if you're limited to using one model, otherwise engage another model to review the first model's outputs.
Speed and scale have exponentially outpaced humans. The human bottleneck is real, but ultimately reduces to a decision, i.e., is this correct? is the quality high enough? That is where the next gains have to come from.
Recursive self-improvement might be the means to do this. Anthropic (2026) define it as an AI system capable of fully autonomously designing and developing its own successor.
{% faqs faqs %}