This goes back before AI, with computers not being found to be improving productivity numbers: Solow's paradox.
* https://en.wikipedia.org/wiki/Productivity_paradox
* https://www.brookings.edu/articles/the-solow-productivity-pa...
One of the problems here is that things like this only count as "increased productivity" in the economic sense if it results in more income at the end of the funnel. Are you actually making more product faster in all your new-found free time?
Very few orgs I've worked in have actually been limited by the speed of programmers writing code. Usually it's communication overhead and management processes eating up most of the bandwidth - and those tend to expand to absorb any additional bandwidth.
Look at all the shit github README before llm. Most repos didn't bother because it was effort. those few that did, were because of autistic focus. Of those, very few were "great" user documentation.
now llms are here, the effort barrier is gone, and now we're inundated with shit README that provide no value to users nor respect their time.
Once you start applying SKILL.md that revolve around fixing HOW to communicate value to users in a way that respects their time, you'll see this story change in noticeable places.
I doubt it will change everywhere because it also requires that you give a shit about doing this in the first place, so those people Ed Zitron talks about... business idiots won't care, because they're ultimately nihlist.
This strikes me as a problem with how we define productivity in this context. If I can do my job in 1 hour, when it took me 8 before, am I not more productive in a rate-based sense? Sure, I might only work 5 hours in a week instead of 40, so my net production is the same, but my rate of productivity was certainly much higher.
It's like "work" meaning one thing to a normal person, but something very specific and counterintuitive in Newtonian physics (if you carry a fifty-pound weight in a circle and stop at your starting point, you've done no work).