Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI adoption and Solow's productivity paradox

fortune.com

Post reply on HN
Print view View original

711–720 of 783 posts

Re: AI adoption and Solow's productivity paradox

#711

Post by overgard »

Kiro wrote: post #298
overgard wrote: post #196

Earlier quoted context omitted.

> The thing with a lot of white collar work is that the thinking/talking is often the majority of the work… unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed. WHOAH WHOAH WHOAH WHOAH STOP. No coder I've ever met has thought that thinking was anything other than the BIGGEST allocation of time when coding. Nobody is putting their typing words-per-minute on their resu…

Our job is not the intellectual exercise you think it is. We're not smarter than anyone else and software development is not automatically more thought-intensive than other jobs. The fact that programming is the first job task to be fully automated says it all.

When coders need a break from intense coding, what do they do with the remaining hours of the day? Usually, administrative stuff -- sending emails, attending meetings (if they can organize when their meetings are), filing expense reports, etc. IE, the stuff that's easy. Also while I wasn't attempting to suggest that thinking more = higher iq (just that it requires a lot of careful thought), average IQ's per job score are quite a bit higher in software engineering fields.

Re: AI adoption and Solow's productivity paradox

#712

Post by overgard »

simonw wrote: post #223
overgard wrote: post #187

Earlier quoted context omitted.

Does it matter if they can't ever stop training though? Like, this argument usually seems to imply that training is a one-off, not an ongoing process. I could save a lot of money if I stopped eating, but it'd be a short lived experiment. I'll be convinced they're actually making money when they stop asking for $30 billion funding rounds. None of that money is free! Whoever is giving them that money wants a return on…

It matters because as long as they are selling inference for less than it costs to serve they have a potential path to profitability. Training costs are fixed at whatever billions of dollars per year. If inference is profitable they might conceivably make a profit if they can build a model that's good enough to sign up vast numbers of paying customers. If they lose even more money on each new customer they don't have…

I'm curious just because you're well known in this space -- have you read Ed Zitron's work on the bubble, and if so what did you think of it? I'm somewhat in agreement with him that the financials of this just can't be reconciled, at least for OpenAI and Anthropic. But I also know that's not my field. I find his arguments a lot more convincing than the people just saying "ahh it'll work itself out" though.

Re: AI adoption and Solow's productivity paradox

#713

Post by overgard »

vidarh wrote: post #286
overgard wrote: post #170

Earlier quoted context omitted.

I don't think "results don't match promises" is the same as "not knowing how to use it". I've been using Claude and OpenAI's latest models for the past two weeks now (probably moving at about 1000 lines of code a day, which is what I can comfortably review), and it makes subtle hard-to-find mistakes all over the place. Or it just misunderstands well known design patterns, or does something bone headed. I'm fine with…

Do you use an agent harness to have it review code for you before you do? If not, you don't know how to use it efficiently . A large part of using AI efficiently is to significantly lower that review burden by having it do far more of the verification and cleanup itself before you even look at it.

I have it run tests and every few days I ask it to do a code quality analysis check on the codebase.

I'm unconvinced AI reviewing AI is the answer here, because all LLMs have the same flaws. To me, the harness/guard rails for AI should be different technologies that work differently and in a more formal sense. IE, static code analysis, linters, tests, etc.

(Linting has actually been, by far, the BEST code quality enforcers for the agents I've run so far, and it's a lot cheaper and more configurable than running more agents.)

Re: AI adoption and Solow's productivity paradox

#714

Post by overgard »

scoopdewoop wrote: post #222
overgard wrote: post #170

Earlier quoted context omitted.

I don't think "results don't match promises" is the same as "not knowing how to use it". I've been using Claude and OpenAI's latest models for the past two weeks now (probably moving at about 1000 lines of code a day, which is what I can comfortably review), and it makes subtle hard-to-find mistakes all over the place. Or it just misunderstands well known design patterns, or does something bone headed. I'm fine with…

Prompting LLMs for code simply takes more than a couple of weeks to learn. It takes time to get an intuition for the kinds of problems they've seen in pre-training, what environments it faced in RL, and what kind of bizarre biases and blindspots it has. Learning to google was hard, learning to use other peoples libraries was hard, and its on par with those skills at least. If there is a well known design pattern you…

Let me clarify, I've been using the latest models for the last two weeks, but I've been using AI for about a year now. I know how to prompt. I don't know why people think it's an amazing skill, it's not much different from writing a good ticket.

Re: AI adoption and Solow's productivity paradox

#715

Post by storus »

csa wrote: post #659
storus wrote: post #391

Earlier quoted context omitted.

It will lead to hollowing out of the substance everywhere. The constant march to more abstraction and simplicity will inevitably end up with AI doing all the work and nobody understanding what is going on underneath, turning technology into magic again. We have seen people losing touch with how things work with every single move towards abstraction, machine code -> C -> Java -> JavaScript -> async/await -> ... -> LLM…

> nobody understanding what is going on underneath I think many developers, especially ones who come from EE backgrounds, grossly overestimate the number of people needed who understand what is going on underneath. “Going on underneath” is a lot of interesting and hard problems, ones that true hackers are attracted to, but I personally don’t think that it’s a good use of talented people to have 10s or 100s of thousan…

The point is that LLMs can only replicate what existed somewhere, they aren't able to invent new things. Once humans lose their edge, there won't be any AI-driven progress, just a remix of existing stuff. That was the hollowing out I mentioned. Obviously, even these days there is tech that looks like magic (EUV lito etc.) but there are at least some people that understand how it all works.

Re: AI adoption and Solow's productivity paradox

#716

Post by steveBK123 »

torben-friis wrote: post #42
crazygringo wrote: post #21

Just to be clear, the article is NOT criticizing this. To the contrary, it's presenting it as expected , thanks to Solow's productivity paradox [1]. Which is that information technology similarly (and seemingly shockingly) didn't produce any net economic gains in the 1970's or 1980's despite all the computerization. It wasn't until the mid-to-late 1990's that information technology finally started to show clear benef…

The comparison seems flawed in terms of cost. A Claude subscription is 20 bucks per worker if using personal accounts billed to the company, which is not very far from common office tools like slack. Onboarding a worker to Claude or ChatGPT is ridiculously easy compared to teaching a 1970’s manual office worker to use an early computer. Larger implementations like automating customer service might be more costly, but…

I keep seeing this argument thrown around, but API usage on business plans is token spend based and can be orders of magnitude more than this $20/head per month.

My company is spending 20-50x that much per head easily from the firmwide cost numbers being reported.

They had to set circuit breakers because some users hit $200/day.

Re: AI adoption and Solow's productivity paradox

#717

Post by docmars »

vidarh wrote: post #690
docmars wrote: post #582

Earlier quoted context omitted.

This is correct, but part of the issue is that it significantly increases token usage costs. Some companies are doing: - PRD and spec fulfillment review - code review + correction loops - security review + corrections - addl. test coverage and tidying - addl. type checks and tidying - addl. lint checks and tidying - maybe more I haven't listed And these are run after each commit, so you can only imagine the costs per…

Sure, it adds tokens. I've burnt 200 million tokens today on a single project. The question is what your time is worth for the company, and which tasks costs less to have an agent automate than having you do.

I think if you were to scale that kind of usage across a reasonable team size, costs would start to add up fast — and possibly beyond the cost of paying another engineer every year, especially if a lot of your teammates are new to AI, or aren't using it efficiently. Of course, it all depends on the appetite of the company.

The other constraint is, for those who are being laid off (maybe because of cost reduction to support an AI budget for a smaller team to use), engineers wanting to expand their skill set and practice these levels of usage + efficiency are effectively unable to with their own funding, making it more difficult to find employment as expectations heighten.

Prior to AI entering the fray, software development was largely free for everyone, allowing anyone with enough time and motivation to build the skills towards gainful employment. As AI becomes more prevalent and expectations around how it's used become higher, fewer and fewer applicants will be able to claim they have the experience necessary because it was out of reach due to costs.

Re: AI adoption and Solow's productivity paradox

#718

Post by sebmellen »

overgard wrote: post #196
sebmellen wrote: post #12

The thing with a lot of white collar work is that the thinking/talking is often the majority of the work… unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed. Writing the software, which is essentially working through how to implement the thought, used to take a much larger percentage of the overall time consumed from thought to completion. Other white collar busines…

> The thing with a lot of white collar work is that the thinking/talking is often the majority of the work… unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed. WHOAH WHOAH WHOAH WHOAH STOP. No coder I've ever met has thought that thinking was anything other than the BIGGEST allocation of time when coding. Nobody is putting their typing words-per-minute on their resu…

> I'm absolutely baffled that you think the job that requires some of the most thinking, by far, is somehow less cognitively intense than sending emails and making slide decks.

OK, to quote you: WHOAH WHOAH WHOAH WHOAH STOP!

You've made a lot of assumptions.

I'm not saying that coding is not thinking. What I'm saying is this:

There is a difference between:

  (a) thinking about, and deciding upon, what will be done, and 
  (b) the thinking that is required during implementation.
In my experience, coding is at least 50/50 (even for the best developer) in the sense that figuring out how to structure and fix your code {type (b)} used to require very deep thinking. But then the other thinking time was spent on your system design/architecture {type (a)}, and not debugging type errors, etc.

AI has already changed that split. If you have a good test harness and problem definition, you can throw Codex at a really massive task and have it do quite well at the finer details of implementation.

Other white-collar office work, as stupid as it may be, will be a lot harder to automate because it is primarily the "thinking about what will be done" {type (a)} kind of work and not the "thinking that is done during implementation" {type (b)} kind of work.

If you haven't seen what I mean by "enterprise office work" it may be hard to grasp what I'm talking about... But thinking that people are just doodling around making slide decks or writing shitty emails is the wrong mental model for the breadth of non-technical work available in a large company.

Re: AI adoption and Solow's productivity paradox

#719

Post by sebmellen »

overgard wrote: post #212
sebmellen wrote: post #80

Earlier quoted context omitted.

Yeah, ratios vary depending on how productive you are with code. For me it was 50:50 and is now 80:20, but only because I was a relatively unproductive coder (struggled with language feature memorization, etc.) and a much more productive thinker/architect.

"Struggling with language feature memorization" is what we call "unemployed", not "relatively unproductive".

No. You can be a very productive developer and have the syntax be more of a blocker than application design, and the same in reverse.

I interview a lot of people, and I've seen people who are astoundingly good at micro-systems, very complex regexes, etc. white struggling massively with system design. And vice versa. People have different talents.

But, in my experience, AI will vastly improve the success of the developer who's better at orchestration, architecture, and system design than the developer who's very good at tiny micro-system type of work. Yes, there is still a need for someone who can read and understand regexes... but is there anywhere near as much of a need as before? Not at all.

Now. there are very many dual threats, and most truly senior engineers are both. These people now have an even bigger leg up, because they have an understanding of system mechanics + the superpower of Claude Code/etc. They don't have to waste as much time on boilerplate and raw implementation, and yet they can check the output of their input to the AI. They are also probably better equipped to build testing harnesses, etc., that adapt well to agentic use.

Re: AI adoption and Solow's productivity paradox

#720

Post by sebmellen »

ozgrakkurt wrote: post #91
sebmellen wrote: post #12

The thing with a lot of white collar work is that the thinking/talking is often the majority of the work… unlike coding, where thinking is (or, used to be, pre-agent) a smaller percentage of the time consumed. Writing the software, which is essentially working through how to implement the thought, used to take a much larger percentage of the overall time consumed from thought to completion. Other white collar busines…

Thinking is always the hardest part and the bottleneck for me. It doesn’t capture everyone’s experience when you say thinking is the smaller part of programming. I don’t even believe a regular person is capable of producing good quality code without thinking 2x the amount they are coding

As I wrote in a separate comment to someone who responded to me, there is a difference between:

  (a) thinking about, and deciding upon, what will be done, and 
  (b) the thinking that is required during implementation.
{type (a)} was always the majority of my time, but {type (b)} consumed a lot of effort, especially for languages or syntaxes I wasn't very familiar with. {type (b)} consumes very little of my time now.
Post reply on HN