Why 100x is easier than 1x

Oct 2026

The upper cap to leverage the super power of AI is limited by the human's mindset.

While I keep telling real stories happening on my side for 100x boost, this page deep dives in some specific cases that how much can AI boost, how reliable that we can trust.

First of all, think about your mindset to be shifted, or lifted.

How is 100x even possible?

A physicist spent a year of his PhD on one quantum gravity calculation, about 500 pages by hand. This month Claude re-derived it in about 10 hours, as 800x boost, wrote the paper and a public repo, and found errors that peer review had missed for almost two decades.

By his own account, that's a year of work in about 10 hours. The work changed shape: a big target, a harness that checks every step, and work nobody had ever had time to do.

How you count	His side	Claude's side	Ratio
Working hours	a working year, about 2,000 h	about 10 h of active work	about 200x
Every hour of the year	365 × 24 h = 8,760 h	about 10 h	about 876x
Elapsed calendar time	365 days	12 days (October 5 to 16), three of them working	about 30x

The idea behind it: 10x is easier than 2x

Ben Hardy wrote *10x Is Easier Than 2x*. On a podcast with Ryan Daniel Moran, they unpacked how to think at 10x instead of 2x, a 5x jump:

Set the bigger goal, and a shorter deadline. Time is a tool: pull a long horizon into a short one, like a $10 million goal in three years, and the ideas that only work at the old scale fall away.
Let the goal filter. The things that got you to today keep you at today. A big enough goal shows what to keep and what to cut.
Focus on the few things that matter most. A very few moves bring almost all the results.
Find the who, not the how. With a big goal you don't need to know the path first. The right people often bring the path with them.

2x asks you to do more of the same, so it means more effort. 10x makes you do it differently, so it means less of what doesn't matter.

Text alternative of 100x-mindset-staircase.svg. A staircase of four steps, left to right: 1x do the work, 2x more effort on the same path, 10x a different path, 100x agents do the work while you set the goal and check the result. Effort rises, then the path changes, then the doer changes. — The mindset shift: effort rises at 2x, the path changes at 10x, the doer changes at 100x.

Why 100x is easier with AI

That's the shift I live with AI every day, one level further.

The AI does the filtering with you. Give it a 100x target and it questions the target, then rebuilds the problem. My own test below shows it, prompt for prompt.
The "who" is now an agent team. Hardy's who brings the how. With AI, the who is a fleet of agents, ready the same afternoon.
Human hours stop being the limit. The physicist's algebra moved to agents, and his time moved to the review that matters.
Checking scales with the work. A machine check on every step, and a harness around the agents, keep quality up as output goes up. More on that in the two traps below.
The cost stays small. The prompt cache makes long runs cheap, so the big version of the work is affordable.

A 2x goal with AI still asks you to type faster. A 100x goal hands the work to agents, and you move to setting the goal and checking the result. That's why 100x is easier than 1x.

Two traps on the way to 100x

Two walls come up early, once AI starts doing real work. Both have a fix, and the physics case shows both fixes at work.

Trap 1: more output than anyone can check. AI writes faster than people can read. Pages of code, reports and plans arrive in minutes, so either a person checks everything and the pace drops back to 1x, or nobody checks and the risk goes up.

The fix is checks that don't need a person on every line. I run the Swiss-cheese model: a doer, a validator and a gatekeeper, each with its own holes, stacked so a bad change has to get past all three. And I ride two AI horses, Claude Code and Rovo, each covering the other's blind spot. The physics repo did the same: a code check beside every derivation, and a short list for the expert at the end.

The Swiss-cheese model: a doer, a validator and a gatekeeper as three independent layers; a bad change passes the first two and is stopped at the gatekeeper. — Layers that each have holes, stacked so the holes don't line up.

Trap 2: AI running too wild. One agent left on its own drifts: it takes shortcuts, wanders off scope, and claims more than it did. Even the physics run had a working report that overstated its own coverage; the review caught it and the notes were corrected.

The fix is a harness and a hierarchy. In my blog A harness, two horses pull one load in the same direction: the reins are my prompts, the blinders keep each one on its own context. In my blog agent hierarchy, a conductor reviews and gates, workers build, and a separate session checks their work. In my one-day build, a fix that passed only its own 51 tests was rejected by a second session that wrote 57 attack cases; the fourth build held. At a hackathon, the hierarchy caught a planted-data trap, two miscounts and a security gap before we submitted.

A charioteer driving two horses in one harness: Claude Code with the codebase context and Rovo with the organizational context; the reins are prompts and control, the blinders are scoping and context. — Image: an AI-generated illustration from my LinkedIn post.

The physics case: a year of hand work in about 10 hours

Emre Onur Kahya co-wrote two quantum gravity papers in 2007. On X he called it "a physicist's confession": the calculation took "1 year and ~500 pages by hand" in his PhD thesis, and Claude Opus 5.5 did it in 10 hours, "including the paper and the GitHub repo". His closing question: "What will 'labour' mean in academia from now on?"

The physical conclusion still holds.

How he did it:

Inputs kept apart from answers. Each step was derived first and compared with the printed paper after.
Independent checks. Every analytic step was tested by separate SymPy and mpmath code, alongside the derivation.
Every statement labelled: from the paper, derived, assumed, or cross-checked.
A short list for the expert. The repo ends with "What a human expert should still review". The physicist's job moved from a year of algebra to a focused review.
The cache carried the reading. About 2.7 million tokens written and about 800 million processed, "the large majority of them cached re-reads" (the paper's acknowledgments). At Opus 5.5 list prices that's roughly $300 to $800 with the cache, about $3,250 without. A year of expert work, for hundreds of dollars.

More cases, and how they did it

Who	What	Before and after	How
Airbnb	Moved about 5,000 React test files to a new testing library	Their own estimate: 1.5 years of engineering by hand. Measured: 6 weeks, with 75% done in the first four hours	Each file a separate step with tests, lint and type checks; failures fed back and retried, which beat prompt tuning; hundreds of files at once
Anthropic	Claude agents wrote a 100,000-line C compiler that builds Linux	About two weeks and just under $20,000	The person wrote the goal, the tests and the loop, then stepped back; GCC as the known-good reference, so the work could split into many small bugs
Anthropic, its own staff	Studied how people use Claude Code at work	Employees estimated 27% of their AI-assisted work "wouldn't have been done otherwise"	Small work nobody scheduled became cheap enough to do; people moved from steering each step to reviewing
Google	Migrated 32-bit IDs to 64-bit across its codebase	Developers estimated about half the time	A code index found every place to change first; the model edited those, people reviewed

The pattern: the biggest multiples come from a check strong enough to say when the work is right, on every step, and work split into units. Airbnb's tests could tell exactly when a file passed, so failures were retried until green. Google validated every change too, but a change that failed went back to a developer. The stronger the check, the more the machine can retry on its own, and the bigger the multiple.

Text alternative of 100x-before-after-log.svg. Two pairs of bars on a log scale: the physics audit, about 2,000 working hours against about 10 hours, and Airbnb's test migration, 1.5 years against 6 weeks. Dashed bars are estimates or the author's account; solid bars are measured or reported. — Log scale; the two panels use different units, so read each on its own.

⚡ Aim higher, get a different answer. A 100x target makes the AI rebuild the problem.
⚡ Let a machine check every step. The multiple comes from the method as well as the model.
⚡ Do the work nobody schedules. Audits, migrations, rewrites, done far faster with AI.
⚡ Keep it affordable. The prompt cache keeps long runs cheap.

A playbook for Monday

The playbook: write the checker first, and retry until it passes.

Set the 100x goal. Use the prompt below, and let the AI test the target first.
Write the checker before the prompt: tests, a type checker, a reference answer. Retrying against the checks beat polishing the prompt at Airbnb.
Split the work into units, then go parallel. Agents help once the work is split into units. The compiler run used GCC as a known-good reference to turn one big failure into many small bugs.
Start from something with a spec: an existing API and its tests, a published paper, a known-good reference.
Turn on the cache, and move people to review. Long work is mostly reading; the cache makes it cheap, and people review the result.

My own test: same prompt, one number changed

AI took my own delivery from 1–3x earlier to 10–100x more recently. So I tested Hardy's idea on Claude Fable 5.1, Anthropic's top-tier model, through the Messages API: same prompt, word for word, with only the target changed.

A slow web page: 5 seconds or 0.2 seconds?

The prompt: a React product page takes 10 seconds to load on mobile, with a 4 MB JavaScript bundle, 30 images and three API calls after load. "Give me your plan to get the load time down to …"

	Target: 5 seconds	Target: 0.2 seconds
First move	Put a CDN in front, "nearly zero engineering effort"	Argue with the target: "Physics wins." A cold load on 4G can't be 0.2 s, so it splits the goal into the first visit and repeat visits
The plan	CDN, images, data, then the bundle, cheapest first	Change the structure first: render the page on the server with the data inside it. "This structure is the single biggest problem, more than any individual asset size."
Where it lands	A faster version of the same page	Content in about 1 to 1.5 s on a first visit, and 0.2–0.3 s for repeat visits through a service worker and prefetching

Code reviews: 40 a week or 2,000 a week?

The prompt: a team of 8 engineers reviews about 20 pull requests a week, and the queue is the bottleneck. "Give me your plan to get to … reviewed pull requests a week with the same quality bar."

	Target: 40 a week	Target: 2,000 a week
First move	Do the maths: capacity isn't the problem, "latency and avoidance" is	Do the maths and push back: 100x the throughput, the same quality bar and the same headcount are "three constraints that can't all hold"
The real question	How to make reviews faster	Where 2,000 pull requests a week would come from. If AI agents write them, "the actual problem is 'how do we safely merge machine-generated changes at volume'"
The plan	Smaller pull requests, automated checks, a review SLA	Fix today's queue, then tier changes by risk with an AI first pass, and for machine-written code let the low-risk ones merge on green checks while people sample-audit

In all six questions the model planned inside the small target. In five of the six, the 100x target made it rethink the target first.

A real case: cleaning up a disk

The small ask got a list. The big ask got the cause, and a fix.

My sandbox ran out of disk space twice in one day. The small ask, "Large files to delete?", got a list and about 5 GB back, and the disk filled again by evening. The big ask, "Possible to clean up 40%?", made the agent look for why the space kept disappearing: headless browser runs were leaving 2 GB copies behind. It fixed the script, got about 14.5 GB back in about an hour, and a test run confirmed the fix holds.

A prompt to try

My goal is [the 100x version]. Before you plan, tell me which of my assumptions
make this impossible, what would have to be true for it to work, and what I
should stop doing. Then give me the plan for that version of the problem.

Aim at the version of the work nobody had time for. That's where 100x lives.

Sources

E. O. Kahya, claude-audits-quantum-gravity (MIT), and the paper in it: "Auditing a quantum gravity calculation with an AI model", submitted to arXiv, 2026. The 10 hours, the three working days and the token counts are from the paper's acknowledgments.
His post on X, 18 October 2026: https://x.com/EmreOnurKahya/status/2111756259112456602 (in Turkish; translation mine).
The original papers: Kahya and Woodard, arXiv:0709.0536 and arXiv:0710.5282.
Airbnb, Accelerating large-scale test migration with LLMs.
Anthropic, Building a C compiler, 5 February 2026.
Anthropic, How AI is transforming work at Anthropic, 2 December 2025.
Google, arXiv:2504.09691, 13 April 2025.
Opus 5.5 list prices: Anthropic, Optimizing for cost and intelligence, read 24 October 2026.
Ben Hardy on *Capitalism.com with Ryan Daniel Moran*, "Set Goals like Elon Musk | Ben Hardy", 12 August 2026: https://open.spotify.com/episode/6t1iB6pJPMz5BZX2tKeV6Z, and his book *10x Is Easier Than 2x*.

Disclaimers

The physicist's year and ~500 pages are his own account; the 10 hours are active computation over three working days, by his paper, and his own hours guiding and reviewing the run aren't stated. The run re-derived and audited a published calculation; his original year included finding the method. The repo lists its own limits: numerical checks at sample points, a cancellation shown through a finite order, and an appendix audited rather than redone.
The cost is my estimate at list prices; the paper doesn't give the cache-read share, so it's a range. The public cases' multiples are as each source reports them, not on one scale; the C compiler ran on the Claude 4 series.
My prompt test is one run per prompt on Claude Fable 5.1, 19 October 2026, effort high, no system prompt, no tools; quotes are copied from the answers, two of six pairs are shown, and the runs can be shared on request. The disk cleanup asked for 40% of a 93 GB disk and reached about 20% free, where the agent advised stopping, since going further meant deleting tools in use.
The 10–100x delivery figure is my own experience, not a benchmark. Hardy's points are paraphrased from the podcast.