Live data from Hacker News

The AI Productivity Gap

bjorg.bjornroche.com

121–127 of 127 posts

Re: The AI Productivity Gap

#121

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

https://en.wikipedia.org/wiki/Amdahl's_law

For anyone who hadn't heard this before, like me. In computer architecture, Amdahl's law (or Amdahl's argument[1]) is a formula limiting the speedup of a task as resources are added to the system executing that task.

The law can be stated as[disputed – discuss]:

    the overall performance improvement gained by optimizing a single part of a system is limited by the fraction of time that the improved part is actually used.[2]
It is named after computer scientist Gene Amdahl, and was presented at the American Federation of Information Processing Societies (AFIPS) Spring Joint Computer Conference in 1967.

Amdahl's law is often used in parallel computing to predict the theoretical speedup when using multiple processors.

Re: The AI Productivity Gap

#123

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

[deleted]

Re: The AI Productivity Gap

#124

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

Of course you can beat it (in this context). You can cheat (by shifting the work around).

Started to write up a comment, got a bit wordy, turned into a blog post: https://senkorasic.com/articles/ai-amdahls-law

Re: The AI Productivity Gap

#125
Could you speak to the source of the pre-ai / post-ai differences? I'm specifically curious about how you decided the values that were changed (1.5h pre -> 0.5 h post)? Is that an illustrative conceptual thing, or is there data backing that? Not trying to litigate your article, good read. Just curious about the grounding for the specific values that changed pre/post.

Re: The AI Productivity Gap

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

Hi, this really resonated with me and the approach I have been following within enterprise software domain.

Do you mind outlining your stack around this. I know you mentioned python to support your verification harnesses but I am more interested in the agent setup. Are you specifically using Claude and it's skills with custom plugins or are you using other harnesses such as pi. I have settled on superpowers plugin across Claude and Codex, Cursor and most of my time is spent iterating through the design doc between Claude and Codex, implementing with either and starting another review cycle with the implementation, using TDD approach. It can be a lot of work but the end result is more than if I had done it myself. I am trying to formalize more. Anyway, thanks for the great insights.

Re: The AI Productivity Gap

#127
post #116

Writing code is cheap. Coming up with a plan to stay updated on specs and verification are not so cheap, and you need more attention there than ever, because an LLM will take your half-assed spec and claim victory as it prints linted code that compiles and passes a few token unit tests while being under (500 or 1000) LoC. That's PoC-level, happy-path-only engineering and LLMs are very dangerous at inserting subtle ha…

[flagged]
Post reply on HN