8 ms·

The link in the last paragraph provides some data to back up the claim. https://mikelovesrobots.substack.com/p/wheres-the-shovelware-why-ai-coding https://mikel

• decasia 10mo ago
  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).
  • binary132 10mo ago
    So much wasted time debating whether the 1000 lines of generated code are actually necessary when the actual transform in question is 3 of them. “But it works”, goes the refrain.
  • ninkendo 10mo ago
    It doesn’t even need to be the case that the LLM produces worse code. Software development is like a gas that expands to fill its container. If the schedule allows a fixed amount of time before shipping, and the time to write the code shrinks to zero, it just means the other parts of the process will fill the remaining time, even if the LLM did a decent job in the first place.
  • LeChuck 10mo ago
    Theory of Constraints right there. Producing faster than the slowest resource in the chain is detrimental to the entire process. You waste resources and create difficulties upstream. https://en.wikipedia.org/wiki/Theory_of_constraints https://en.wikipedia.org/wiki/Theory_of_constraints
• api 10mo ago
  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.
  • AshamedCaptain 10mo ago
    LLMs have indeed increased developer productivity: now 1 developer with LLM can generate the same amount of technical debt as 100 junior developers.
    • jaxn 10mo ago
      I have been using AI to remove tech debt faster than ever before.
      • lkjdsklf 10mo ago
        Similar here, but most of what I've removed was pointless ai generated code that made it through lazy reviewers. So much dead and useless code generated by these tools... and tens of thousands of lines of worthless tests.. honestly I don't mind it that much... my changed lines is through the roof relative to my peers and now that stack ranking is back........
• mattacular 10mo ago
  > 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?
• deleted 10mo ago
  [deleted]
• maddmann 10mo ago
  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.
  • prymitive 10mo ago
    Looking forward to the “just in vibe” software ecosystem where your entire os is an LLM coding agent that creates a tool you need when you need it.
  • conartist6 10mo ago
    You would still expect to see traces of the economic value they were creating elsewhere.
    • maddmann 10mo ago
      Can you specify? I am personally using ai coding tools to replace subscription tools. While it’s valuable to me, in aggregate it would be a potential decline in economic activity for traditional services (this would only play out years from now in aggregate). We need to keep in mind that good ai coding tools like Claude code or to some extent,lovable, have barely come into existence.
      • conartist6 10mo ago
        AI usually costs you the ability to pursue the right work. It blinds you and it numbs you. It will feed your ego while guiding you to spend your time doing ordinary stuff, the same ordinary stuff it is guiding everyone to do. People just can't see it because they all spend their time talking to AI now instead of talking to each other -- that's the blindness.
        • 10mo ago
• 13415 10mo ago
  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.
  • le-mark 10mo ago
    Is it really that useful though? I spend a lot of my time with ai wondering how much of what I’m reading is BS and how to verify. Some tools make checking easier than others.
    • rjh29 10mo ago
      It's best used as a glorified autocomplete or for refactoring. Autocomplete is useful but coding time is like 10% of development, upfront design / debugging / discussions / testing is a bigger issue. Refactoring needs to be checked as AI can't be trusted, and can end up costing as much time as it saves if it makes mistakes.
      • scotty79 10mo ago
        > glorified autocomplete I feel like people who feel that about AI never really tried it in agentic mode. I disable AI autocomplete. While bringing some value it messes with the flow of coding and normal autocomplete in ways I find annoying. (Although half of the problems would probably disappear if I just rebound it to CapsLock instead of Tab, which is the indent key). But when switched to agentic mode I start with blank canvas and just describe applications I want. In natural language. I tell which libraries to use. Then I gradually evolve it using domain language or software development language whatever fits best to my desires about code or behavior. There are projects where I don't type any code at all and I inspect the code very rarely. I'm basically a project manager and part time QA while the AI does all the development including unit testing. And it unncannily gets things right. At least Gemini 3 Pro (High) does. Sonnet 4.5 occasionally gets things wrong and difference in behavior tells me that it's not a fundamental problem. It's something that gets solved with stronger LLMs.
• pureliquidhw 10mo ago
  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.
  • user_7832 10mo ago
    To add on: if you don't have the patience for the full book, watch the movie, it's not too long. One day in our uni class, the prof played the movie instead of teaching. It is the only class I distinctly remember today in terms of the scope of what it taught me.
    • somenameforme 10mo ago
      Is the name of the movie 'The Goal'? A rather search proof title if so.
      • FrustratedMonky 10mo ago
        add Goldratt the author. "The Goal" is a movie based on Eliyahu Goldratt's best-selling business novel that teaches the principles of the Theory of Constraints
      • user_7832 10mo ago
        Yeah, that's the name. I think it was even on YouTube at some point of time, I bet one of the archival websites has a copy of it.
• scotty79 10mo ago
  > 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.
  • rsynnott 10mo ago
    I don’t think I buy that; in particular, most steam games are not demand driven. They’re mostly created by hobbyists, who do not, and do not expect to, make much money on them.
    • scotty79 10mo ago
      Steam is not super friendly towards AI and who knows what are motivations of those hobbyists. Maybe using AI doesn't sit with majority of them well. I don't think you are gonna see the uptick in published software. At least not until there's money to be made from the additional demand. What you are gonna see instead is drop in sales of published software (probably not games) as people build custom software with AI agents for their personal needs and use instead buying of the shelve products (and SaaS).
• brokensegue 10mo ago
  What about this data https://innovationgraph.github.com/global-metrics/git-pushes https://innovationgraph.github.com/global-metrics/git-pushes
  • rsynnott 10mo ago
    That seems only compelling if you assume that all git pushes are of equal worth. If you instead assume that LLM codegen things push people into smaller PRs (because getting them to do anything big reliably is difficult) or more mistaken PRs which then require more PRs to correct them (anecdotally, it sure _feels_ like everything’s getting a lot buggier) that also scans.
• djeastm 10mo ago
  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.
• rsynnott 10mo ago
  > 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.
• outside1234 10mo ago
  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.
• rwmj 10mo ago
  Amdahl's Law in action.
• ponector 10mo ago
  >>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!
• rstuart4133 10mo ago
  > 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 https://en.wikipedia.org/wiki/Brooks%27s_law
• jacobriers 10mo ago
  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.