Live data from Hacker News

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

frederickvanbrabant.com

471–480 of 490 posts

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

#471

Earlier quoted context omitted.

You do not seem to be engaging in good faith: the GP explicitly discusses "self-driving cars", which come with an expectation that you still need to be "just checking they work well", and we have already seen people not do that, or be bad at it (if you have to jump in in an emergency, that's exactly when you want to have been part of getting to that point to react properly). You are debating how people should behave,…

I know they said self driving cars, I am talking about manual cars, it's two different points even though both are analogies about cars. I am not debating how people should behave, I am debating their thought that technology should just work without any sort of instruction or learning and if it doesn't then it's a tech error not a human error. My point is that many technologies require learning how to use them, and t…

> I am debating their thought that technology should just work without any sort of instruction or learning

But since that was not, in fact, the point I was trying to make, and you keep trying to put it into my mouth, I don't think it's particularly productive trying to discuss this with you.

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

#472
post #252

Earlier quoted context omitted.

Same here. Anyone being even hesitant about AI is viewed negatively by management

This is the one case where management is right, they had to drag my (FAANG) org kicking and screaming into the AI future and it was worth it. We are moving 3-10x faster (team dependent). Now the engineers I know that had the same skeptical tone as OP are the ones singing its praises and doing cool shit with it.

From what little you're saying, you guys might be more productive now and writing better code, finally decently documented, or you just hopped onboard a speeding slop train, or something to be defined in between. Hard to tell which.

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

#473
post #424

Earlier quoted context omitted.

IQ is a (biased) proxy measure for human intelligence. It is not a meaningful measure when applied to a computer system.

What IQ "means" is separable from what it is. IQ is a measure of performance on IQ tests. That's literally what it is. If a computer system can complete IQ tests, it has an IQ. The issue is that IQ means less than you want it to.

I don't want IQ to mean anything. pkoird clearly wants it to mean something.

IQ is a terribly flawed measure of human intelligence. But it measures nothing when you apply an LLM that contains multiple IQ tests in its corpus. IQ is deeply flawed, but the point is not to "measure performance on IQ tests". If someone cheats on an IQ test and scores 200, no reasonable person would say they have 200 IQ.

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

#474
I'm an AI maximalist (I haven't touched a line of code since Dec 2025, barring some config files) and I agree with the article. Most teams won't be meaningfully accelerated by AI because building was never the bottleneck in most orgs. Knowing what to build usually was. I routinely finish everything on my plate pretty quickly with LLMs, so my personally processes have accelerated. I've fired off agents to build stuff that I personally want out of the product but would have been infeasible to build manually. And I'd work on my tasks at the same time.

But when I compare company roadmap this year to a few years ago, you can't tell that any needle has moved at all in terms of technology and features.

That said, we're kinda in a weird era where the optics of AI usage is more important than anything because investors want to see it, because they think it will give their company a leg up on the competition, which is not necessarily true!

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

#475

Earlier quoted context omitted.

> That's what a good PM and developer pair should be doing, it's just that it's a lot faster for both of them now to review and work in tandem to get the feature done, because the bottleneck is the code generation. The bottleneck is understanding, never "code generation." Below is an an axiom which has served me well over the years. Perhaps it will for you as well. When making software, remember that it is a snapshot…

Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.

> Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.

If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them.

More generally, I have yet to see engineers which understand what needs to be delivered be limited by typing speed. Conversely, I have too often observed rapid code generation lacking intrinsic understanding fail to deliver satisfactory solutions.

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

#476

Earlier quoted context omitted.

Sure for a few. But eventually the interaction of all those complex features turns it into a “complex system”. Which as you yourself just said are not conducive to PM vibe coding.

I'd say the majority of these sorts of tools are actually simple enough to be vibe coded, only some are complex enough to require an actual engineer building it rather than vibe coding. So in most cases it's actually a win for the PM.

Only if you’re talking about tools with very few users that haven’t been around long. In my experience the conflicting requirements and workflows that accrete over time are too complex for people to reason about without more formal methods.

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

#477

Earlier quoted context omitted.

I'd say the majority of these sorts of tools are actually simple enough to be vibe coded, only some are complex enough to require an actual engineer building it rather than vibe coding. So in most cases it's actually a win for the PM.

Only if you’re talking about tools with very few users that haven’t been around long. In my experience the conflicting requirements and workflows that accrete over time are too complex for people to reason about without more formal methods.

> Only if you’re talking about tools with very few users that haven’t been around long

Sure, most business needs only have a few users. I once built a dashboard over the course of a year only for a grand total of around 10 business executives to actually use it.

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

#478

Earlier quoted context omitted.

I know they said self driving cars, I am talking about manual cars, it's two different points even though both are analogies about cars. I am not debating how people should behave, I am debating their thought that technology should just work without any sort of instruction or learning and if it doesn't then it's a tech error not a human error. My point is that many technologies require learning how to use them, and t…

> I am debating their thought that technology should just work without any sort of instruction or learning But since that was not, in fact, the point I was trying to make, and you keep trying to put it into my mouth, I don't think it's particularly productive trying to discuss this with you.

I am pointing out that your point, that tech should cater to how people generally operate, does not make much sense. It is flawed from the start, because people's general or natural operation can still be wrong and must be taught correctly, and that just because something is a natural operation does not mean it is how it should be. People have fundamentally flawed misconceptions all the time and it is foolish to cater to them, beyond improving UX where possible, but some things are simply not technologically possible to only improve via UX and not without teaching.

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

#479

Earlier quoted context omitted.

Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD.

> Sometimes it is code generation, not just understanding, especially if many of the tickets are just CRUD. If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them. More generally, I have yet to see engineers which understand what needs to be delivered be limited by typing speed…

> If "the tickets are just CRUD", then code generation reduces to a typing exercise if and only if the requisite functionality of the "CRUD tickets" are understood by the engineer(s) delivering them.

Correct, that's basically most tickets as I had said. They truly are not complex.

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

#480

Earlier quoted context omitted.

> I am debating their thought that technology should just work without any sort of instruction or learning But since that was not, in fact, the point I was trying to make, and you keep trying to put it into my mouth, I don't think it's particularly productive trying to discuss this with you.

I am pointing out that your point, that tech should cater to how people generally operate, does not make much sense. It is flawed from the start, because people's general or natural operation can still be wrong and must be taught correctly, and that just because something is a natural operation does not mean it is how it should be. People have fundamentally flawed misconceptions all the time and it is foolish to cate…

Very well then, O Fount Of All Wisdom About Humans, how does one go about teaching humans to operate self-driving cars that will drive for hours at a time with no problem, but 1% of the time will encounter an issue that the human needs to react to in under 3.5 seconds or crash and probably kill themselves and someone else?
Post reply on HN