The link in the last paragraph provides some data to back up the claim. https://mikelovesrobots.substack.com/p/wheres-the-shovelware... - If the goal is to increase the rate of software production, there isn't much evidence that AI has moved the needle.

Sure, code gen is faster now. And the industry might finally be waking up to the fact that writing code is a small part of producing software. Getting infinitely faster at one step doesn't speed up the overall process. In fact, there's good evidence it that rapid code gen actually slows down other steps in the process like code review and QA.

Strongly agreeing with this comment…

I realized early on in my enterprise software job that if I produce code faster than average for my team, it will just get stuck in the rest of our review and QA processes; it doesn’t get released any faster.

It feels like LLM code gen can exacerbate and generalize this effect (especially when people send mediocre LLM code gen for review which then makes the reviews become painful).

One alternative explanation to the lack of shovelware, people are deploying software at an individual level. Perhaps millions of new people are using vibe code tools to build tools that are personalized and folks aren’t interested in trying to sell software (the hardest part of many generic saas tool is marketing/etc)

Perhaps looking at iOS, steam, and android release is simply not a great measure of where software is headed. Disappointing that the article didn’t think go a little more outside the box.

The Goal was written 40 years ago and talks about, among other things, the paradox/illusion of local optima. This isn't new, AI coding assistants are at some level just another NCX-10. This isn't a book recommendation thread, but I highly recommend that book to anyone, even if you've read its IT equivalent, The Phoenix Project.

> This was unsettling. It was impossible not to question if I too were an unreliable narrator of my own experience. Was I hoodwinked by the screens of code flying by and had no way of quantifying whether all that reading and reviewing of code actually took more time in the first place than just doing the thing myself?

I don’t understand why this was so surprising to people. People are _terrible_ at self-reporting basically anything, and “people think it makes them mildly more productive but it actually makes them mildly less productive” is a fairly common result for ineffective measures aimed at increasing productivity. If you are doing a thing that you believe is supposed to increase productivity, you’ll be inclined to think that it is doing so unless the result is dramatically negative.

> And the industry might finally be waking up to the fact that writing code is a small part of producing software.

[Parts] of the industry are very aware of the fact, and have been for decades. In fact there was a book on the subject. You probably already are well aware of it. It's "The mythical mean month" by Fred Brooks.

He didn't have to contend with AI's of course, but the underlying driver was the same. He wanted to speed up writing software. Specifically OS/360, a new operating system for IBM, on which Brooks was a project manager. It was badly late, so they tried the obvious tactic on throwing go hordes of programmers at it. I doubt money was a problem, so the said programmers would have been good at their job. Those programmers weren't AI's of course, but the reasoning behind the move seems to be the same as here: OS/360 is just code, therefore the faster you can produce code the faster it will be delivered.

Brooks Law [0] summarises what he believes happened to OS/360: "Adding manpower to a late software project makes it later." Which is doesn't sound too different to the experiences mentioned here: AI's supplying tens of thousands of lines to a large software project that is well outside of their context window to understand is a hindrance, not a help.

Interestingly, that doesn't contradict the experiences reported by people vibe small projects, who say it is much faster. We had a term for difference between the two types of development back in the day: programming in the small vs programming in the large. It seems to have largely disappeared from the vernacular now. Pity, as I think it sums up where AI coding works and where it doesn't.

And it had same disconnect between the two groups, as we see between the vibe coders and the rest. People who spend their lives coding in the small have no idea what people programming in the large do all day. To them, people working on large projects seem to spend an inordinate amount of time producing very little code.

[0] https://en.wikipedia.org/wiki/Brooks%27s_law

> And the industry might finally be waking up to the fact that writing code is a small part of producing software.

Typing code and navigating syntax is the smallest part. We're a solid 30 years into industrialized software development. Better late than never?

Could it be that while there may not be an increases in the raw number of apps released, there's more functionality within existing apps?

I say this because I've had my own app for years and I am now using AI more and more to add features I wouldn't have attempted before (and a lot of UI enhancements)... but I haven't made a new domain name or anything.

>>In fact, there's good evidence it that rapid code gen actually slows down other steps in the process like code review and QA

Luckily there is a solution, quite popular nowadays: layoff QA team and say developers should test themselves. Couple with rubber stamping merge requests and now you have higher velocity. All development metrics are up!

What about this data https://innovationgraph.github.com/global-metrics/git-pushes

The graphs that this article uses as sources for app store releases are just stock images from Statistica and not the real numbers - looks like that's hidden behind a paywall.

The reason I think so is because I wanted to write a follow-up post, and checked the numbers - for instance, the graph for the Play Store peaks at 140000 app released per month, but all the references I found on the internet were much lower.

I then hunted around for other sources of app store data and found appfigures, which had a free trail. I did a bit of querying and I am seeing a noticeable uptick in number of apps released since around March 2025 (from around 20000 to 35000 for Google and 17000 to 30000 for iOS).

In terms of new GITHUB public repositories, the numbers look correct - so I agree with them there - no uptick in new open source repos in the AI era so far.

The curse of Amdahl’s Law. You can only speed up a process so much by optimizing only one part, so if writing code is 10% of the process, the largest speed up you can get is 1.11. Even if it is 50% of the process, the largest speed up is 2x.

Amdahl's Law in action.

> If the goal is to increase the rate of software production, there isn't much evidence that AI has moved the needle.

There is only one thing that triggers growth and it is demand. When there's a will, there's a way. But if there's no additional will, new ways won't bring any growth.

Basically AI will show up on the first future spike of demand for software but not before.

My software output increased by manyfold. But none of the software AI wrote for me shows up on the internet. Those are all internal tools, often one off, written for specific task, then discarded.

In my experience of using AI for development, the development speed is exactly the same as before. What you gain in letting AI writing some simple rote tasks, you lose by increased debugging and wasting time with sycophantic enthusiastic suggestions that turn out to be totally wrong two hours later. It's kind of infuriating because AI is so useful when it works, yet wastes your time in the worst way when it doesn't.

Lol. Rapid “code gen” can slow down the process. Some of the best programmers have negative productivity when joining existing projects if you measure it by lines of code added.

Simplicity is harder than complexity. I want to tattoo this on my forehead.

Huge amounts of poor quality code is technical debt. Before LLMs you frequently saw it from offshore lowest bidder operations or teams of very junior devs with no grey beards involved.