Live data from Hacker News

The AI Productivity Gap

bjorg.bjornroche.com

21–30 of 127 posts

Re: The AI Productivity Gap

#21
AI is a force multiplier.

It multiplies both good and bad decisions. Both mine and it's 'own'.

I can get some things done 10x faster and it might even catch mistakes or help me solve something difficult.

But if I am being lazy or complacent then it bites me that much harder.

Re: The AI Productivity Gap

#22
post #8

Based on personal observation, a lot of productivity has been thrown out of the window with unneeded refactoring, rewrites and "what-if" scenarios that the AI agent will spot.

"... unneeded refactoring, rewrites and "what-if" scenarios ..." Like so many senior developers I have encountered. That stuff is good for CV.

It's on a completely different level now.

Re: The AI Productivity Gap

#23
post #6

Earlier quoted context omitted.

I stopped using coding agents after more than one and a half year of active use, it really started to become way too boring, and I’m t a point where I just hate having to babysit them and for the 200th time make it understand what the actual goal is… and to be honest, going back to writing code by hand without assistance is really hard at first you continuously have that little voice telling you how simple that would…

Neither of these points feel true anymore. Models are very much predictable these days (except anthropic models). The real issue stems from letting them work on their own for far too long. Also we are not controlled by 2 companies anymore as kimi k3, deepseek flash (and soon pro) as the ultra-cheap variants, glm 5.2 especially is a direct replacement for opus 4.8. Models will only get better and cheaper I wouldn't fe…

I always found that if you are good enough at whittling down boilerplate that coding becomes something akin to pure architecture.

I find that mediocre programmers and LLMs are bad at both. They're helpful if you want to shit out some repetitive boilerplate or perform a complex search of some kind but otherwise you're better off without.

Re: The AI Productivity Gap

#24

Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well. AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's w…

> you've mostly increased the team's work queue rather than its throughput

Amdahl’s law remains unbeaten

Re: The AI Productivity Gap

#25

Writing code is a small part of everyday's job of a software engineer. The article's table reflects this fairly well. AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. If code generation speeds up by 5x while those bottlenecks don't, you've mostly increased the team's w…

Good summary. Theory of constraints in action.

Re: The AI Productivity Gap

#27

What I have noticed in my own work that a lot of the time that used to be for coding is now just waiting. I have three agents working on three different features in parallel, and I'll go back and forth with all of them, correcting things and steering etc, but then I find myself with three busy agents and nothing to myself except stare at the screen while they code away. There is a mental budget for me where I can't h…

Which is why, when I can get away with it, I only use AI for improved code completion, or generating the initial boilerplate.

Re: The AI Productivity Gap

#28
> There’s no doubt that AI has already improved the productivity of engineering teams

Thought it might be an interesting read, however have up just after reading the first line.

For the context, code had always been a copy-paste exercise, big part of it was understanding and differentiating between the different choices. Along with it people were growing as engineering practitioner's too. Human learning still needs to happen if they are expected to fix the code when LLM gives up.

LLMs are quite useful tool in themselves, however the hype has unfortunately polarized the population.

Re: The AI Productivity Gap

#29
post #5

Pre AI and Post AI code review hours are both 0.75 in this made up example. I find that implausible. Even with the same amount of code, AI code is less trustworthy* and requires more attention... but we know it won't be the same amount, it will be more. This means it will take longer to review, or there will be unforeseen consequences of not spending that extra time. *meaning no human eyes have looked at it and said…

The hard part is that LLM code looks like there is some sort of flow. It is like a nice statistical smooth flow. It looks very convincing at a glance. No one would write code like that and not know what they are doing comments self assured and all.

LLMs are incredibly good at replicating common, coarse statistical features - which is what backs "looks very convincing at a glance".

If it's a general signal that's easy for you to recognize at a glance, it's a signal that's natural and easy for an LLM to replicate.

They're much worse at making the underlying structure work. Not incapable at all, especially not the modern LLMs. Frontier models kick ass. But it's true that an LLM denies you a lot of the classic "tell at a glance" by its very nature.

Re: The AI Productivity Gap

#30
I don’t think human review is worth it for LLM generated code. We design abstractions and all around how humans think. LLMs writes code that is better understood by machines. If you are all in on LLMs, by all means, read the code figure out what it means. But trying to enforce a human flow to its logic is flawed and will be overwritten the next time.
Post reply on HN