This is completely infeasible in the age of mythos. The reality is that the velocity is just not going to feasible from a security PoV without leveraging these tools.
If you aren’t happy with their stance towards LLMs you can fork and fix yourself if you feel it’s necessary.
(Update: you're a Debian developer so you're even more familiar with how that world works than I am.)
I'm merely trying to establish that it's bad. A lot of HN seems to be cheering for the badness. That is, to me, unfathomable.
I've pointed out to you that LLMs are forced onto people. I fear you are out of touch with the job market requirements of 2026.
All I'm trying to say here is that slopcode is generally a bad idea. If you are forced to slopcode to earn a living, I am not saying you shouldn't do that ("be a purist", as you'd put it). I'm just trying to point out that HN doesn't seem to generally acknowledge that concept as being bad.
Slop is not okay, this isn't disputed.
When you say "If you are forced to slopcode" you are implying that LLMs (or humans who operate the tools) can only produce slop with it.
No.
Just because you are forced to use an LLM, does not mean you can only produce slop.
I can imagine LLMs becoming a mainstay, but what you are describing isn't wholly different from sufficiently advanced static code analysis - where you'd want more determinism than most LLMs normally provide.
The problem is that such a thing might take a decade and billions of dollars of investments to create per-language (e.g. actually useful code analysis for Java, for Spring Boot, for processing and validating form data, and DB schemas and document processing and rendering reports etc., literal domain checks for anything and everything that is common across various enterprises) so nobody wants to do that, so it's easier to throw LLMs at it and call it good enough.
Most bugs are far too nuanced to be caught by static analysis imo, you do need to actually understand what's going on in the program, the intent, the environment, etc. instead of blindly verifying if everything technically checks out, compilers already do a perfect job at that.
So who's responsible for all of the Spring Dependency Injection bullshit with circular dependencies and AOP issues, stuff like @Transactional only working when called from a different bean, as well as the other hundreds of issues I've seen throughout the years? One can't just ignore that, because in many places that is most of the job market (alongside maybe .NET or PHP).
There's got to be some traditional way to spot every single one of the states that can be represented in code by the frameworks available in a given language, surely the correct answer is not "Yeah, an LLM said it looks okay because it's close enough to some training data that we have." It might be the practical answer, but only because all of our tech is built wrong.
Then again, writing provably correct code might be impossible in Java, at least with the currently available tools, because the ecosystem is such that the compiler can't do anything about all of the dynamic stuff that evil developers make you deal with at runtime.
Man do I enjoy my totally real full self driving.
For me, for all intents and purposes, self driving is here today.
> In ten years we'll be drowning in subtle bugs introduced by the unreliable garbage that is machine-generated code
Yes. But replace
> and the industry will hopefully have learned to never rely on anything that wasn't at least seriously looked over by an actual thinking human being that understands it.
with: "and the industry will throw even more LLMs at the problem, producing an even deeper soup of garbage that in some cases perform a tiny bit better, and when things do break it's always the fault of someone else. So for example a bank denies you a mortgage or an insurance company fails to process your claim, and you are almost certain that it's due to some slopcode somewhere, but you have to suck it up because the world has become accustomed that this is just how things are done."
It's a way of breaking computers that I'd never thought I'd see. We're wilfully taking the one cool thing about computers – them exactly interpreting instructions carefully crafted by humans to do exactly the right thing – with bucketloads of vibes that hopefully mostly do the right thing most of the time ("the tests pass"). What the hell are we doing.