Live data from Hacker News

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

frederickvanbrabant.com

101–110 of 490 posts

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

#101
post #8

> Yes, AI can generate code quickly (whether that’s a good thing is open for debate), but that doesn’t mean it’s generating the correct code. No, the code is actually almost always correct. The way it’s added is probably not what you’re going to like, if you know your code base well enough. You know there’s some ceremony about where things are added, how they are named, how much comments you’d like to add and where e…

>No, the code is actually almost always correct

That's not my experience, especially when the inputs are bugs or performance issues. It frequently hallucinates and misdiagnosis without a guiding hand. However, it can still RCA and analyze well and improve efficiency if you keep an eye on what it's doing and push it the right direction.

> If you were to give human developers the same amount of feature/scope documentation you would also see your productivity skyrocket.

I think you run into a ceiling how fast a person can digest and analyze the info compared to a machine

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

#102

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…

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 writers is to put anything they can onto the page then edit it later.

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

#103

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…

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.

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

#104

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,…

What's even worse is that when dealing with human software teams, a vague requirement will (at least in a well-run org) receive demands for further specification. "What do you mean by 'get data'?", etc. An LLM will just say, "Sure! Here's the fully implemented code that gets the data and give it to the user. " and be done with it.

Just as poorly designed code can still compile. This is operator error, not a failure of the technology.

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

#105

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…

lol

Just lol. Is this what you guys mean by productivity boost?

Comical. LLM’s aren’t all that great - it’s more that most orgs are horribly inefficient. Like it’s amazing how bad they are.

That’s why Elon succeeded with spacex - he saw how horrible inefficient the industry was. And used that thinking to take a gamble and it’s paid off.

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

#106

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…

> Honestly, with the first step, it seems the PMs are already halfway there to implementation of the feature so I wonder if in the future they'll just do everything themselves

Yes please, I've seen the vibecoded slop PMs put out every day because software engineering is simply not a skill they have, and I'd love to make a LOT of money fixing their crap once it dies in production <3

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

#107
> "requirements were always the bottleneck"

> "faster typing won't make you faster".....

I understand a Deloitte consultant has specific incentives. But let's first try to answer a baseline question: why do some companies have thousands of software engineers? What do they all do?

And then, a follow-up: what is actually the bottleneck at most companies? What causes "requirements gathering" to take long?

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

#108

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?

Hahahahahaha. Sorry, I couldn't help myself; this reads like satire. The answer is "real life experience says otherwise".

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

#109
post #88

Earlier quoted context omitted.

> I find that for things I'm already capable at, LLMs are relatively inconsequential. But for things I'm no good at, it's a huge game changer. What are the chances that this is the Gell-Mann amnesia effect? Sounds like the textbook definition of it. Personally, I find the exact opposite to be true. LLMs only help me when I already know exactly what I'm doing.

Just because one isn’t good at a thing doesn’t preclude one from being a sufficiently passable judge of a thing. To wit, the answer pre-AI was to hire an expert on that thing, and you would then critically assess their work product, despite being unable to build it yourself.

True, but if you hire a generalist and they are consistently under-performing specifically in the subject matter where you are an expert, it may behoove you to take the rest of their work with a grain of salt as well.

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

#110

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,…

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]
  192.168.0.1 production-read
  192.168.0.2 production-write
  192.168.0.27 amqp
  
  [Env2]
  192.168.0.101 production-read
  192.168.0.201 production-write
  192.168.1.127 amqp
  
  Basically format:
  
  [CONFIG_NAME]
   
  
  Like an usual hosts file
  
  4) And each of those will be stored in memory
  5) if in /etc/hosts it matches one of those, it sets the "current env" as the configname
  
  5) It'll create an icon on the top-right of ubuntu 22 default gnome with
  6) that icon could be the text of the current config name or if nothing matches, "custom" text would show
  7) When the user clicks the "tray"/appindicator(or whatever gnome is calling them) it'll list the config names in a   simple gtk/gnome
  8) When the user clicks one config, we create a backup of /etc/hosts in ~/.config/backups/ named   hosts-%UNIX_TIMESTAMP%
  9) we then apply it to hosts file (find only the line with the hostnames to change and modify only those)
And that one-shotted a simple gnome app indicator env switcher. Had to fix a few lines here and there but it mostly just worked. If you give the proper spec to the LLM, it'll do it right. You can even fake a DSL to describe what you want and it'll figure it out.
Post reply on HN