AI

Software Development

Ai Revolution

Claude Code

The AI Revolution. Part II: The Senior Multiplier

J. P. Solano

10 min read

·

May 19, 2026

--

Listen

Share

What 100× actually looks like — measured over 24 hours — and what 600 years of disrupted skilled labor say about who wins next.

1476, Paris

In 1476, a group of Paris scribes broke into Johann Heynlin’s printing shop and destroyed his press. They had a real grievance. A press could reproduce a book in a day; a scribe needed a year. The math was unforgiving: one machine, one operator, 300× the output.[1]

I keep thinking about those scribes. Not because of the violence. Because of the math they refused to do.

We are running the same math right now in software, and most of the industry is still debating whether the press exists.

Here’s what 24 hours AI-driven coding looks like. No meetings, no stand-ups, no distractions.

1. The numbers, by artefact

Just me, one AI coding tool and a solid plan (it took me at least 1 week to create it), working in tandem on a real production codebase for a single 24-hour stretch. Measured, not estimated.

Production level code

• 8,977 lines of new production code across 44 files
• 9,534 lines of tests across 40 files (8,992 unit-level + 542 TDD-first contract tests)
• Tests-to-production ratio: 1.06× (≈1:1)

Documentation

• 392 lines of architecture-decision records across 3 files
• 42 lines of plan-module updates across 4 files
• 136 lines of project-context document updates (the in-repo file the AI tool reads at session start)
• 205 lines of skill / tool specifications
• 3,524 lines of structured audit-trail markdown across 28 report files
• 1,442 lines of pull-request wording across 21 PRs
• All documentation total: 4,299 lines / 39 files

Process artefacts

• 21 pull requests opened, reviewed, audited, merged
• 35 issues created (24 of them auto-tracked deferrals from audit findings)
• 21 issues closed
• 9 automated code-vs-criteria reviews (1,222 lines of structured reports)
• 9 automated code-vs-plan audits (1,106 lines of reports)
• 14 distinct features shipped
• 1 bug fix — caught in-PR by audit before merge
• 0 regressions, 0 force-pushes, 0 doc drift
• 1 PR every 68 minutes average
• All 21 PRs merged green on first ready-mark. Zero retries.

Total LOC contribution: 22,934 added / 262 deleted. The deletions were cleanups, not regressions.

Same output, unaided: an honest estimate puts a principal-grade engineer at ~625 hours of focused, sustained work — roughly 5 months at 6 productive hours per day. 80–120× compression, with quality preserved.

That ratio is not a typo, not a cherry-picked snippet, and not a vendor demo. It is one cycle of one senior with one tool, instrumented end to end.

2. Three modes — what the math forces

The data refuses the binary frame.

AI alone        →  median quality at LLM speed
Senior alone    →  excellent quality at human speed (5 months)
Senior + AI     →  excellent quality at LLM speed (24 hours)
                   ── only when the senior owns the spec, the gates,  
                      and the audit

The first row is what most people picture when they hear “AI coding.” It is also what most teams produce when they hand a model a vague ticket and accept whatever comes back. It is the mode that lets the rest of the industry conclude “AI doesn’t work for serious code.” It doesn’t. Without you.

The second row is the experienced-engineer baseline most of us trained on. Excellent work, sustainable cadence, perishable when the engineer takes a vacation.

The third row is the one that matters. It is not faster typing. It is the senior’s spec, gates, and audit machinery getting amplified by a tool that does the routine work at machine speed. The model is the typing. The discipline is the multiplier.

3. The historical pattern — four cases, four multipliers

The 80–120× number is not unprecedented. It is the latest data point on a curve that runs through 600 years of skilled labor. Four cases worth knowing, with the mat

Press enter or click to view image in full size

The historical pattern — four cases, four multipliers

Pull the invariant out:

Across all four: the tool compressed the routine, the role moved up the value chain, the resistors lost, the adapters got a temporary arbitrage that compounded into structural advantage. Not a single counter-example.

The ATM case is the one most engineers should sit with. Everyone — economists, banks, the tellers themselves — predicted automation would eliminate the role. The opposite happened. Banks opened 43% more branches because each branch got cheaper to run.[4] The teller role got scarcer per branch but more numerous in aggregate, and the survivors moved from counting cash to selling mortgages. Compression of the routine task increased demand for the skilled task.

If you take one historical pattern from this post, take that one.

4. Where the leverage actually moved

The thing that compressed in the 24h cycle:

• Typing for-loops you’ve written 200 times
• Looking up that one library method signature
• Wiring up the spec → impl → test triangle for a new module
• Restating a complex diff in a PR description that reviewers will skim
• Cross-referencing 16 review criteria against a 1,000-line patch
• Boilerplate, scaffolding, the third copy of an interface that was always going to be similar to the first two

The thing that did not compress:

• Deciding what to build
• Designing the interface between two modules so a new caller doesn’t break in 3 months
• Picking when to bundle two changes vs. split them
• Catching that the audit’s 25th tracked issue is actually a duplicate of a 6-month-old one
• Knowing that this looks like a 2-day implementation but is secretly a security boundary
• Reading the PR you just wrote with the eyes of the person who will inherit it in a year

If you spent the last decade getting good at the first list, your moat just evaporated. If you spent it getting good at the second, your multiplier just landed.

That distinction is the entire post in one paragraph. Read it twice.

5. The denial trap

There is a colleague at every company right now who refuses to use these tools. Their reasons:

• “It hallucinates.” It does. So does the junior they trained last quarter.
• “It writes bad code.” It writes median code. The senior turns it into good code. Without the senior it stays median.
• “I’d rather understand it myself.” They still do. They read every line before merging — that’s the whole point of the third mode.
• “It’s intellectual laziness.” This one is just pride wearing engineering clothes.

The math doesn’t negotiate with any of these. The colleague who used the tool today shipped 5–10 features. You shipped a careful one. Compounded weekly, that gap is irrecoverable.

This is not a moral judgment. It’s the same trade the Paris scribes had in 1476. They were better than the press at one specific job — beautiful, irreplaceable manuscripts — and that mattered for about 30 years. Then their patrons died, their apprentices left, and their craft became a museum piece. The thing they were excellent at was no longer the thing the world was paying for.

You are not being asked to abandon your craft. You are being asked to bring it to a tool that finally makes the boring half cheap.

6. Brief note for the people writing the comp checks

Three points, and we move on.

1. The compensation lag is the arbitrage window. A senior who has internalized the third mode delivers what 5–10 unaided seniors used to. Comp models do not yet reflect this — there is no “Principal SWE, AI-amplified” rung on most ladders, because most ladders were drawn before the multiplier existed. The window closes in 2–3 years as the market re-prices. The companies that retain and amplify their senior software engineers now gain a structural advantage that compounds for the rest of the decade.
2. Junior hiring is the harder problem, not the easier one. Juniors used to become seniors by typing code; that bridge is being compressed. The mentorship structure has to be redesigned around judgment, not throughput — and the redesign is itself senior-SWE work. Pretending nothing changed is the slow Luddite trade. Hiring three juniors at lower comp to “wrap prompts” produces median output at LLM speed, which is the first row of the table above. The mode that doesn’t ship.
3. Don’t replicate the textile owners’ mistake. The mill owners of 1810 cut hand-weaver wages while installing power looms and discovered, painfully, that the mills needed more skilled supervision than the workshops did, not less. They kept the wrong half of the equation. Cost-cutting was the wrong frame in 1810. It is the wrong frame in 2026. The instinct to “replace seniors with juniors plus AI” reads exactly like cutting hand-weaver wages. It will produce exactly the same outcome.
4. The engineering ladder needs a new top step. The “Principal SWE” rung was sized when one Principal could deliver one Principal’s output per quarter. The measured ceiling is now 10–100× that. A senior SWE contributing at the third-mode rate sits structurally between historical Principal and historical Director-level scope — and most companies have no rung there. They lose their amplified senior engineers to companies that do. This is not speculation; it is compensation theory applied to a two-order-of-magnitude productivity shift, which the labour market has historically re-priced within 3–5 years of the underlying tool becoming standard. The ladder you draw in the next 12 months will determine which side of that re-pricing your company is on.

That’s the executive section. Back to engineering.

7. The playbook

Four shifts.[5] They fit on a wall poster. Anyone running an AI-augmented dev team will converge on something close to these whether they read this post or not — better to skip the years of trial and error.

1. Write the contracts before the first line of production code. Schemas, interfaces, error envelopes, role/permission matrices, observability shape — pinned in version-controlled markdown alongside the code they specify. Vague specs produce divergent agent work; pinned contracts produce convergent parallel work. The plan does not have to specify the world up front; it has to specify the seams. Velocity without a contract is just faster drift.
2. Gate at decision points, not code points. Reversibility test: if this change lands and turns out to be wrong, can it be undone cheaply? Yes → flow it through the agents, the checklists, the audits. No → human gate. The set of “no” categories is small and stable across every team I’ve seen: authentication and identity, money handling, schema migrations to shared environments, production infrastructure, the merge to trunk, external communication. Around the gates, three guardrails: tool-call budgets per agent session, WIP caps on open agent PRs, an explicit escalation protocol where an agent stops and asks rather than guessing.
3. Audit code against plan before declaring done. An agent’s todo list is its plan to itself, not the spec. The two diverge silently unless something explicitly checks. Run a code-vs-plan audit on every PR that closes a feature. Look for five categories of finding: gap (the plan said X; the code does not do X — blocker), soft gap (the plan said X for a later phase; the code defers correctly and the deferral is tracked elsewhere — OK), improvement, over-scope, doc drift. Route blockers to fix-in-PR; route everything else to durable, tracked issues — never PR comments, never report lines. Comments evaporate. Issues persist. If you only enforce the blocker half, you ship rigorously; if you only enforce the non-blocker half, you ship endlessly.
4. Encode the floor as a checklist; reserve human judgment for the ceiling. Mechanical correctness is regex-checkable and author-agnostic — does every tenant query carry the tenant filter, is the diff free of plaintext credentials, is every new endpoint described in the spec the client is generated from. Encode that as binary criteria and free your reviewers to spend attention on architecture, business logic, security boundaries, the thing the spec didn’t anticipate. If your reviewers are catching tenant filters in code review, you don’t have a code-review problem. You have a checklist problem.

The 24h cycle ran every PR through all four. Without them, the multiplier collapses to AI-alone — median work at LLM speed, worse than no multiplier at all, because you ship faster in the wrong direction.

Closing — the formula

Five lines. Suitable for a poster above your desk:

1. AI alone is median work at LLM speed.
2. Senior alone is excellent work at human speed.
3. Senior + AI is excellent work at LLM speed — but only when the senior owns the spec, the gates, and the audit.
4. Without the discipline, AI is a worse multiplier than no multiplier.
5. Adapt or be displaced. The historical record is unambiguous.

The press was invented in 1450. The scribes who broke into Heynlin’s shop in 1476 were 26 years late. Don’t be 26 years late.

References

1. Gutenberg / printing press productivity — historical text on the post-1450 knowledge economy, including Ripoli Press cost data (1483) showing per-book reproduction costs falling roughly 340× compared to manual scribing. The Paris scribes’ 1476 attack on Johann Heynlin’s press is documented in multiple histories of European book production.
2. The Luddite movement (1811–1816) — modern academic consensus (notably Eric Hobsbawm and the Cambridge economic-history archive) establishes the Luddites as skilled textile workers protecting wages and trade conditions against unskilled-labor displacement, not as anti-technology reactionaries. The mill owners’ wage cuts and circumvention of guild practices are the load-bearing context the popular caricature omits.
3. VisiCalc / Lotus 1–2–3 historical impact — Harvard Business Review archive material on the 1979–1985 spreadsheet revolution, plus Daniel Bricklin’s own retrospectives on what financial analysts could do in 15 minutes that previously required 20 hours of manual ledger work.
4. ATM employment paradox — James Bessen, Learning by Doing: The Real Connection between Innovation, Wages, and Wealth (Yale, 2015), and Bessen’s IMF Finance & Development article on the 500K → 600K teller-employment growth between 1980 and 2010 alongside ATM rollout. The 43% branch-expansion figure is from Bessen’s industry-data analysis.
5. Plan-first, audit-gated operating model — the four shifts in §7 are unpacked in greater depth in the companion essay Plans Are the New Code (dev.to). The current essay is the measured-evidence follow-up to that one.