Live data from Hacker News

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

frederickvanbrabant.com

211–220 of 490 posts

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

#211

Earlier quoted context omitted.

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…

I think validating a fully generated novel of a ticket, is much harder than thinking through the problem in the first place and creating your own ticket. We see it with code too right? It’s harder to review code than to write it. On top of that the LLM can work so fast that the amount of things that need validating grows! This is where humans get lazy and the problems come in IMO. Whether its a PM not validating thei…

The tickets are not "novel"-length, they are about a few bulleted lists of the sections I mentioned above. In that case it is indeed way easier to review that a ticket only saying "do X with Y data."

Reviewing code is harder than reviewing text because code does something and has interdependencies and therefore must be correct in its function, do not mix the two. This is like saying an editor reviewing an article or novel is harder than actually writing the novel which is blatantly incorrect.

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

#212
post #203

Earlier quoted context omitted.

A workable C compiler is a ~10-50KLOC program, and a fairly simple one at that (batch, with no concurrency or interaction). That Anthropic's swarm of agents wrote 100KLOC before failing is a symptom of the problem. It's certainly possible that many programs are in the sub 5KLOC range, but it's definitely not "most software". Plus, almost no software has this level of detailed spec, ready-made tests, and a selection o…

A bit off topic, but see how Anthropic publicity stunts went from "Claude C Compiler" with 100K LOC to the recent Bun Rust rewrite with 1M LOC (10x!) in just 3 months. I get that it's "novel" creation vs porting, but given that they reported that the C compiler cost them $20k in API costs, the Bun rewrite must be at least $200k, maybe even closer to a million. Pure madness.

Yes, the task is very different, but also it will be months to a year until we know the results of the bun experiment.

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

#213
post #206
post #129

Earlier quoted context omitted.

This was already a reality for a years. In several companies I have seen product managers joining teams and failing to even have minor requirement ready for months during “onboarding” of the PM. And then code being ready but taking months to release because DevOps is busy or QA can’t find time. The pace of release of software has been disconnected from the coding part for the longest time, and we have been quiet abou…

The solution I've seen work is have engineers and designers that can take much of the detailed spec writing on, and have the PMs spend time with users/prospective users, partners, etc, understanding the market and users better. When you pull PMs in to all the details, often they turn into project managers, shuffling bug tickets around etc, taking time away from owning the user and the problem and shifting them too mu…

I agree with you. The healthier organizations work in the way you mention.

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

#214
post #201

Earlier quoted context omitted.

> The PMs validate it, why do you think they don't read over it to make sure it fits what they want? Hahahahahaha. Sorry, I couldn't help myself; this reads like satire. The answer is "real life experience says otherwise".

Yeah I was so tempted to ask if this person has ever actually met a project/product manager...

Maybe you both just have bad PMs, because just like good devs they should also be reviewing their work. My point was that it is more likely for PMs to review and edit a generated ticket than to have to write it all themselves which they often won't do.

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

#215

> This exact thing is what software developers have been begging for since the beginning of the profession: Receiving a detailed outline of the problem and what the end result should look like. > This is often the part that slows down software development. Trying to figure out what a vague, title only, feature request actually means. But that is exactly what Software Engineering is!. It's 2026 and the notion that you…

Trying to figure out the best way to solve vague requirements is why I got into engineering.

If I got detailed specs, I’d just be a coding robot. I push that work off onto juniors.

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

#216
Honest question: Does anyone know about any quantitative study or analysis on productivity gains using code assistants? Asking for numbers comparing between the "pre AI era" and now.

Also, I have the impression that LLMs bring some gains or benefits for individuals but not relevant enough at the organization level.

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

#217

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.

Maybe they are holding it wrong then. Like someone else said, people had to be taught how to drive a car and that cannot be in any sense said to be the car's fault.

Some people are lazy, plain and simple. If they want to blindly accept what the LLM tells them without critical analysis and review then that's on them.

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

#218

Earlier quoted context omitted.

You're completely right and I thought this would be obvious. I never prompted anything remotely closely to "make a facebook clone". Instead, I make an explanation of how it should work. To give you an example: I need a python script that 1) reads /etc/hosts 2) find values of specific configured hosts (read from a .conf which) eg server1, localhost, etc 3) it'll assign a name to those configs eg if the .conf has [Env1…

That's the kind of stuff where you would write a few lines of shell script or perl and not bother with the whole GTK stuff. Because GTK would be accidental complexity to the task (unless you used something like zenity). This is one of the reasons I like the OpenBSD and suckless projects. There are solutions that are technically correct, but are overengineered.

Well I would never write shell because I loathe it's grammar/syntax. I enjoy GUIs and am a heavy mouse user, so the GTK part isn't really an "accidental complexity" but a must have for me. If a LLM can one-shot all the GTK boilerplate it's a win.

That's (as shown in my sample prompt) one great thing I've been using LLMs for: making GUIs for arcane Linux-based OS/userland settings that I have no interest in doing "sudo gedit yadda yadda" or learning man pages for. It's been 30+ years, we deserve a better desktop experience.

I've used suckless packages in the past, but it feels to me too close the GNOME/Apple way of giving zero settings and having opinionated defaults whose opinions do not ring well for me. I have zero desire to change my shortcuts/hotkeys to something random devs chose based on their past computer experience, mostly unix-based. Muscle memory > *.

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

#220
post #152

Earlier quoted context omitted.

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…

I literally can’t tell if this comment is a joke or not.

The last sentence was party facetious sure but the first paragraph is not, I have seen ticket quality go up quite a bit from a few years ago.
Post reply on HN