Live data from Hacker News

I don't think AI will make your processes go faster

frederickvanbrabant.com

131–140 of 490 posts

Re: I don't think AI will make your processes go faster

#131

It’s completely wild to me that lifelong programmers come into contact with agentic coding and come to the conclusion that their jobs are safe for one reason or another. AI will definitely be able to write entire software, inclusive of figuring out requirements and asking the right questions. It’s not that far already. Why is it that everyone looks at weaknesses of a technology that didn’t exist a couple years ago in…

>...the incredible rate of improvement? Because the "rate of improvement" is only astonishing in well understood areas and really only astonishing if you yourself are not that great at what you do. Speaking for myself here, my job is extremely safe given that my boss doesn't wanna sit there and prompt AI all day and i work in a fun little 4 person company. We already have plans for the 3 next years which involve me :…

Because the "rate of improvement" is only astonishing in well understood areas and really only astonishing if you yourself are not that great at what you do.

This is a bold vague claim many on HN make, but never put back-of-napkin numbers on. e.g. do you think agentic Opus 4.7/GPT 5.5 are 95th percentile coders but you're 98th percentile? Or are you saying you're a middle-of-the-road 60th percentile coder and AI is 20th percentile so only 20% worst programmers should worry? Let's be specific about the claim being made.

Re: I don't think AI will make your processes go faster

#132

Earlier quoted context omitted.

Except... no one validates the generated tickets, and it's full of inaccuracies. And then someone copy pastes it into Claude and now those inaccuracies become part of the code and tests.

This failure is human laziness, not an issue with the technology. People who use AI because they are trying to avoid doing work fall into a completely different category than people using AI as a force multiplier and for skills/capabilities enhancements / quality improvement.

This is very much a "you're holding it wrong" response.

If your technology relies on humans using it in ways that go against the ways they are inclined to use them, then that is an issue with the technology.

Re: I don't think AI will make your processes go faster

#133
Fascinating, I was literally thinking about how to communicate this to coworkers the other day, literally down to the gantt chart. Now I don't even have to make one =)

> We are now talking about software development, but this is applicable to all processes that take longer than you would like.

Indeed, it's kind of a generalized version of Amdahl's law. Since we only speed up a portion of the work, there are upper bounds on time saved. Worse, work in progress tends to bunch up at a specific point: code review. A coworker of mine literally complained two months ago now that nobody was reviewing code (and that it was blocking his work). I'm not sure review delay has actually gotten better since.

Re: I don't think AI will make your processes go faster

#134

I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. When I was working we used to get requirements that literally said things like, "Get data and give it to the user". No definition of what data is, where its stored,…

In what I've seen, tickets are much richer in detail now because PMs are using AI (connected to the codebase itself, like Claude Code or Codex) to fill out a template as to what and why the problem is (ie X field exists in the backend not frontend), how and where to get any data (query the backend), and what acceptance criteria is needed (frontend should have the field exposed and "submit" should push the field's dat…

IMO the code-generation for boilerplate and the improvement of copypasta quality are much bigger improvements than that.

PMs turning their brain off and letting the LLMs extrapolate from quick and dirty bashing of text into a template (or, PMs throwing customer feedback at a slackbot to generate a jira ticket form it) can be better than PMs doing nothing but passing ill-defined reqs directly into the ticket, but that's a low bar. And it doesn't by itself solve the problems of the details that got generated for this ticket subtly conflicting with the details that got generated for (and implemented) in a different ticket 8 months ago.

Re: I don't think AI will make your processes go faster

#135
Recent NYT podcast showcased how China and the US are putting time, effort, and money into using AI. I have to say I liked China’s approach of AI percolation into the economy than US approach of walled gardens with cloud.

https://podcasts.apple.com/us/podcast/the-daily/id1200361736...

Re: I don't think AI will make your processes go faster

#136
post #59

Earlier quoted context omitted.

> how many problems that you work on have many existing free solutions but you neglected to use that code and decided to spend days doing it yourself? Only when the existing free solutions are licensed with something like GPL. Now I can just say, write me a C webserver library similar to mongoose and I get the functionality without the license burden.

You might as well have ignored or removed the GPL notice. Running it through the LLM laundering gets you a "fork" of unknown origin, questionable quality. You're still potentially open to supply chain issues but the chain is obfuscated. And you now own full responsibility for maintenance.

I just vibe coded a socks proxy because existing ones were too thick. And let me tell you, you are absolutely right. Go libraries I’ve never heard of, new implementations that has not been tested.. I think the word for this is YOLO

Re: I don't think AI will make your processes go faster

#137

Earlier quoted context omitted.

Except... no one validates the generated tickets, and it's full of inaccuracies. And then someone copy pastes it into Claude and now those inaccuracies become part of the code and tests.

The PMs validate it, why do you think they don't read over it to make sure it fits what they want? You might say "well they're lazy, look why they didn't write enough detail to start off with" but for lots of people, reviewing something to make sure it's close to what they want and then tweaking it is much easier than writing it from scratch. It's the equivalent of writer's block and is why a common advice given to w…

> The PMs validate it, why do you think they don't read over it to make sure it fits what they want?

The PM has historically often not had a detailed enough mental model of the implementation to spot the hard parts in advance or a detailed enough mental model of the customer desires to know if it's gonna be the right thing or not.

Those are the things that killed waterfall.

You can use LLM tools to help you improve both those areas. Synthesizing large amounts of text and looking for inconsistencies.

But the 80th-percentile-or-lower person who was already not working hard to try to get ahead of those things still isn't going to work any harder than the next person and so won't gain much of a real edge.

Re: I don't think AI will make your processes go faster

#138
post #29

I think when LLMs first came out people thought they could just say something like, "Make a Facebook clone". But now we're realizing we need to be more exact with our requirements and define things better. That has always been the bottle neck in software. When I was working we used to get requirements that literally said things like, "Get data and give it to the user". No definition of what data is, where its stored,…

We now have product owners trying to farm out their work to an LLM. The process didn’t work before because the person writing the requirements either put out vague requirements or bad requirements because they didn’t understand the business intent (or were careless). LLMs just take the same vague or poor requirements and make them look believable until you dig in to them.

> The process didn’t work before because the person writing the requirements either put out vague requirements or bad requirements because they didn’t understand the business intent (or were careless).

You make it sound like writing good requirements is easy.

If it were easy we wouldn't need all these concepts around PMF, product pivots and the like. And even before that was Peter Naur's paper "Programming as Theory Building" [1].

If you truly understand the problem you're solving with software then requirements can be easy. But usually we don't, not right away, and so we have to build up our understanding of the problem first in order to solve it.

Even then, the problem we solve may not have been the problem paying users will have, so you can have "good requirements" and still have a bad business, or even the opposite where you somehow build a working business despite bad requirements, because you hit upon a customer's need quite by mistake.

Nothing about any of this precludes LLMs being helpful, though nothing guarantees LLMs will be helpful either.

[1]: https://cekrem.github.io/posts/programming-as-theory-buildin...

Re: I don't think AI will make your processes go faster

#139
It's felt awhile similar to what we see in parallel computing:

- shift towards throughput-oriented vs latency-oriented. Can juggle more tasks, but increasingly hard to speed up individual ones.

- strong scaling is tough. Might even see slowdowns for individual tasks, so reliable benefits come from being able to juggle more and eat the per-task inefficiency

- amdahl's law: we can't speed up tasks beyond their longest sequential (human) unit, so our work becomes identifying those bits and working on them. Related: you can buy bandwidth, but you can't buy latency

Re: I don't think AI will make your processes go faster

#140

Earlier quoted context omitted.

This failure is human laziness, not an issue with the technology. People who use AI because they are trying to avoid doing work fall into a completely different category than people using AI as a force multiplier and for skills/capabilities enhancements / quality improvement.

This is very much a "you're holding it wrong" response. If your technology relies on humans using it in ways that go against the ways they are inclined to use them, then that is an issue with the technology.

I don't think that works as a critique of LLMs because it's far too broadly applicable to well-accepted tools.

Are advanced calculators bad because a student could use the CAS to ace calculus homework, exams or the SAT without actually learning the material?

Is copy/paste bad because a person could use it to copy/paste code from one place to another without noticing some of the areas they need to update in the new location, adding bugs and missing a chance to learn some more subtleties of the system?

Is Git bad because a manager could use it to just measure performance by number of lines of code committed instead of doing more work to actually understand everyone's performance?

Many tools can be used lazily in ways that will directly work against a long term goal of improving knowledge and productivity.

Post reply on HN