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

451–460 of 490 posts

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

#451

Post by jknoepfler »

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…

If by "much faster" you mean ~10% faster, then sure. Having actually measured gains across a few teams, I haven't found anything faster than that. And that's making no effort to amortize across the slowdowns introduced by shipping more bugs (which I also measurable, but is not necessarily damning. Yes, I'm well aware of the knee-jerk "then you need to use GenAI to write better tests!" - which, I will add, is more undiscovered, non-free work).

Writing "80% of the code" is not saving "80% of the time". Code is usually trivial and writes itself when other problems are solved.

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

#453

Post by tardedmeme »

dxdm wrote: post #449
banner521520 wrote: post #448

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.

You forgot to cite the source of your verbatim quote of an earlier comment here.

It's a karma farming bot.

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

#454

Post by tardedmeme »

leereeves wrote: post #433
tardedmeme wrote: post #390

Earlier quoted context omitted.

This evaluation appears to be AI-written itself. It claims a 3x slowdown and a 4x slowdown combine to produce a 158000x slowdown "because there are billions of iterations" - yeah well both versions of the program had the same number of iterations. Does anyone know how the 158000x slowdown happened? That's quite ridiculous.

It could be written more clearly but I think when it refers to a 4x and a 3x slowdown, it's actually a 4x slowdown and 3x larger code that causes cache misses, and the impact of those cache misses on runtime is surely much larger than 3x. > Each individual iteration: ~4x slower (register spilling) > Cache pressure: ~2-3x additional penalty (instructions don't fit in L1/L2 cache) > Combined over a billion iterations:…

3 times 4 is 12. What's the other 157988x caused by?

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

#455

Post by nijave »

BoxedEmpathy wrote: post #306
nijave wrote: post #101

Earlier quoted context omitted.

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

What tools are you using? What settings? What process? What's your code review like? I think this varies a lot. I find with a c++ project I'm working on that the LLM needs a lot of guardrails and guidance, and still gets a lot wrong. But with a vite/js project it often one shots complex and intricate changes in large codebases.

Claude Code with Opus 4.7 xhigh effort

Datadog + Python with a little AWS

It does better at writing code but diagnosing bugs and performance issues is a bit of a crapshoot. It's decent at diagnosing but when tasked with improving performance it gets a bit sketchy. It'll write something that runs but often times it either has subtle functionality changes or mediocre improvements

Other times I'll repeatedly have to push it to find the root cause. It'll say "hey this downstream service threw an exception that propagated as a 500" and I'll have to remind it that's a first party service with info available in the trace and source code also available that it needs to continue investigating.

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

#456

Post by pron »

rowanG077 wrote: post #317
pron wrote: post #277

Earlier quoted context omitted.

People who independently tried to use it reported that it is very much not workable: - "CCC compiled every single C source file in the Linux 6.9 kernel without a single compiler error (0 errors, 96 warnings). This is genuinely impressive for a compiler built entirely by an AI. However, the build failed at the linker stage with ~40,784 undefined reference errors."( https://github.com/harshavmb/compare-claude-compiler…

Well then as you say a 10-50KLOC C compiler is workable. Could you show me the C compiler that does manage to compile a modern Linux kernel that is of that size?

By "workable" I meant something more modest, say, successfully compiling SQLite, something that CCC fails to do unless you stretch the meaning of success (it seems the problem may have to do with register allocation, but I would say that register allocation is pretty much the only interesting job a C compiler does).

As to the Linux kernel, you're right that a compiler that can successfully compile it is likely to be bigger, but we don't know that CCC is able to do it, either. What we do know is that (when using the gcc linker and assembler) people were able to boot the RISC-V kernel in qemu. That's something for sure, but not enough to call it a successfuly compilation.

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

#457

Post by sarchertech »

satvikpendem wrote: post #413
sarchertech wrote: post #356

Earlier quoted context omitted.

For basic CRUD we’ve had no code solutions that PMs could have been using for decades. The truth of the matter is that software starts as basic CRUD and then given time and users evolves into its own special snowflake. Every single system given enough time and users will become a “complex system”.

The difference is no code tools are not flexible in the same way LLMs are. As long as PMs can articulate those snowflake requirements to the LLM then it will happily build it.

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.

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

#458

Post by echelon »

solenoid0937 wrote: post #351
ddosmax556 wrote: post #298

Earlier quoted context omitted.

I know and I agree. It sounds incredibly arrogant but it's frankly is a bid sad to see how much HN is lagging behind AI adaption. It's been 90% noise over the last 3-6 months about problems that aren't truly problems if you really look hard at what AI is capable to do already today. It's mostly ppl & process problems. I could post a comment like the one above below almost every article on AI. But it is what it is. It…

The HN AI skeptics are just bizarre to me. They are insisting to us that, no, the productivity gains we're experiencing every day, simply don't exist! It's not that they're using the tool wrong, it's that the tool just isn't capable of what we see before our own eyes! I guess our eyes and ears are simply lying to us? And then they ask for how we are managing to make things move faster. When you refuse to breach NDA a…

> When you refuse to breach NDA and give up your competitive advantage on HN

I want to know your alpha because that excites me.

These people have their heads buried in the sand.

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

#459

Post by serallak »

marcus_holmes wrote: post #368
Philip-J-Fry wrote: post #278

Earlier quoted context omitted.

I don't agree. I regularly get pieces of work someone product guy has thought up in an afternoon. They only care about the happy path, and sometimes only part of the happy path. I work for a global company that has to abide by rules and regulations in each country we operate in. The product guy thinks up some feature, we implement the feature, then we're told "actually, we legally aren't allowed to do this in 90% of…

I think this was TFA's point about "engineers have been begging to be involved earlier in the process forever". Which is absolutely true. It has to be someone's job to push back on the Product Guy's stupid idea and answer all the awkward questions about the not-so-happy path with it. Unfortunately, because of the way we've ended up with this process, that person is often the engineer tasked with building it, without…

But that it's not really the case in the example above.

It's not the software engineer duty to know about how a given product is legal in what regulatory environment. That is something that must be hashed out upstream, well before tasking somebody to write a program.

Granted, an expert engineer with strong domain knowledge could be aware of those kind of pitfalls, and offer insights during the product development phase. But again, that should be done before committing to a schedule or making implementation decisions.

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

#460

Post by wek »

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…

The article is correct to emphasize the importance of definition and that this can be a bottleneck. But it is incorrect to show the layered documentation and development lines taking just as long as they did pre-coding-agents.

Our team is coding much much faster at high quality then we were before coding agents. As this commenter says, if you empower individuals and small teams to define, document and they set up good practices and harnesses, they can accelerate dramatically.

Post reply on HN