A lot of AI productivity claims sound impressive until you ask what was actually measured.
"10x developer productivity" usually means one of three things:
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?
My first instinct was to look at code volume.
Over roughly 30 days of recent development, MachDuDas had:
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:
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 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:
They also removed about:
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:
In August 2026, runtime-code additions were lower:
But test code exploded:
Across March through September 2026, MachDuDas accumulated approximately:
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.
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:
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.
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:
This changed the picture.
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.
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.
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.
I also reconstructed production incidents and separated them into categories:
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.
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 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:
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:
Those are still human decisions.
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:
The old advice to reduce batch size becomes more important when code generation gets cheap.
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.
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.
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.
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.
If you want to estimate human capacity, normalize by the humans actively involved. Otherwise you are just comparing busy periods with quiet periods.
Measure whether the work reaches production.
Useful metrics include:
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. 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.
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:
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.
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:
Those numbers will change as more data accumulates.
But they tell a more useful story than LOC alone.
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.