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).

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.

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.

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

> 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.

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.

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.

Is the name of the movie 'The Goal'? A rather search proof title if so.

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

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.

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.

This is at least a little bit true for me. Examples:

https://github.com/epiccoleman/scrapio

https://github.com/epiccoleman/tuber

These are both projects which have repeatedly given me a lot of value but which have very little market mass appeal (well, tuber is pretty fuckin' cool, imho, but you could just prompt one up yourself).

I've also built a handful of tools for my current job which are similarly vibe coded.

The problem with these kinds of things from a "can I sell this app" perspective are that they're raw and unpolished. I use tuber multiple times a week but I don't really care enough about it to get it to a point where I don't have to have a joke disclaimer about not understanding the code. If one of my little generated CLIs or whatever fails, I don't mind, I still saved time. But if I wanted to charge for any of them I'd feel wrong not polishing the rough edges off.

Loved scrapio idea, gonna try it out. It sounds like a clear example of a vibe-code-tier tool, no need to get the fancy programmers bois to implement something like this, just something quick and dirty. Also a fan of the quirky text in both repos, eg. "you can just get a printout of the eleventeen exercises you're not going to do"

Thanks for checking them out! I give myself many small moments of joy with my millenial-ass sarcasm in my docs.

Feel free to email me at the address in my bio if you run into any issues.

You would still expect to see traces of the economic value they were creating elsewhere.

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.

I've mostly seen this done for things where there is no prefect commercial tool because it's a small market.

For example a flight school that I work with has their own simple rental administration program. It's a small webapp with 3 screens. They use it next to a SaaS booking/planning tool, but that tool never replaced their administrative approach. Mainly because it wouldn't support local tax rules and some discount system that was in place there. So before the webapp they used paper receipts and an spreadsheet.

I think the challenge in the future with lots of these tools is going to be how they're maintained and how "ops" is done.

It just doesn't seem that different to me. The difficulty of building and maintaining a 3 screen webapp hasn't changed significantly. Flight schools are a niche sure (and I've been around them; I'm a private pilot) but really all the innovation that lets a flight school own a webapp has nothing to do with AI, it happened in web browsers and in React and lots of investment in abstractions until we made it pretty trivial to build and own a simple webapp.

Somehow AI took over the narrative, but it's almost never the thing that actually created the value that it gets credit for creating.

Are you arguing that the difficulty of producing a fully functioning poc is no different today than 2-3 years ago?!

Personally, I’ve been writing software for 10 years professionally. It is much easier, especially for someone with little coding experience, to create a quite complex and fully featured web app.

It makes sense that ai models are leveraging frameworks like next js/react/supabase, they are trained/tuned on a very clear stack that is more compatible with how models function. Of course those tools have high value regardless of ai. But ai has rapidly lowered the barrier to entry, and allows be to go much much farther, much faster.

No, I'm arguing that it's gotten steadily easier and easier to build high-level projects all the time over the last 20 years. React is obviously a huge part of that. There's a zillion React tutorials out there, so the value of making React accessible to beginners -- once again, that value was not created by AI, but rather by bloggers and youtubers and conversational evangelists.

I also just don't think "going fast" in that sense is such a big a deal. You're talking about frantic speed. I think about speed in terms of growth. The goal is to build sturdy foundations so that you keep growing on an exponential track. Being in a frantic hurry to finish building your foundations is not a good omen for the quality of what will be built on them.

New software may end up being less about legacy foundations and more about bespoke software, fast iteration, throw away single purpose code, etc.

AI is likely to change fundamental paradigms around software design by significantly decreasing the cost of a line of code/feature/bugfix/and or starting from scratch and enabling more stakeholders to help produce software.

3 years ago you throw hundreds of dollars to the Upwork and have an app in result. Nowadays it's much cheaper/faster with LLM, but the difficulty is pretty much the same.

It made the group of people that could do it much larger. A tech savvy person they knew some HTML was not able to create such an app from scratch in an afternoon before AI, it would take them weeks of googling and figuring things out with a high likelihood of getting stuck. Now that same type of person using Claude Code writes an app in an afternoon.

Reading things Claude creates and asking some critical questions is much easier than writing the same code from scratch.

Quality may not be amazing, but this whole thing is less than 2 years old. It's not hard to imagine that quality will go up further and more people will learn to use it well.

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.

I was asking you a specific question and am curious of your answer. The impact of ai “blinding” people isn’t an “economic indicator” and hardly something that has been proven. Of course there are major issues with how people use ai just like any technology.

The aggregate impact isn’t known yet and the tech is still in its infancy.

The economy looks normal-ish in graphs if you don't consider that the graph shows the AI sector thriving while all other sectors are in recession. It's the kind of graph you'd expect to see if there were one sector leeching the life out of all the others.

Where?

Don’t tell my boss but I am producing code much faster than before. I just use most of the extra time for myself

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.

yes, this is also largely how I use it; suiting workflows to my taste in a sort of "artisanal" way. most recent tool is a Windows "omniterminal" for Serial/SSH/SFTP, but there is a handful of bugs and missing wiring left (serial in particular is still in poor shape). 4MB .7z archive; portable binary; Rust source included: https://archivalcopy.com/content/category-utilities/category...

I also agree with comment that it seems silly to try widely releasing something you could just ask an LLM to make. Instead of something taking a team months or years, you can knock out most things in a weekend. I think vibe-coded stuff is best for hobbyists and experimentation.

Amdahl's Law in action.

> 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.

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

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.

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.

> 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.

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.

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).

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.

LLMs have indeed increased developer productivity: now 1 developer with LLM can generate the same amount of technical debt as 100 junior developers.

I have been using AI to remove tech debt faster than ever before.

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........

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.

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.

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.

> 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.

Yes it works for certain people, but the whole premise of the OP is that it isn't working that well for the majority of people. I wonder if you are a manager already or aspire to be one. Because the workflow you describe, I've tried it and I find it exhausting.

I'm a senior, mostly full-stack-web developer, but I also have done some desktop apps and dabbled in other platforms as well. I wrote code for over 20 years in many languages. I never had any aspiration for managing anything or anyone but I was freelancing a lot so I have a good, working understanding of every role in the software development process and I embodied each of those for a bit at one point or another. I never built a complete product out of my own volition, but I have a lot of ideas. However deeply understanding how much work would the implementation take, I was always discouraged. ADHD probably was also a factor.

I lead a team once and wasn't particularly fond of it. For me AI is godsend. It's like being a tech lead and product owner but without having to deal with people and multitude of their idiosyncrasies.

I can understand how AI can't work well for a developer whose work is limited to reading tickets in Jira and implementing them in 3-5 business days, because that's exactly whom AI replaces. I also did that during my career and I liked it but I can see that if all you do at work is swing a shovel you might find it hard to incorporate power digger into your daily work process. But if you can step out a bit it feels great. You can still keep you shovel and chisel nice corners or whatever in places where digger did less than stellar job. But the digger just saves so much work.

Try Antigravity from Google. Not for your daily work. Just to make some stupid side projects that come to your mind, you don't care about, or process some data, make a gui for something, literally whatever, it costs nothing. I hope you'll see what I see.

Let me give you an example of my workflow from tonight:

1. I had two text documents containing plain text to compare. One with minor edits (done by AI).

2. I wanted to see what AI changed in my text.

3. I tried the usual diff tools. They diffed line by line and result was terrible. I searched google for "text comparison tool but not line-based"

4. As second search result it found me https://www.diffchecker.com/

5. Initially it did equally bad job but I noticed it had a switch "Real-time diff" which did exactly what I wanted.

6. I got curious what is this algorithm. So I asked Gemini with "Deep Research" mode: "The website https://www.diffchecker.com/ uses a diff algorithm they call real-time diff. It works really good for reformatted and corrected text documents. I'd like to know what is this algorithm and if there's any other software, preferably open-source that uses it."

7. As a first suggestion it listed diff-match-patch from Google. It had Python package.

8. I started Antigravity in a new folder, ran uv init. Then I prompted the following:

"Write a commandline tool that uses https://github.com/google/diff-match-patch/wiki/Language:-Py... to generate diff of two files and presents it as side by side comparison in generated html file."

[...]

"I installed the missing dependance for you. Please continue." - I noticed it doesn't use uv for installing dependencies so I interrupted and did it myself.

[...]

"This project uses uv. To run python code use

uv run python test_diff.py" - I noticed it still doesn't use uv for running the code so its testing fails.

[...]

"Semantic cleanup is important, please use it." - Things started to show up but it looked like linear diff. I noticed it had a call to semantic cleanup method commented out so I thought it might help if I push it in that direction.

[...]

"also display the complete, raw diff object below the table" - the display of the diff still didn't seem good so I got curious if it's the problem with the diffing code or the display code

[...]

"I don't see the contents of the object, just text {diffs}" - it made a silly mistake by outputting template variable instead of actual object.

[...]

"While comparing larger files 1.txt and 2.txt I notice that the diff is not very granular. Text changed just slightly but the diff looks like deleting nearly all the lines of the document, and inserting completely fresh ones. Can you force diff library to be more granular?

You seem to be doing the right thing https://github.com/google/diff-match-patch/wiki/Line-or-Word... but the outcome is not good.

Maybe there's some better matching algoritm in the library?" - it seemed that while on small tests that Antigravity made itself it worked decently but on the texts that I actually wanted to compare was still terrible although I've seen glimpses of hope because some spots were diffed more granularly. I inspected the code and it seemed to be doing character level diffing as per diff-match-patch example. While it processed this prompt I was searching for solution myself by clicking around diff-match-patch repo and demos. I found a potential solution by adjusting cleanup, but it actually solved the problem by itself by ditching the character level diffing (which I'm not sure I would have come up with at this point). Diffed object looked great but as I compared the result to https://www.diffchecker.com/ output it seemed that they did one minor thing about formatting better.

[...]

"Could you use rowspan so that rows on one side that are equivalent to multiple rows on the other side would have same height as the rows on the other side they are equivalent to?" - I felt very clumsily trying to phrase it and I wasn't sure if Antigravity will understand. But it did and executed perfectly.

I didn't have to revert a single prompt and interrupted just two times at the beginning.

So I basically went from having two very similar text files and knowing very little about diffing to knowing a bit more and having my own local tool that let's me compare texts in satisfying manner, with beautiful highlighting and formatting, that I can extend or modify however I like, that mirrors interesting part of the functionality of the best tool I found online. And all of that in the time span shorter than it took me to write this comment (at least the coding part was, I followed few wrong paths during my search for a bit).

My experience tells me that even if I could replicate what I did today (keeping motivated is an issue for me), it would most likely be multi-day project full of frustration and hunting small errors and venturing into wrong paths. Python isn't even my strongest language. Instead it was a pleasant and fun evening with occasional jaw drops and feeling so blessed that I live in SciFi times I read about as a kid (and adult).

Oh, yeah, I didn't use auto-complete once, because it mostly sucks. ;-)

That works great for a small greenfield project. Now try applying it to a million-line monorepo with three competing architectural patterns and a CI/CD pipeline that breaks if you look at it wrong. The real world of development is much messier

If you have such a beast you have n problems. Not being able to apply AI to it is just (n+1)th.

It works great when dealing with microservices architecture that was all the rage recently. Of course it doesn't solve it's main issue that is that microservices talk to each other but it still lets you sprint through a lot of work.

It's just that if you engineered (or engineer) things well, you get immediate huge benefits from AI coders. But if all you did last decade was throw in more spaghetti into already a huge bowl of spaghetti you are out of luck. Serves you right. The sad thing is that most humans will get pushed out into doing this kind of "real development" so it's probably a good time to learn to love legacy, because you are legacy.

> If you have such a beast you have n problems.

Lol no one needs AI to tell them that!

IMHO, AI can spot errors in an instant when I give it the files. This can be a real time-saver. I also use it as a glorified autocomplete, it's amazingly good at converting programming code in a mechanical fashion, like adding some lines in every function or changing some API.

The problem is that it can give very bad general advise in more complex cases, and it seems to be especially clueless about software architecture. I need to learn to force myself to ignore AI advice when my initial reaction is "Hm, I don't know." It seems that my bullshit detector is better than any AI so far even if I know the topic less good.

>>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!

> 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

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.