Live data from Hacker News

The AI Productivity Gap

bjorg.bjornroche.com

81–90 of 127 posts

Re: The AI Productivity Gap

#81
post #78

Earlier quoted context omitted.

ehh, they're pretty good at automated performance research and bug fixes, especially when spanned across hundreds of them.

bug fixes not so much. when I encounter a bug the first thing I do is ask an LLM and not only do they usually fail to get the correct solution, they often slap virtual duct tape on it which makes other bugs more likely.

feels like a harness issue, bug fixes work out fine with omp.sh as long as it can be tested properly. Untestable things tend to lead to hallucinated results though.

Re: The AI Productivity Gap

#82
I’d suggest a slightly different workflow depending on experience level.

Beginners should follow the practice described in the article: have the LLM propose code, then type it manually. This forces you to examine each step, question unfamiliar decisions, and build a stronger mental model of the codebase.

Experienced developers who already understand the underlying concepts may find autocomplete more practical when writing from scratch. It preserves control over structure, comments, and coding style while preventing tools such as Opus or Fable 5 (Both of these models loves adding tons of comment in your codebase) from generating bloated code, excessive comments, or patterns that do not match the existing codebase.

Re: The AI Productivity Gap

#83

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…

[flagged]

Re: The AI Productivity Gap

#84
Soon nobody will write code by hand , nobody will read it, and nobody will do code reviews. Architecture too will be done by AI.

the one whats unclear to me is, will there still be meetings.

Re: The AI Productivity Gap

#85
post #69

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…

Very well said. Programming has always felt like converting thought-stuff into something that the computer can understand. That's still the same, it's just a different language, and much faster. My hot take is: if people are saying AI code is bad, yet they're using cutting-edge models like Opus 5, then those same people are writing bad code even without AI. I'm finding that AI today can write excellent code, as long…

more and more of the thought stuff is being done by AI, let's not kid ourselves.

Re: The AI Productivity Gap

#86

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…

> AI compresses implementation time for an individual engineer, but architecture decisions, design reviews, integration, testing, deployment, and production validation remain largely serial activities. Integration, testing, deployment and production validation activities are also, depending on you setup, available for AI to work on. It depends on the type of stack that you have and how your hosting is set up but with…

This is largely true to only the extent that you you have a machine-verifiable measure of quality. If not, you’re putting more pressure on the humans who can actually reason and understand business goals. This cascades: tests are what make LLM code generation work but if you have an LLM write the tests you are then pushing further down the road the point where you learn that the first LLM was going in the wrong direction.

Re: The AI Productivity Gap

#87
post #78

Earlier quoted context omitted.

bug fixes not so much. when I encounter a bug the first thing I do is ask an LLM and not only do they usually fail to get the correct solution, they often slap virtual duct tape on it which makes other bugs more likely.

feels like a harness issue, bug fixes work out fine with omp.sh as long as it can be tested properly. Untestable things tend to lead to hallucinated results though.

might be a symptom of writing complex code. I'm sure on basic CRUD they can figure out most bugs since most of them have happened 1000 times before.

Re: The AI Productivity Gap

#88
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…

[dead]

Re: The AI Productivity Gap

#89
"In reality, it’s juniors who stand to gain the most from AI – especially if they are good at using AI as a learning tool, not just an overeager sidekick who’s willing to do the menial work."

We have had interns come in and do 5x more work than their predecessors using GenAI. Senior devs spend most of their time planning and reviewing now and Junior devs can implement. Both with the help of GenAI.

Re: The AI Productivity Gap

#90
post #64
post #14

Earlier quoted context omitted.

I'd be really interested to see all the software that is written by agents. Whenever I touch agents or ai I can't get much use out of them. My understanding is the value when I think aloud with them/treat them as a better google search, but thats about it. Except one off web stuff, that is a pretty neat use case. But lets be real, anything moderately complex that is out of the domain of publicly available sample code…

Idk, ymmv. I’ve had very good outcomes writing embedded firmware for complex systems, drivers, etc. it’s really, really good at not bodging the kinds of things that always catch meaty developers unawares. OTOH, we run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then…

How much does your whole setup cost? Just curious. An estimated range would be interesting to have
Post reply on HN