alt Hacker NewsExcellent post. People always defend agentic/LLM-driven development by saying, "Well it's good enough", or "It works most of the time."
That may be tolerable for some user-facing app. But what if we start normalizing failures in the libraries, the infrastructure, and the compilers? Everything descends into a mess of unreliability, and that slows EVERYTHING and EVERYONE down.
Replies
Banking/Finance is the one industry I've seen push back against this type of thinking. Transactions must be handled in a perfect and repeatable way, or the system is unusable as far as the company is concerned.
There's definitely still AI/LLM integration happening, but is kept out of specific areas of the business.
However, we are not (yet) building probabilistic libraries right? Even if AI is used, the code it builds is still deterministic and will fail in a way that can be fixed.
Not unlike legacy code, where the original developers are long gone and no one knows when that system breaking bug is about to wake up.
Even in the best of cases tho, fully human written and reviewed code will still fail eventually.
So I would say we are not normalizing failures (yet) but rather normalizing legacy.
Write tests first. Have agent iterate until they are satisfied.
The point is that it boils down to writing the tests correctly, regardless of who is implementing the actual code. Hand-written code without test coverage has the same problems as AI generated code.
Exactly. Reliable abstractions are more important than ever. They're the dues the rest of us must pay to support vibe coding.
Counterpoint: software has always had bugs. People are fallible.
Perhaps designing with assumptions that the entire stack is imperfect is the route to higher quality, along the lines of chaos monkey, which randomly kills processes on production boxes… which ensures resilience is real.
Even without AI our tech stack is so deep it’s hard to imagine every feature at every layer being provably correct.
> People always defend agentic/LLM-driven development by saying, "Well it's good enough", or "It works most of the time."
The main argument for LLM-driven development is much simpler: "It will get better".
The current state of LLM coding is about a year old. Imagine if we dismissed human coding efforts after a year. Rust, Python2 -> Python3 transition, Python type checking, Windows, C++, … nothing of that was done in a year and emerged in perfection in the first year. Everything takes ages to mature into a usable product. LLM coding is still in the "throw mud at the wall and see what sticks" stage, give it some more years and see how it will develop and what approaches actually work at. For the time being, LLMs are just the most useful development tool in the history of development tools, that's a pretty solid start in such a short time.