There are a lot of claims about AI making developers 5x, 10x, or even 100x more productive.
Most of them are difficult to take seriously.
Lines of code are a bad productivity metric. Comparing one developer using AI with an unrelated engineering team is not particularly meaningful. And generating code quickly is very different from getting working software safely into production.
I happen to have something close to a natural experiment.
I own and operate MachDuDas, a German marketplace that has existed for more than a decade. The Git repository contains years of development history, including periods when the software was built by conventional human development teams.
Today, I am effectively the only human driving development, but I work extensively with AI coding agents.
So I wanted to answer a fairly simple question:
How much engineering capacity have AI agents actually given me?
Not theoretically. Not based on benchmarks.
On the same software product.
The first answer was wrong
I initially looked at the amount of code being produced.
Over roughly 30 days, development on MachDuDas had:
- added about 54,700 lines
- removed about 10,000 lines
- increased the codebase by about 44,600 net lines
- produced 139 relevant commits
- accumulated another roughly 10,000 net lines on feature branches that had not yet reached
master
That works out to something like 10,000 net lines per week.
Using old industry estimates for programmer productivity, it was possible to derive some fairly spectacular numbers. Depending on the benchmark, the apparent equivalent could easily look like a team of 15, 20, or considerably more engineers.
That did not feel right.
The problem is obvious once you look more closely.
Modern AI-assisted development produces enormous amounts of automated tests, migration code, browser tests, fixtures and supporting infrastructure. LOC benchmarks from very different types of software development are not comparable.
So instead of comparing MachDuDas against generic historical averages, I compared it against something much better:
MachDuDas itself.
The same product, ten years apart
The repository still contains the development history from its earlier years.
That means we can compare actual development on the same codebase before generative AI with development today.
One particularly useful period is 2016.
In July 2016, for example, three human contributors added approximately:
22,900 lines of runtime application code
and removed about:
5,700 lines.
That was a productive conventional software team.
Now compare that with recent AI-assisted development.
In June 2026, with one human contributor directing AI agents:
30,800 runtime-code lines were added.
In August, the runtime-code number was lower, about 12,200 additions, but something else 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
The test number is particularly important.
The old development history contains nowhere near that level of automated verification.
AI is not merely writing application code faster. It is making previously expensive engineering work, especially extensive automated testing, cheap enough that I routinely ask for much more of it.
The productivity multiplier is real, but it isn’t 10x
If I normalize the historical development periods by active human contributor-month, the current AI-assisted workflow produces roughly:
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 a much more believable number than the 10x or 20x claims commonly thrown around.
And it describes only application-code production.
It does not capture the additional test automation, QA work, migration verification and operational work that AI is also doing.
So my current estimate is that the engineering capacity of my one-person-plus-agents setup is roughly equivalent to a conventional pre-generative-AI software team of:
4 to 7 people.
My best single estimate would be around five or six.
Very roughly, that capacity might traditionally 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 does not mean that AI has “replaced six developers.”
That interpretation would be too simplistic.
What it means is that one person can now operate at an engineering capacity that, on this particular product, would previously have implied a small software team.
Those are not the same claim.
But does all that code actually ship?
There is another problem with productivity measurements.
It is easy to create software quickly.
It is harder to create software quickly without breaking production.
So I reconstructed the actual MachDuDas production-deployment history and applied DORA-style software delivery metrics.
This is where the experiment became much more interesting.
Change lead time
Across a large set of commits for which 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.
That initially looked less impressive than the development velocity.
Then I separated the most recent work.
For deployments from mid-September onward, median commit-to-production lead time fell to roughly:
11 hours.
The 75th percentile was about:
3 days.
So the development system had changed.
Earlier work was accumulating in large branches, particularly around a major frontend migration and parity project.
Once those large batches started clearing, the actual delivery loop became dramatically shorter.
Deployment frequency
Over the six-month period I reconstructed, MachDuDas averaged approximately:
one production deployment every 6.8 days.
That is roughly weekly.
But again, the recent period looks different.
Between September 14 and September 22, there were:
seven production deployments in nine days.
So deployment frequency has moved from roughly weekly toward several times per week.
Change failure rate
I also reconstructed production incidents and tried to distinguish between:
- failures actually caused by deployments
- unrelated infrastructure problems
- staging failures
- normal later improvements
That distinction matters.
For example, an nginx outage is not necessarily a failed software change.
Using the strictest interpretation, there was one clearly documented production regression caused by a deployment during the relevant period.
That gives a change failure rate of approximately:
3.7%.
There is another earlier incident that is 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 is more interesting to me than the LOC number.
Recovery time
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 sufficient to place observed deployment-caused recovery inside:
less than one day.
There were no observed executed rollbacks in the reconstructed period.
Rework
I also looked for production deployments whose primary purpose was repairing a problem introduced by earlier deployment work.
Depending on how conservatively the incidents are classified, approximately:
7% to 11% of deployments were rework.
Again, this matters more than how many lines an agent can produce.
An AI system that writes 100,000 lines and forces humans to spend the next month repairing them is not productive.
That is not what appears to be happening here.
What actually changed
The most important conclusion from this exercise is not that AI writes code quickly.
That part is obvious.
The more interesting observation is that the bottleneck moved.
Ten years ago, implementation itself was expensive.
A feature required human time for:
- 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 cheap.
I can ask an agent to investigate a legacy behavior, implement a change, write unit tests, create browser tests, test migration idempotency, inspect edge cases, update documentation and review its own implementation.
That does not make engineering free.
It changes where the scarce resource is.
The scarce resource increasingly becomes:
judgment.
What should the system actually do?
Is the agent solving the right problem?
Has it invented unnecessary abstractions?
Is a behavioral difference intentional?
Should this branch be merged?
Should this deployment happen?
Is this test proving something useful, or merely encoding the agent’s own assumptions?
Those decisions still need a human.
I discovered another bottleneck: batch size
One of the largest recent MachDuDas initiatives accumulated more than 60 commits on a feature branch.
The implementation work was progressing extremely quickly.
But the branch itself became large.
That creates a strange situation.
AI makes code generation so fast that it becomes possible to generate changes faster than they can comfortably be reviewed, integrated and released.
In traditional software development, developers were often waiting for implementation.
In AI-heavy development, implementation can instead start waiting for acceptance.
That is a different engineering-management problem.
The answer is probably not to ask the agents to slow down.
It is to keep work smaller.
Smaller stories.
Smaller branches.
Shorter-lived branches.
More frequent integration.
More frequent production releases.
The traditional recommendation to reduce batch size becomes more important when code itself becomes cheap.
AI also changes what “good testing” means
The test numbers surprised me.
In one month, AI-assisted development added more than 70,000 lines of tests.
I would never have commissioned that amount of manual test-writing effort from a small conventional team.
It would have been economically irrational.
But the marginal cost is now dramatically lower.
That changes the engineering tradeoff.
Historically, teams had to decide how much testing was worth paying humans to write.
Now I can ask:
“Can we prove this behavior?”
If the answer is yes, the agent can often create that proof at relatively low incremental cost.
That means AI may increase code volume partly because it changes what is economical to verify.
This is another reason why comparing raw LOC between 2016 and 2026 is misleading.
Thirty thousand lines of application code and seventy thousand lines of tests is not equivalent to one hundred thousand lines of application complexity.
What I would not conclude from this
I would not conclude that one AI-assisted founder can replace every six-person engineering team.
The experiment does not show that.
MachDuDas has characteristics that make AI particularly effective:
It is an existing product with a large amount of behavior already encoded in software.
There is substantial historical context to inspect.
I know the product and can make decisions quickly.
There is almost no organizational communication overhead.
Agents can work directly against the repository.
And many tasks involve software construction, migration, testing and verification, areas where current models are particularly useful.
A six-person startup building an entirely new product also performs discovery, customer research, design, strategy, internal communication and hundreds of informal decisions that do not appear in Git.
AI does not make all of that disappear.
There is also a measurement problem
One useful outcome of this exercise was discovering how easy it is to produce impressive but meaningless AI-productivity statistics.
My first estimate suggested something like a 12 to 15 person team.
That estimate was based largely on historical industry LOC productivity.
It was wrong.
Once I compared against the actual MachDuDas development history, the estimate fell to roughly 4 to 7 people.
That is still a substantial multiplier.
But it is much more defensible.
This is why I would be skeptical of almost every statement of the form:
“AI made our developers 10x more productive.”
Ten times what?
Measured how?
Did it reach production?
How often did it break?
How much of it was generated code?
How much was testing?
How much was later deleted?
What happened to lead time?
What happened to failure rate?
Without those answers, the number means very little.
Where I landed
For MachDuDas, I think the evidence currently supports the following 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.
And importantly, the additional throughput has not obviously destroyed delivery quality.
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 figures will change as more data accumulates.
But they already tell a more useful story than LOC alone.
The real implication for founders
For me, the biggest change is not that I can type code faster.
I barely care about that.
The important change is that maintaining and substantially evolving a non-trivial software business no longer necessarily implies building a conventional engineering organization around it.
A founder with sufficient technical understanding 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 of an individual programmer and more of 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 based on my experience with MachDuDas, that is increasingly where the real leverage, and the real bottleneck, sits.