Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

frederickvanbrabant.com

Post reply on HN
Print view View original

331–340 of 490 posts

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

#331

Post by jyounker »

ianbutler wrote: post #227
pron wrote: post #197

Earlier quoted context omitted.

> It's 2026 and the notion that you can get detailed enough requirements and specifications that you can one-shot a perfect solution needs to die. It's 2026 and the idea that even with detailed-enough requirements you can one-shot even a workable (let alone perfect) solution also needs to die. Anthropic failed to build even something as simple as a workable C compiler, not only with a perfect spec ( and reference imp…

Sorry where are we seeing that it failed? It compiled multiple projects successfully albeit less optimized. " It lacks the 16-bit x86 compiler that is necessary to boot Linux out of real mode. For this, it calls out to GCC (the x86_32 and x86_64 compilers are its own). It does not have its own assembler and linker; these are the very last bits that Claude started automating and are still somewhat buggy. The demo vide…

By "non-workable" I think people mean that it won't compile Hello World.

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

#332

Post by DrewADesign »

tombert wrote: post #253
lr4444lr wrote: post #126

Earlier quoted context omitted.

I can't imagine SWEs will be reduced to SDETs anymore than attorneys will be reduced to spell-checkers on AI powered case briefs. I am a very AI-forward person, but hallucinations are becoming more pernicious than ever even as they get less frequent, especially if the code actually works. A human absolutely has to guide these processes at a macro level for sustainability for SaaS as it evolves with business needs. Ma…

I've noticed even more than the "hallucinations", just the code is generally quite bad. At least with concurrent and distributed systems stuff (which is really all I know nowadays), it is great at getting a prototype, but the code is generally mediocre-at-best and pretty sub-optimal. I don't know if it's because it is trained on a lot of mediocre and/or buggy code but for concurrency-heavy stuff I've been having to r…

Numerous real world technical requirements can be solved with existing code, lightly modified. That’s basically LLM code’s bread and butter. The further you get from that, the closer the “time saved using LLM” line gets to zero, and once it crosses, it becomes the “time wasted using LLM” line. I think embedded and concurrent systems are going to require more unique code solutions than, say, a crud web app with a few interesting feature-building junkets.

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

#333

Post by lr4444lr »

satvikpendem wrote: post #229
lr4444lr wrote: post #126

Earlier quoted context omitted.

I can't imagine SWEs will be reduced to SDETs anymore than attorneys will be reduced to spell-checkers on AI powered case briefs. I am a very AI-forward person, but hallucinations are becoming more pernicious than ever even as they get less frequent, especially if the code actually works. A human absolutely has to guide these processes at a macro level for sustainability for SaaS as it evolves with business needs. Ma…

By SDET I mean one who reviews not writes code, maybe we have different definitions of that term because you also mention humans being needed to guide the processes. Even still, other professions interact with the real social world which is not necessarily the case with programming. A lawyer will always be needed because judgments are and must be made by humans only. Software on the other hand can be built and tested…

No one's arguing you can't stand up a good MVP.

It's when you have to iterate to handle changing business needs, scale issues, and integrate with other systems where the entropy becomes a scary concern over a long enough timeline.

And it's not just "checking" - it's wholesale rejections of code, reframing prompts to target specific classes or approaches, etc... I don't think you will take the human out planning any time soon.

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

#334

Post by doginasuit »

The general conversation on LLM assistance with coding is lacking nuance.

> 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.

It really depends on what you asked it to do. Add a new feature? I wouldn't touch that code with a 10 foot pole. Create a service with an example of another service in your project that does something similar? It is going to nail that pretty much every time in 2026.

Someone else put it really well: use LLMs as a fast typer, not a fast thinker. Don't have it generate any code you can't verify at a glance. Call in small completions that don't span more than a couple files, everything else is vibe coding.

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

#335

Post by tombert »

vips7L wrote: post #326
tombert wrote: post #253

Earlier quoted context omitted.

I've noticed even more than the "hallucinations", just the code is generally quite bad. At least with concurrent and distributed systems stuff (which is really all I know nowadays), it is great at getting a prototype, but the code is generally mediocre-at-best and pretty sub-optimal. I don't know if it's because it is trained on a lot of mediocre and/or buggy code but for concurrency-heavy stuff I've been having to r…

The code is quite terrible, but no one has ever cared about code quality, at least in my experience. All they’ve ever cared about is that “it works”. It’s why an army of juniors always write most of the code. I had this same discussion at work the other day. I had an 80k line generated project dropped on my plate. It doesn’t use anything built into the web framework or orm. It’s a maintenance nightmare.

I think there are plenty of projects where "good enough" really is "good enough"...maybe most apps? If you're just making a shitty simple app, I don't really care about code quality.

Example: I got Claude to generate a language server for TLA+ so I could have nice integration with Neovim. It took like 45 minutes of arguing with Claude and then it worked fine. This is incredibly low-stakes stuff: realistically the worst case scenario is that the text in the file gets screwed up, and I'm somewhat protected by Git if that happens.

That said, I am a little concerned how cavalier people have been deploying AI code everywhere. I don't want pacemaker firmware to be written by some intern in an afternoon with Claude.

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

#336

Post by Izkata »

q8zd3 wrote: post #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.

Here's the big one that was being passed around months ago, which nowadays usually gets dismissed out of hand because of when they did it (while ignoring the relative finding): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...

Here's a slightly more recent one focused more on comprehension/learning than productivity: https://www.anthropic.com/research/AI-assistance-coding-skil...

Metr attempted to redo that first one to get trends over time, but couldn't recruit enough developers to get reliable results for it.

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

#337

Post by BloondAndDoom »

angarg12 wrote: post #189

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

We will see smaller and smaller teams where all this overhead is minimized by handful of people, and more than ever we will see 2-5 people teams creating great software

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

#338

Post by vips7L »

tombert wrote: post #335
vips7L wrote: post #326

Earlier quoted context omitted.

The code is quite terrible, but no one has ever cared about code quality, at least in my experience. All they’ve ever cared about is that “it works”. It’s why an army of juniors always write most of the code. I had this same discussion at work the other day. I had an 80k line generated project dropped on my plate. It doesn’t use anything built into the web framework or orm. It’s a maintenance nightmare.

I think there are plenty of projects where "good enough" really is "good enough"...maybe most apps? If you're just making a shitty simple app, I don't really care about code quality. Example: I got Claude to generate a language server for TLA+ so I could have nice integration with Neovim. It took like 45 minutes of arguing with Claude and then it worked fine. This is incredibly low-stakes stuff: realistically the wor…

Yes I agree, the low stake, low evolution code is perfect for LLMs. The project I was handed is not that at all.

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

#340

Post by satvikpendem »

BugsJustFindMe wrote: post #283
satvikpendem wrote: post #214

Earlier quoted context omitted.

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.

> My point was that it is more likely for PMs to I feel compelled to point out to you that this is a completely unsustainable, unsupportable, unsubstantiable claim. You have met ~0% of PMs, and of the ones you've met maybe you've experienced a non-zero percentage of their work, but statistically that's also very unlikely. If you think you can say what most PMs do or what PMs are likely to do, then, I'm sorry, but you…

What a strange response. By your logic you've met ~0% of developers too yet I assume you can distinguish good development practices from bad. I also mentioned good PMs which by definition review and write good tickets with a clear explanation of the problem and what they want the solution to be. If personally meeting millions of people is the epistemic standard you have to know something then I'm not sure how you know anything at all.

As to your latter point, not sure why you think I think business doesn't continue on even with bad employees, of course it does and I didn't say otherwise. But that does not mean they're doing a good job, those two are orthogonal concepts.

And I'm not sure how we even got to this, the original point was that I personally as a dev can physically see PM productivity increasing with AI, even as other devs in this thread seem not to. For a competent PM, a tool that automates a detailed first draft fundamentally changes the psychology of ticket creation. If your argument is just "bad PMs will still be bad," then sure, I agree, but that doesn't really engage with how the tooling changes the workflow for everyone else.

Post reply on HN