Live data from Hacker News

AI adoption and Solow's productivity paradox

fortune.com

541–550 of 783 posts

Re: AI adoption and Solow's productivity paradox

#541
post #467

Earlier quoted context omitted.

Models are fixed. They do not learn post training. Which means that training needs to be ongoing. So the revenue covers the inference? So what? All that means is that it doesn't cover your costs and you're operating at a loss. Because it doesn't cover the training that you can't stop doing either.

Training costs are fixed. Inference costs are variable. The difference matters.

No they are not. They are exponentially increasing. Due to the exponential scaling needed for linear gain. Otherwise they'd fall behind their competition.

Re: AI adoption and Solow's productivity paradox

#542

Earlier quoted context omitted.

So we're suddenly going back into measuring lines of code as a useful metric? Just because people are shitting out endless slop code that they never bothered to throw a 2nd glance at doesn't mean it's good or that it's leading to better projects or tools, it literally just means people are pushing code out haphazardly . If I made a python script that everyone started using and all it did was create a repo, commit a R…

It's not the be all end all and there are obviously issues with using it alone, but it's rather silly going the other extreme and pretending it isn't a major factor. >If I made a python script that everyone started using and all it did was create a repo, commit a README and push it every 5 seconds we'd be seeing 1. Well you can't do that 2. Something like that won't register as Claude Code (or any other AI tool) usag…

> Well you or anyone else can't do that...

But that's what these tools are doing, in a large number of cases? At least the end result is basically the same, like that Clawdbot or whatever name they've decided to try ride the coattails of guy who has 70k commits in the last few months that I saw being touted as an impressive feat on HN the other day. How much broken, unusable code exists within those 70k commits that ultimately would've had the same effect as if he had just pushed a `--allow-empty` commit thousands of times?

Now whatever, if it's people pushing slop into their own codebase that they own, more power to them, my issue stems from OSS projects being inundated with endless spam MR/PRs from AI hypesters. It's just making maintainer's lives more difficult, and the most annoying part of it all is that they have to put up with people who don't see the effort disparity between them prompting their chatbot to write up some broken bullshit vs the effort required for maintainers to keep up with the spam. It hurts the maintainers, it hurts genuine beginners who would like to learn and contribute to projects, it hurts the projects themselves since they have to waste what precious little time and resources they already have digging through crap, it hurts quite literally everyone who has to deal with it other than the selfish AI-using morons who just take a huge dump over everyone and spouts shit like "Well 4% of all code on Github is now AI-generated!" as if more of that is somehow a good thing.

Re: AI adoption and Solow's productivity paradox

#543
post #299

Earlier quoted context omitted.

> I think companies will need fewer engineers but there will be more companies. This would be strange, because all other technology development in history has taken things the exact opposite direction; larger companies that can do things on scale and outcompete smaller ones.

This would be strange, because all other technology development in history has taken things the exact opposite direction; larger companies that can do things on scale and outcompete smaller ones. I don't think this has always been true. Youtube allowed many more small media production companies - sometimes just one person in their garage. Shopify allowed many more small retailers. Steam & cheap game engines allowed m…

That’s an argument for giant companies at scale like Google/YouTube.

Re: AI adoption and Solow's productivity paradox

#544

Earlier quoted context omitted.

Not necessarily. You could have 100 FTE on reports instead of 300 FTE in a large company like a bank. That means 200 people who'd normally go into reporting jobs over the next decade, will go into something else, producing something else ontop of the reports that continue to be produced. The sum of this is more production. Looking at job numbers that seems to be happening. A lot less employment needed, freeing up peo…

Looking at job numbers That is a wild take given the recession we're basically in from bad US policy like tariffs.

I’m not in favor of these tariffs. At all. However, it seems that they haven’t had such an impact yet on the economy, at least regarding consumer prices. You’d expect much larger inflation given the tariffs IIUC.

My current understanding of the general consensus is that many companies have been eating the tariffs with the hope SCOTUS will strike them. If they are upheld, prices will likely rise significantly

Re: AI adoption and Solow's productivity paradox

#545

Earlier quoted context omitted.

[dead]

> This is an underrated take. If you make someone 3x faster at producing a report nobody reads, you've improved nothing In the private market are there really so many companies delivering reports no one reads ? Why would management keep at it then ? The goal is to maximize profits. Now sure there are pockets of inefficiency even in the private sector but surely not that much - whatever the companies are doing - someo…

> In the private market are there really so many companies delivering reports no one reads ? Why would management keep at it then ?

In finance, you have to produce truly astounding amounts of regulatory reports that won't be read... until there is a crash, or a lawsuit, or an investigation etc. And then they better have been right!

Re: AI adoption and Solow's productivity paradox

#546

Earlier quoted context omitted.

Code is much much harder to check for errors than an email. Consider, for example, the following python code: x = (5) vs x = (5,) One is a literal 5, and the other is a single element tuple containing the number 5. But more importantly, both are valid code. Now imagine trying to spot that one missing comma among the 20kloc of code one so proudly claims AI helped them "write", especially if it's in a cold path. You wo…

In my experience the example you give here is exactly the kind of problem that AI powered code reviews are really good at spotting, and especially amongst codebases with tens of thousands of lines of code in them where a human being might well get scrolling blindness when quickly moving around them to work.

The AI is the one which made the mistake in the first place. Why would you assume it's guaranteed to find it?

The few times I've tried giving LLMs a shot I've had them warning me of not putting some validations in, when that exact validation was exactly 1 line below where they stopped looking.

And even if it did pass an AI code review, that's meaningless anyway. It still needs to be reviewed by an actual human before putting it into production. And that person would still get scrolling blindness whether or not the ai "reviewer" actually detected the error or not.

Re: AI adoption and Solow's productivity paradox

#547

Earlier quoted context omitted.

> since the AI is writing the tests it's obvious that they're going to pass That's not obvious at all if the AI writing the tests is different than the AI writing the code being tested. Put into an adversarial and critical mode, the same model outputs very different results.

Even if its a different session it can be enough. But that said i had times where it rewrote tests "because my implementation was now different so the tests needed to be updated" so you have to prompt even that to tell it to not touch the tests.

and then verify that it obeyed the prompt!

Someone needs to build an agentic tool that does strict, enforced TDD.

Re: AI adoption and Solow's productivity paradox

#548

Earlier quoted context omitted.

And those companies will do what? Produce products in uber-saturated markets? Or magically 9900 more products or markets will be created, all of them successful?

Go back to a time at the start of Youtube. Now answer these questions: And what will those people who make videos on Youtube do? Produce videos in uber-saturated categories? Or magically 9900 more media channels will be created, all of them successful?

To follow this up, one of my favorite channels on Youtube is Outdoor Boys. It's just a father who made videos once a week doing outdoor things like camping with his family. He has amassed billions of views on his channel. Literally a one-man operation. He does all the filming, editing himself. No marketing. His channel got so popular that he had to quit to protect his family from fame.

Many large production companies in the 2000s would have been extremely happy with that many views. They would have laughed you out of the building if you told them a single person could ever produce compelling enough video content and get at many viewers.

Re: AI adoption and Solow's productivity paradox

#549

Earlier quoted context omitted.

My manager mentioned that his manager (an executive) is not happy because the org we are in are not using as much tokens as other orgs in the company. Pretty wild

Just have Claude code churn out some Harry Potter fan fiction for an hour a day and you’ll meet your KPI easily

"You haven't hit your spell quota today, Harry. I'm putting you on a Wizard Improvement Plan."

Re: AI adoption and Solow's productivity paradox

#550
post #426

It's the same reason why I have, for more than a decade, been so frustrated with people refusing to consider proper pair programming and even mob programming, as they view the need to keep people busy churning lines of code individually as the most important part of the company. That multiple AI agents can now churn out those lines relatively nearly instantly, and yet project velocity does not go much faster, should…

> ... and yet project velocity does not go much faster 1) The models like us have finite context windows and intelligence, even with good engineering practices system complexity will eventually slow them down. 2) At the moment at least, the code still needs to be reviewed and signed off by us and reading someone else's code is usually harder than writing it.

Are people still reading PRs in detail manually?

I am after the automated PR agents have all passed a PR I tend to let Claude Code and Codex give me a summary, with an MCP skill to read the requirement story. I trust their ability to catch edge cases and typos more than me. I just check the general structure of the PR

Post reply on HN