{"slug": "what-ai-actually-did-to-my-software-development-velocity", "title": "What AI Actually Did to My Software Development Velocity", "summary": "A solo developer running the German marketplace MachDuDas measured AI coding agents against the same codebase's pre-generative-AI history, finding roughly 2.4x runtime-code output per active human contributor (about 3.2x excluding a 2016 repository-import period) rather than the 10x-20x figures commonly claimed. The developer estimates the one-person-plus-agents setup matches the engineering capacity of a conventional four-to-seven-person team, with test code growing far more than application code.", "body_md": "A lot of AI productivity claims sound impressive until you ask what was actually measured.\n\n\"10x developer productivity\" usually means one of three things:\n\nThose are weak signals.\n\nLines of code are easy to inflate. Benchmarks are not production systems. And generating code quickly is not the same as shipping working software safely.\n\nI wanted a better answer for my own work.\n\nI 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.\n\nToday, I am effectively the only human driving development, but I work heavily with AI coding agents.\n\nThat gave me something close to a natural experiment:\n\nSame product. Same codebase. Different development model.\n\nThe question was simple:\n\nHow much engineering capacity have AI agents actually given me?\n\nMy first instinct was to look at code volume.\n\nOver roughly 30 days of recent development, MachDuDas had:\n\n`master`\nThat looked like about 10,000 net lines per week.\n\nIf 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.\n\nThat comparison failed the smell test.\n\nThe reason is obvious once you inspect the work.\n\nAI-assisted development produces a lot of supporting code:\n\nThat code is valuable and cannot be compared reliably with generic historical LOC benchmarks.\n\nA line of application logic, a line of fixture data, and a line of browser-test setup are not the same productivity unit.\n\nSo I stopped comparing MachDuDas to generic industry averages.\n\nI compared it to itself.\n\nThe MachDuDas repository still contains older development history.\n\nThat means I can compare current AI-assisted development against earlier conventional development on the same product.\n\nOne useful period was July 2016.\n\nDuring that month, three human contributors added approximately:\n\nThey also removed about:\n\nThat was a productive conventional team working on the same software product.\n\nNow compare that with recent AI-assisted development.\n\nIn June 2026, one human contributor directing AI agents added approximately:\n\nIn August 2026, runtime-code additions were lower:\n\nBut test code exploded:\n\nAcross March through September 2026, MachDuDas accumulated approximately:\n\nThat test number matters.\n\nThe older history does not contain anything close to that amount of automated verification.\n\nThe fuller story includes:\n\nAI makes certain kinds of engineering work cheap enough that I ask for much more of them.\n\nEspecially testing.\n\nWhen I normalized the historical periods by active human contributor-month, the current AI-assisted workflow produced about:\n\n**2.4x the runtime-code output per active human contributor.**\n\nIf I exclude the initial large 2016 repository-import period, the multiplier is closer to:\n\n**3.2x.**\n\nThat is much less dramatic than the 10x or 20x claims people like to throw around.\n\nIt is also much more believable.\n\nAnd it only covers application-code production.\n\nThe estimate also excludes extra automated QA, migration verification, operational work, and test-writing produced by agents.\n\nMy current estimate is that my one-person-plus-agents setup has engineering capacity comparable to a conventional pre-generative-AI software team of roughly:\n\n**4 to 7 people.**\n\nMy best single estimate would be around **five or six**.\n\nVery roughly, that conventional team might have looked like:\n\nThis is an engineering-capacity comparison. Literal replacement of six developers is too simplistic.\n\nIt 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.\n\nThose are different claims.\n\nThe next question is more important:\n\nDid the code actually reach production without making the product worse?\n\nSo I reconstructed MachDuDas production deployments and applied DORA-style delivery metrics.\n\nThe goal was to look beyond code generation and measure the delivery system:\n\nThis changed the picture.\n\nAcross 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:\n\n**6.8 days.**\n\nThe 75th percentile was about:\n\n**9.2 days.**\n\nAt first, that looked much less impressive than the development velocity.\n\nThen I separated the most recent deployments.\n\nFrom mid-September onward, the median commit-to-production lead time fell to roughly:\n\n**11 hours.**\n\n**3 days.**\n\nThe system had changed.\n\nEarlier 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.\n\nThis is an important lesson for AI-heavy development:\n\nFast implementation does not automatically create fast delivery.\n\nYou can generate code faster than you can review, integrate, and release it.\n\nOver the six-month period I reconstructed, MachDuDas averaged approximately:\n\n**One production deployment every 6.8 days.**\n\nThat is roughly weekly.\n\nBut the recent period looked different.\n\nBetween September 14 and September 22, there were:\n\n**Seven production deployments in nine days.**\n\nSo deployment frequency moved from roughly weekly toward several times per week.\n\nThat is the kind of signal I care about more than raw LOC.\n\nIf AI only creates larger branches that sit around longer, the productivity gain is partially trapped.\n\nIf it helps produce smaller changes that reach production safely, the gain is much more real.\n\nI also reconstructed production incidents and separated them into categories:\n\nThat distinction matters.\n\nAn nginx outage, for example, is not automatically a failed software change.\n\nUsing the strictest interpretation, I found one clearly documented production regression caused by a deployment during the relevant period.\n\nThat gives a change failure rate of approximately:\n\n**3.7%.**\n\nThere was another earlier incident that was very likely deployment-related. Including that one raises the estimate to:\n\n**7.4%.**\n\nSo the defensible range is approximately:\n\n**4% to 7%.**\n\nGiven the amount of software changing, that number is more meaningful to me than how many lines the agents wrote.\n\nThe earlier likely regression was hotfixed in about:\n\n**13 minutes.**\n\nThe later confirmed deployment regression was remediated within approximately:\n\n**15 hours.**\n\nThe historical evidence is not precise enough to claim an exact median recovery time.\n\nBut it is enough to say observed recovery from deployment-caused failures was within:\n\n**Less than one day.**\n\nThere were no observed executed rollbacks in the reconstructed period.\n\nI also looked for production deployments whose primary purpose was repairing a problem introduced by earlier deployment work.\n\nDepending on how conservatively incidents are classified, approximately:\n\n**7% to 11% of deployments were rework.**\n\nThat is an important guardrail.\n\nAn AI system that writes 100,000 lines and forces humans to spend the next month repairing them is not productive.\n\nHere, the evidence shows high output alongside acceptable delivery quality.\n\nThe most important conclusion is that the bottleneck moved as implementation became cheap. Fast code generation is already obvious.\n\nThe more interesting change is that the bottleneck moved.\n\nTen years ago, implementation itself was expensive.\n\nA feature required human time across many layers:\n\nEvery additional layer consumed scarce engineering hours.\n\nToday, many of those activities are much cheaper.\n\nI 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.\n\nEngineering still carries real costs. The scarce resource moves.\n\nThe scarce resource is increasingly judgment.\n\nSomeone still has to decide:\n\nThose are still human decisions.\n\nOne of the largest recent MachDuDas initiatives accumulated more than 60 commits on a feature branch.\n\nThe implementation work was moving quickly.\n\nBut the branch became large.\n\nThat creates a strange failure mode.\n\nAI can generate changes faster than they can comfortably be reviewed, integrated, and released.\n\nIn traditional development, teams often waited for implementation.\n\nIn AI-heavy development, implementation can start waiting for acceptance.\n\nThat is a different engineering-management problem.\n\nThe practical response is to keep the work smaller:\n\nThe old advice to reduce batch size becomes more important when code generation gets cheap.\n\nThe test numbers surprised me.\n\nIn one month, AI-assisted development added more than 70,000 lines of tests.\n\nI would not have commissioned that amount of manual test-writing effort from a small conventional team.\n\nIt would have been economically irrational.\n\nBut if the marginal cost of test creation drops, the tradeoff changes.\n\nThe question becomes less:\n\n\"Is this worth paying a human to test manually?\"\n\nAnd more:\n\n\"Can we prove this behavior?\"\n\nIf the answer is yes, an agent can often create that proof at relatively low incremental cost.\n\nThis is another reason raw LOC comparisons are misleading.\n\nThirty thousand lines of application code plus seventy thousand lines of tests is not the same thing as one hundred thousand lines of application complexity.\n\nSome of that volume is verification that previously would not have existed at all.\n\nIf you are trying to evaluate AI-assisted development in your own team, start with delivery outcomes before \"lines of code generated.\"\n\nI would start with these questions.\n\nDo not compare your team to generic productivity benchmarks if you have better data.\n\nYour own repository history is a stronger baseline.\n\nSame product. Same domain. Similar architectural constraints.\n\nApplication code, tests, migrations, fixtures, and operational scripts should not all be treated as the same output.\n\nThey all matter, but they mean different things.\n\nIf you want to estimate human capacity, normalize by the humans actively involved.\n\nOtherwise you are just comparing busy periods with quiet periods.\n\nMeasure whether the work reaches production.\n\nUseful metrics include:\n\nAI can make large branches deceptively easy to create.\n\nLarge branches remain hard to review and risky to ship.\n\nIf lead time gets worse while code output improves, batch size is a likely suspect.\n\nAI-generated tests can be very valuable.\n\nKeep test volume separate from runtime code volume.\n\nLarge test additions may reflect improved verification without enlarging the product surface.\n\nGeneralizing this into a claim that one AI-assisted founder can replace every six-person engineering team would exceed the evidence.\n\nMachDuDas has characteristics that make AI particularly effective:\n\nA six-person startup building a new product is doing more than writing code.\n\nIt is also doing discovery, customer research, design, strategy, internal communication, and countless informal decisions that do not appear in Git.\n\nThose responsibilities still require human judgment.\n\nFor MachDuDas, the evidence currently supports this conclusion:\n\n**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.**\n\nOnce automated QA, testing, migration work, and release engineering are included, the overall engineering capacity appears comparable to roughly:\n\n**A 4 to 7 person conventional software team.**\n\nDelivery quality remained stable enough to make the additional throughput useful.\n\nRecent production delivery has reached:\n\nThose numbers will change as more data accumulates.\n\nBut they tell a more useful story than LOC alone.\n\nThe biggest change is the amount of software business one technical founder can now maintain and substantially evolve. Typing speed barely matters to me.\n\nA technical founder can now direct a collection of AI agents that investigate, implement, test, and verify software across multiple layers of a system.\n\nThe founder becomes less like an individual programmer and more like a very small engineering organization.\n\nBut somebody still has to run that organization.\n\nSomeone has to maintain the model of what the product is supposed to do.\n\nSomeone has to notice when an agent is technically correct but solving the wrong problem.\n\nSomeone has to decide what goes into production.\n\nSomeone has to say no.\n\nFor now, that is still the human job.\n\nAnd in my experience, that is where the real leverage now sits.", "url": "https://wpnews.pro/news/what-ai-actually-did-to-my-software-development-velocity", "canonical_source": "https://dev.to/samiralibabic/what-ai-actually-did-to-my-software-development-velocity-55jg", "published_at": "2026-09-24 17:29:40+00:00", "updated_at": "2026-09-24 17:59:26.193847+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["MachDuDas"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/what-ai-actually-did-to-my-software-development-velocity", "markdown": "https://wpnews.pro/news/what-ai-actually-did-to-my-software-development-velocity.md", "text": "https://wpnews.pro/news/what-ai-actually-did-to-my-software-development-velocity.txt", "jsonld": "https://wpnews.pro/news/what-ai-actually-did-to-my-software-development-velocity.jsonld"}}