A lot of AI productivity claims sound impressive until you ask what was actually measured.
"10x developer productivity" usually means one of three things:
- More lines of code
- Faster task completion in a benchmark
- A subjective feeling that work is moving faster
Those are weak signals.
Lines of code are easy to inflate. Benchmarks are not production systems. And generating code quickly is not the same as shipping working software safely.
I wanted a better answer for my own work.
I own and operate MachDuDas, a German marketplace that has existed for more than a decade. The repository has years of history from conventional development teams, before generative AI was part of the workflow.
Today, I am effectively the only human driving development, but I work heavily with AI coding agents.
That gave me something close to a natural experiment:
Same product. Same codebase. Different development model.
The question was simple:
How much engineering capacity have AI agents actually given me?
The first measurement was misleading
My first instinct was to look at code volume.
Over roughly 30 days of recent development, MachDuDas had:
- About 54,700 lines added
- About 10,000 lines removed
- About 44,600 net lines added
- 139 relevant commits
- Another roughly 10,000 net lines on feature branches not yet merged to
master
That looked like about 10,000 net lines per week.
If you compare that to old industry estimates for programmer productivity, the result looks absurdly good. Depending on the benchmark, you can make the output look equivalent to a team of 15, 20, or more engineers.
That comparison failed the smell test.
The reason is obvious once you inspect the work.
AI-assisted development produces a lot of supporting code:
- Automated tests
- Browser tests
- Fixtures
- Migration logic
- Verification scripts
- Supporting infrastructure
That code is valuable and cannot be compared reliably with generic historical LOC benchmarks.
A line of application logic, a line of fixture data, and a line of browser-test setup are not the same productivity unit.
So I stopped comparing MachDuDas to generic industry averages.
I compared it to itself.
The better baseline was the same repository
The MachDuDas repository still contains older development history.
That means I can compare current AI-assisted development against earlier conventional development on the same product.
One useful period was July 2016.
During that month, three human contributors added approximately:
- 22,900 lines of runtime application code
They also removed about:
- 5,700 lines
That was a productive conventional team working on the same software product.
Now compare that with recent AI-assisted development.
In June 2026, one human contributor directing AI agents added approximately:
- 30,800 runtime-code lines
In August 2026, runtime-code additions were lower:
- About 12,200 lines
But test code exploded:
- More than 72,000 lines of tests were added
Across March through September 2026, MachDuDas accumulated approximately:
- 81,000 runtime-code additions
- 105,000 test additions
That test number matters.
The older history does not contain anything close to that amount of automated verification.
The fuller story includes:
AI makes certain kinds of engineering work cheap enough that I ask for much more of them.
Especially testing.
The multiplier I can defend
When I normalized the historical periods by active human contributor-month, the current AI-assisted workflow produced about:
2.4x the runtime-code output per active human contributor.
If I exclude the initial large 2016 repository-import period, the multiplier is closer to:
3.2x.
That is much less dramatic than the 10x or 20x claims people like to throw around.
It is also much more believable.
And it only covers application-code production.
The estimate also excludes extra automated QA, migration verification, operational work, and test-writing produced by agents.
My current estimate is that my one-person-plus-agents setup has engineering capacity comparable to a conventional pre-generative-AI software team of roughly:
4 to 7 people.
My best single estimate would be around five or six.
Very roughly, that conventional team might have looked like:
- 2 to 3 application developers
- 1 to 2 QA or test-automation engineers
- Part of a DevOps or release-engineering role
- Part of a technical product or engineering-management role
This is an engineering-capacity comparison. Literal replacement of six developers is too simplistic.
It means one technical founder can now operate at a level of engineering capacity that, on this product, previously would have implied a small software team.
Those are different claims.
Shipping matters more than code volume
The next question is more important:
Did the code actually reach production without making the product worse?
So I reconstructed MachDuDas production deployments and applied DORA-style delivery metrics.
The goal was to look beyond code generation and measure the delivery system:
- How long does a commit take to reach production?
- How often do deployments happen?
- How often do deployments break production?
- How quickly do deployment-caused failures recover?
- How much deployment work is rework?
This changed the picture.
Lead time changed once large branches cleared
Across a large set of commits where I could reconstruct both the commit timestamp and the first production deployment containing that commit, the median commit-to-production time was:
6.8 days.
The 75th percentile was about:
9.2 days.
At first, that looked much less impressive than the development velocity.
Then I separated the most recent deployments.
From mid-September onward, the median commit-to-production lead time fell to roughly:
11 hours.
The 75th percentile was about:
3 days.
The system had changed.
Earlier work was accumulating in large branches, especially around a major frontend migration and parity project. Once those large batches started clearing, the actual delivery loop became much shorter.
This is an important lesson for AI-heavy development:
Fast implementation does not automatically create fast delivery.
You can generate code faster than you can review, integrate, and release it.
Deployment frequency moved from weekly to several times per week
Over the six-month period I reconstructed, MachDuDas averaged approximately:
One production deployment every 6.8 days.
That is roughly weekly.
But the recent period looked different.
Between September 14 and September 22, there were:
Seven production deployments in nine days.
So deployment frequency moved from roughly weekly toward several times per week.
That is the kind of signal I care about more than raw LOC.
If AI only creates larger branches that sit around longer, the productivity gain is partially trapped.
If it helps produce smaller changes that reach production safely, the gain is much more real.
Change failure rate stayed in a reasonable range
I also reconstructed production incidents and separated them into categories:
- Failures clearly caused by deployments
- Likely deployment-related failures
- Unrelated infrastructure issues
- Staging failures
- Normal follow-up improvements
That distinction matters.
An nginx outage, for example, is not automatically a failed software change.
Using the strictest interpretation, I found one clearly documented production regression caused by a deployment during the relevant period.
That gives a change failure rate of approximately:
3.7%.
There was another earlier incident that was very likely deployment-related. Including that one raises the estimate to:
7.4%.
So the defensible range is approximately:
4% to 7%.
Given the amount of software changing, that number is more meaningful to me than how many lines the agents wrote.
Recovery and rework matter too
The earlier likely regression was hotfixed in about:
13 minutes.
The later confirmed deployment regression was remediated within approximately:
15 hours.
The historical evidence is not precise enough to claim an exact median recovery time.
But it is enough to say observed recovery from deployment-caused failures was within:
Less than one day.
There were no observed executed rollbacks in the reconstructed period.
I also looked for production deployments whose primary purpose was repairing a problem introduced by earlier deployment work.
Depending on how conservatively incidents are classified, approximately:
7% to 11% of deployments were rework.
That is an important guardrail.
An AI system that writes 100,000 lines and forces humans to spend the next month repairing them is not productive.
Here, the evidence shows high output alongside acceptable delivery quality.
The bottleneck moved
The most important conclusion is that the bottleneck moved as implementation became cheap. Fast code generation is already obvious.
The more interesting change is that the bottleneck moved.
Ten years ago, implementation itself was expensive.
A feature required human time across many layers:
- Backend code
- Frontend code
- Tests
- Migration logic
- Repetitive verification
- Documentation
- Debugging
- Operational scripts
Every additional layer consumed scarce engineering hours.
Today, many of those activities are much cheaper.
I can ask an agent to investigate legacy behavior, implement a change, write unit tests, add browser tests, test migration idempotency, inspect edge cases, update documentation, and review its own implementation.
Engineering still carries real costs. The scarce resource moves.
The scarce resource is increasingly judgment.
Someone still has to decide:
- What should the system actually do?
- Is the agent solving the right problem?
- Did it invent an unnecessary abstraction?
- Is a behavior change intentional?
- Should this branch be merged?
- Should this deployment happen now?
- Is this test proving useful behavior, or just encoding the agent's assumptions?
Those are still human decisions.
Batch size became a real problem
One of the largest recent MachDuDas initiatives accumulated more than 60 commits on a feature branch.
The implementation work was moving quickly.
But the branch became large.
That creates a strange failure mode.
AI can generate changes faster than they can comfortably be reviewed, integrated, and released.
In traditional development, teams often waited for implementation.
In AI-heavy development, implementation can start waiting for acceptance.
That is a different engineering-management problem.
The practical response is to keep the work smaller:
- Smaller stories
- Smaller branches
- Shorter-lived branches
- More frequent integration
- More frequent production releases
The old advice to reduce batch size becomes more important when code generation gets cheap.
AI changes the economics of testing
The test numbers surprised me.
In one month, AI-assisted development added more than 70,000 lines of tests.
I would not have commissioned that amount of manual test-writing effort from a small conventional team.
It would have been economically irrational.
But if the marginal cost of test creation drops, the tradeoff changes.
The question becomes less:
"Is this worth paying a human to test manually?"
And more:
"Can we prove this behavior?"
If the answer is yes, an agent can often create that proof at relatively low incremental cost.
This is another reason raw LOC comparisons are misleading.
Thirty thousand lines of application code plus seventy thousand lines of tests is not the same thing as one hundred thousand lines of application complexity.
Some of that volume is verification that previously would not have existed at all.
What I would measure on another codebase
If you are trying to evaluate AI-assisted development in your own team, start with delivery outcomes before "lines of code generated."
I would start with these questions.
1. Compare against your own history
Do not compare your team to generic productivity benchmarks if you have better data.
Your own repository history is a stronger baseline.
Same product. Same domain. Similar architectural constraints.
2. Separate runtime code from verification code
Application code, tests, migrations, fixtures, and operational scripts should not all be treated as the same output.
They all matter, but they mean different things.
3. Normalize by active human contributor-month
If you want to estimate human capacity, normalize by the humans actively involved.
Otherwise you are just comparing busy periods with quiet periods.
4. Track delivery alongside generation
Measure whether the work reaches production.
Useful metrics include:
- Commit-to-production lead time
- Deployment frequency
- Change failure rate
- Recovery time
- Rework caused by previous deployments
5. Watch batch size
AI can make large branches deceptively easy to create.
Large branches remain hard to review and risky to ship.
If lead time gets worse while code output improves, batch size is a likely suspect.
6. Treat tests as output and classify them separately from application complexity
AI-generated tests can be very valuable.
Keep test volume separate from runtime code volume.
Large test additions may reflect improved verification without enlarging the product surface.
Limits of this comparison
Generalizing this into a claim that one AI-assisted founder can replace every six-person engineering team would exceed the evidence.
MachDuDas has characteristics that make AI particularly effective:
- It is an existing product
- A lot of behavior is already encoded in the software
- The repository contains substantial historical context
- I know the product well and can make decisions quickly
- There is almost no organizational communication overhead
- Agents can work directly against the repository
- Many tasks involve construction, migration, testing, and verification
A six-person startup building a new product is doing more than writing code.
It is also doing discovery, customer research, design, strategy, internal communication, and countless informal decisions that do not appear in Git.
Those responsibilities still require human judgment.
Where I landed
For MachDuDas, the evidence currently supports this conclusion:
One founder directing AI coding agents is producing roughly 2.5 to 3 times the application-code output per active human contributor that the same product historically achieved with conventional developers.
Once automated QA, testing, migration work, and release engineering are included, the overall engineering capacity appears comparable to roughly:
A 4 to 7 person conventional software team.
Delivery quality remained stable enough to make the additional throughput useful.
Recent production delivery has reached:
- Sub-day median commit-to-production lead time
- Several deployments per week
- Approximately 4% to 7% observed change failure rate
- Recovery from deployment-caused failures within a day
- Relatively limited deployment rework
Those numbers will change as more data accumulates.
But they tell a more useful story than LOC alone.
The practical implication for technical founders
The biggest change is the amount of software business one technical founder can now maintain and substantially evolve. Typing speed barely matters to me.
A technical founder can now direct a collection of AI agents that investigate, implement, test, and verify software across multiple layers of a system.
The founder becomes less like an individual programmer and more like a very small engineering organization.
But somebody still has to run that organization.
Someone has to maintain the model of what the product is supposed to do.
Someone has to notice when an agent is technically correct but solving the wrong problem.
Someone has to decide what goes into production.
Someone has to say no.
For now, that is still the human job.
And in my experience, that is where the real leverage now sits.
