The Multiplier

This is part of a series of articles describing the evolution of my Digital Team, a harness of agents working with me to create useful things.


List of articles

Part 4: The Multiplier
Part 3: Why is that fence there?
Part 2: Don’t Do Anything You Can’t Undo
Part 1: Want a Digital Team?


Other resources

Project architecture and rationale

We had a hot month lately in fine tuning and building the right architecture and tools for our Digital Team.

We assembled a landing page for the project, where there is a detailed rationale, strategy and blueprint. All updates will go there, bookmark it: https://susala.eu/digital-team/

Now, I think time arrived for some numbers.

Since August – when the Digital Team lightbulb happened – I always thought in the back of my mind that the productivity gain might be around 100x.

100x faster than human work.
100x cheaper than human costs.
100x faster time to an MVP.

Sure, I like round numbers, but I wanted to gather some stats before hyping myself.

So I asked Claude Opus 5.5 to analyze the whole 2026 year to date, and he got some very interesting numbers. The report is much bigger and exhaustive, but I’ll summarize below the most important facts:

(BTW: this report is proof that nothing is lost: git and the session transcripts keep everything.)

Summarized raw figures

  • First recorded commit: 2026-01-07.
  • 9 months later: 46 repos, 4,532 commits. The 14 repos built actively hold ~576,000 tracked lines: code, tests, docs and config, without vendored code, lockfiles or binaries.
  • The largest are A (221k lines), B (138k) and C (60k).
  • Running in production or close to it: the CRM on its own appliance, various WordPress plugins and themes, the client-site fleet operations (several VPS, close to 100 domains/websites), and the Digital Team charter, published and tagged.

Volumes

MonthCommitsLines addedLines removedImport-sized commits (set apart)
2026-0117848,83614,0064
2026-0216155,7756,7063
2026-0318447,49612,7384
2026-04343106,83333,83412
2026-0528483,03120,7552
2026-0650382,29324,8973
2026-0738039,57012,4243
2026-08992111,26525,0754
2026-091,388123,04729,6373
  • September per project (commits / lines added): Project B 405 / 44k, Project A 396 / 31k, websites maintenance 178 / 11k, network operations 138 / 10k, and three more projects between 3k and 8k lines each.
  • Days with at least one commit: 19–31 per month, every month since January.
  • Commits grew 8x from January to September; lines changed grew only about 2.5x. The jump came with the Digital Team (August): more lanes in parallel, and smaller, verified, recorded units of work, not more code per unit.
  • Plus the team ledger: 625 commits in September alone.

Typing ratio

Transcripts, July–September: for every character I typed into a session, Claude wrote 46–76 characters of text, code and commands.

Time to fix

From the biggest and most active project, in the tracked period:

  • 206 of 315 (65%) were filed in the commit that fixed them. Found, fixed, tested and recorded as one unit, so there is no waiting time to measure.
  • The other 109, filed first and fixed later in a median of 8.5 hours (includes postponing fixing).

Most things are fixed the hour they’re found; what waits, waits on something else, such as my decision, an external release or a test host. The long tail is not machine time.

Example from 2026-10-01: a wrong verdict wording reported from a live prompt, then fixed, tested, replayed against all 6,171 commands ever judged, rebuilt and live in 13 minutes from filing. The first attempt silently made three real cases worse; only the full replay caught it.

Decision load – the weakest link

  • My prompts/messages: a median of 49 per active day (max 185), median 223 characters each, measured over 78 days with transcripts.
  • Decisions recorded in the team ledger (added lines that cite my word, ruling, OK or ratification): September: 344 lines over 25 days, a median of 13 per active day (max 68).
Machine clockWork clockHuman clock
Whattyping, generating, readingissues found → fixed → verifiedmy decisions and attention
Measured46–76 chars written per char typed65% fixed on the spot; median 8.5 h when waiting~49 messages, ~13 recorded decisions a day
Speed-up~50–75x (typing alone; higher without pasted text)large, not measurable as a ratio (no baseline)1x — unchanged

Rework

Commit subjects that revert or correct earlier work, all projects:

MonthCommitsRevertsCorrectionsShare
2026-01 → 072,045339~2.1%
2026-089960565.6%
2026-091,3880684.9%

Corrections more than doubled their share when the Digital Team started (August). Read carefully: that is mostly corrections becoming visible, because sessions now check each other’s claims (“Correct the handover: the closing report was acknowledged”).

Before the Digital Team, a wrong claim had to be caught by me or not at all.

The charter itself: 4 errata against the frozen text of record.

Live examples from a recent evening (2026-10-01): the first fix that made three cases worse (caught by replay); a peer’s kernel claim that was wrong (caught by cross-check); the pilot’s own wrong “correction” of a ledger line (caught by me). Even while preparing this article, Claude put “100x+” in a table cell where the measured ratio was 46–76.

By comparison with much of the human code I’ve seen shipped, it is close to flawless. Not flawless, though: it is fast, often wrong in small ways, and caught because the setup checks itself: tests, replays against real traffic, sessions checking each other, and me noticing. I trust it reasonably, and the trust rests on those checks, not on Claude being right the first time. Weaker programmers make mistakes too. The difference here is that every claim gets checked, and quickly.

Time estimates

Claude tries to estimate each fix/action, and it does so conservatively using human metrics. This is wrong, the actual AI work is several orders of magnitude faster.

Claude’s time estimates against reality (checked against the commits):

  • “An afternoon’s work” took 4 minutes (about 55x).
  • “A couple of hours” took 7 minutes (about 17x).
  • “About an hour” took 8 minutes (about 7x).

Claude estimates like a human contractor, and the bigger the unit (“afternoon”, “half a day”), the bigger the miss. I told Claude in April to stop quoting human hours, but he kept doing it.

When the machine sets the pace (copying 140 GB, reboots, builds), Claude’s estimates were right. Decidedly, the speed gap is in thinking and editing, not in disks.

The catch: both of the fastest project B builds broke something. One was an app-wide error the next day, the other a silently dropped setting. Each took minutes to fix, but I had to notice them first.

A real quote from a conversation in April: Claude claimed about 25 minutes of work and 1–2 hours saved; it had taken 3 minutes 53 seconds. My reply was “they were in fact some 2 minutes”. Even me can have time interpretations.

Money

I estimated some salary vs subcription figures in https://susala.eu/digital-team#faq

Numbers speak for themselves, and the “save” on human quirks is the most attractive.

I didn’t gather the “real” token cost behind this heavily subsidized subscription, meaning what the same work would cost through the API (Claude Code can estimate it). I didn’t want to be woken from my dream. And even if I counted it, the fair comparison is still with what I actually pay, the number on the invoice.

Moreover, in my FAQ I did not detailed a much more interesting arithmetic, so here it is.

So, my curiosity was always: what would a person who knows everything Claude knows could cost? It’s evident such a person can’t exist, but the thought experiment is still very telling.

Disclaimer: it’s a deliberately rough model, subjective by design.

Start from a senior programmer at 5,000 EUR net a month. About 90% of that pay is for thinking that has nothing to do with any particular language: architecture, design principles, debugging instinct, judgment. The other 10% is the language itself. That gives a simple, additive rule: the thinking costs 4,500 EUR once, and each language adds 500 EUR if known at production level, or 250 EUR if known well enough to work in carefully.

Apply it to Claude. By its own rough account it writes about 25 languages at production level and another 35 or so at working level. That comes to 4,500 + 25 × 500 + 35 × 250, about 25,750 EUR net a month, for a single person who can’t exist. And it still leaves out everything that isn’t a language: Linux and servers, databases, security, networking.

My own projects need far less than that. Across 46 repositories I counted eight programming languages. Six are in heavy use: Rust, PHP, TypeScript, Bash, JavaScript and Python. Two are light: Go and SQL. The same rule gives 4,500 + 6 × 500 + 2 × 250 = 8,000 EUR net a month for the one person who could have built all of it. In practice no such person exists either. It would have been a team: a Rust developer, a PHP/Laravel developer, someone for the front end, and someone for the servers. The sum of all these individual positions will be more than the 8000 EUR anyways.

And the largest “language” in my repositories isn’t code at all: it’s documentation, about 260,000 lines of written English. That is a job in itself, if you know what I mean. Another salary.

Against that, I pay 100 USD or around 90 EUR a month for Claude Max 5x.

I won’t claim this makes the multiplier exact. What the model shows is the order of magnitude, and it misses the main point anyway: prior to Claude Code, I never had the opportunity to spend 8,000+ EUR net on programmers, mostly because there were no viable products on the pipeline. Now they can happen easily.

Final multiplier

Reading the numbers above this way isn’t, by all means, statistical science.

However, based on them and my experience, I can safely claim that my Digital Team setup is 100x cheaper, and 100x faster at everything.

Except, well, me.

Take a seat. Take your time.


Bogdan Susala, October 2026

3 responses

  1. […] 4: The MultiplierPart 3: Why is that fence there?Part 2: Don’t Do Anything You Can’t Undo Part 1: Want a […]

  2. […] 4: The MultiplierPart 3: Why is that fence there?Part 2: Don’t Do Anything You Can’t Undo Part 1: Want a […]

  3. […] 4: The MultiplierPart 3: Why is that fence there?Part 2: Don’t Do Anything You Can’t Undo Part 1: Want a […]

Leave a Reply

Your email address will not be published. Required fields are marked *