| ▲ | oudlys 7 hours ago |
| Productivity is not value. It's quite possible for you to experience productivity improvements, and actual value to not be created. That is what I think the most robust data is showing. https://unessays.substack.com/p/talk-is-cheap |
|
| ▲ | amatheus 5 hours ago | parent | next [-] |
| From an economic perspective productivity is defined as the creation of value isn't it? Then if you "improve productivity" and does not create value in the end you're no improving productivity at all. |
| |
| ▲ | oudlys 5 hours ago | parent | next [-] | | It does depend on how you define productivity. But the way it's commonly used is "I'm going faster, personally, with these tools." The thing people I think have a hard time seeing is that "I go faster" does not mean "more features get finished". It's a scale issue, and one scale is better than the other. People only pay for finished features, they do not pay for how much code you emit. | | |
| ▲ | fl4regun 3 hours ago | parent [-] | | economists define productivity as gdp per hour worked. Like a lot of other economic measurements, its mostly a bogus number people use as an argument on why their politics are better than someone elses politics. You can have an efficient business located in a poor country making the same product and same quality as that same business in a rich country, the rich country will be more "productive" because local cost of goods is higher there (i.e. a restaurant in NYC is more "productive" than a restaurant in bangladesh). | | |
| ▲ | oudlys 3 hours ago | parent [-] | | Sure. But that's not, in my view, how most people use the word productivity when describing LLM use. In my field - operations - productivity is usually described as some rate of production for a specific asset. 100 widgets / machine / hour - for example. "My productivity is 3 PRs / day with the LLM as opposed to 1 PR per every three days". That's how I think people are thinking about it. My point is that's not the same thing as value. I.e. what people will pay for. | | |
| ▲ | fl4regun 3 hours ago | parent [-] | | You're correct, I just wanted to add that there is another definition that you may see used online, and it is very specific, and it's important to be aware it's NOT exactly the same thing most normal people mean when they say "productivity". |
|
|
| |
| ▲ | w29UiIm2Xz 4 hours ago | parent | prev [-] | | Productivity is defined revenue per worker hour. And we know worker hours are going down as there are fewer workers with the layoffs. |
|
|
| ▲ | bigstrat2003 7 hours ago | parent | prev | next [-] |
| Also, supposed productivity gains are dubious. I personally experience at best no productivity gains when using LLMs to write code, and sometimes it's an active drain on my productivity. There was that one study a year or so ago showing similar results. People are trying to say the productivity gains are there and undeniable, but that is not true. It is very much a subject of controversy whether AI helps productivity. |
| |
| ▲ | asdfasgasdgasdg 7 hours ago | parent [-] | | I can see an argument that the productivity gains are illusory / don’t translate to economic productivity. I’m not denying the possibility. However, most of the engineers I respect have gone from being skeptics a year ago to convinced today. I don’t personally know any true holdouts any more. If there are studies that disprove productivity gains more than six months ago, I’m happy to believe that it was true of the AIs that were available at the time. But I’m going to need something much more recent before I disbelieve my lyin’ eyes where it pertains to the AIs available today. | | |
| ▲ | oudlys 7 hours ago | parent | next [-] | | There is an observational study that was published in March 2026 that followed 4000 teams over 2 years. It shows, in my view, exactly that the productivity gains don't translate into economic value. Here is the report: https://www.faros.ai/blog/ai-acceleration-whiplash-takeaways And my commentary: https://unessays.substack.com/p/talk-is-cheap | | |
| ▲ | asdfasgasdgasdg 3 hours ago | parent [-] | | If it was published in March 2026, even if the data was collected up to the day the study was published, 7/8ths of it would fail my “within the last six months” test. But I am looking forward to the results of future studies on this topic! | | |
| ▲ | oudlys 2 hours ago | parent [-] | | I get wanting to wait for more data. And thinking that LLMs have improved enough that this will change. My view is that it's not really about how good the models are - it's about how we're using them. Understanding what you've built is an important part of value creation, and LLMs eliminate that. |
|
| |
| ▲ | dminik 5 hours ago | parent | prev | next [-] | | Its funny, I've noticed the same thing, but did not come to the same conclusion. I currently don't have work access to Claude Code, but most of my teammates do. Watching from the outside, the cycle seems to look like this: 1. Experience some success, which hooks you into relying on AI. 2. The AI keeps failing at some task, but you don't want to stop. Keep trying over and over again. 3. Run out of tokens and take a break. Now, sometimes 1 doesn't happen. Sometimes 2 doesn't happen. 3 is a certainty though. Now, if you told me that the productivity gain from 1 is enough to offset the loss from 2 and 3, I could believe you. But I also wouldn't be surprised if it didn't. | | |
| ▲ | chillacy 4 hours ago | parent [-] | | As I work with Claude more and gain a feel for its capabilities, I tend to run into 2 far less often, as I'll decompose my messages more for the current model limitations. The threshold also changes each release. |
| |
| ▲ | techblueberry 2 hours ago | parent | prev [-] | | I’m going back to being a holdout, but it’s nuanced - My theory into why LLMs don’t lead to the colloquial definition of productivity would be something like - if code was never the bottleneck than generating code faster doesn’t result in more meaningful output. Even if you take for granted that AI is as good as the best people say in writing code. And Ive spent a lot of time generating codes, I won’t disagree - Then the question becomes - does this change your daily incentives such that you reach for code as the solution to your problems rather than something else (coordinating with your colleagues? Product management? Planning and Design? So from a holistic perspective, I think intentionally limiting your own AI usage is the best approach for maximum long-term productivity. |
|
|
|
| ▲ | nyeah 7 hours ago | parent | prev [-] |
| That's possible, sure. But I think the answer is more likely in the numbers, not in just qualitatively saying AI isn't worth anything. Like if I pay $30k for an ounce of gold, I got value. Gold is worth something. But that amount of gold wasn't worth what I spent. EDIT: In fact, parent comment has a link to some numbers. [EDIT: Most] people don't want to go through the numbers. Ok. But there's a history here. When people don't want to see the numbers, certain kinds of things tend to happen. |
| |
| ▲ | oudlys 7 hours ago | parent [-] | | I've posted numbers that indicate that productivity is becoming decoupled from value delivery. If you follow the link in my comment it reviews a pretty robust study of 4000 teams over 2 years. There is no product throughput increase. | | |
| ▲ | d33d 6 hours ago | parent | next [-] | | Yep. Code acceleration is great, but.... something precedes that. Vision and strategy re. expansion of offerings and businesses. Once a firm reaches maturity in what it offers and is only touching the edges - this code acceleration is literally useless when you factor in all of the trade-offs. This is a good thing - it means fat and slow incumbents are sitting ducks to be out-witted by creative and imaginative founders, which is healthy for a well-functioning economy. Now the economics of existing frontier models are not sustainable - its looking like a mix of the airline (supersonic vs subsonic) and EV industry with China in the background providing decent offerings at much lower prices. | | |
| ▲ | oudlys 4 hours ago | parent [-] | | I think its worse than that. I admit that if a small team or an individual uses an LLM, it's likely they can create value faster. I think as soon as you don't own the responsibility for the defects you generate with an LLM, their use starts to destroy value. Regardless of product maturity. This is what I think the data says. https://unessays.substack.com/p/talk-is-cheap | | |
| ▲ | nyeah 3 hours ago | parent | next [-] | | Yeah this part scares me a little. I imagine it scares everyone who is more than a couple of years out of school. I hear that "the solution to LLM tech debt is more LLM." That might be true, but it might not be. | | |
| ▲ | oudlys 3 hours ago | parent [-] | | It scares me too. I actually think this is precisely the reason LLMs can't be the basis for a technological revolution. Because it's only one way. Like, if you have a compiler, and it has a bug. You can discover if that bug is influencing your code execution and patch it. You can go both up and down the stack. With LLMs, there is no way to patch it's translation function. You have to rely on it to forward process. I don't think there is any way to avoid us understanding our tech stacks. |
| |
| ▲ | d33d 3 hours ago | parent | prev [-] | | You're not really getting it. If you are producing something that delivers a far better experience, irrespective of what's under the hood (see Claude Code et al), you will decimate an incumbent who is trying to use LLMs in the context of incrementally improving a mature product. LLMs are suited for the development of revolutionary innovation, not incremental. | | |
| ▲ | oudlys 3 hours ago | parent [-] | | I think we mostly agree. I think I just disagree about the power of the LLM to deliver revolutionary innovation. That's something you do. Not the machine. And, pretty soon on your journey to scale, the LLM becomes a hinderance rather than a help. |
|
|
| |
| ▲ | nyeah 6 hours ago | parent | prev [-] | | Interesting data, thanks. |
|
|