5 ms·

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

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.

20k 3mo ago
Analysing codebases with LLMs to find security vulnerabilities is completely unrelated to committing code generated with LLMs
- alchemism 3mo ago
  It's a fair comparison. There's a fair amount of plausible-sounding bullshit being peddled as a transparent advertisement for an ai-driven "code security" firm.
- bsamuels 3mo ago
  and how do you propose fixing the hundreds, if not thousands, of valid, impactful security bugs that frontier models will find?
  - slopinthebag 3mo ago
    That seems like an unfounded assumption. Why should one assume that Git Annex has hundreds or thousands of critical, exploitable security vulnerabilities?
    - bsamuels 3mo ago
      This isn't a problem that is isolated to Git Annex. There are many maintainers out there taking anti-LLM stances, and you don't have to look very far to find OSS projects drowning from the wave of bugs. https://daniel.haxx.se/blog/2026/05/26/the-pressure/ https://daniel.haxx.se/blog/2026/05/26/the-pressure/
      - slopinthebag 3mo ago
        Wave of bug reports which is quite a different thing. If you aren’t happy with their stance towards LLMs you can fork and fix yourself if you feel it’s necessary.
  - gspr 3mo ago
    If you can't fix them without LLMs, then you can't fix them. You probably shouldn't be trusted with maintaining the codebase in the first place.
    - simonw 3mo ago
      How about if you don't have time to fix them without LLMs?
      - gspr 3mo ago
        Then you don't have time to maintain the codebase. Sad, but sometimes true.
        simonw 3mo ago
        Welcome to volunteer-driven open source. (Update: you're a Debian developer so you're even more familiar with how that world works than I am.)
        sscaryterry 3mo ago
        When given the choice between putting food on the table, and being a purist, I'd take some bread. It is hard out there.
        gspr 3mo ago
        Sure. I did not mean to throw shade at people whose professional survival depends on doing this. 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.
        sscaryterry 3mo ago
        You are trying to establish that it is bad based on your beliefs. 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.
moffkalast 3mo ago
In ten years we'll look at human written code like the unreliable garbage it is, and never rely on anything that wasn't at least seriously looked over by an LLM. It won't be even close.
- KronisLV 3mo ago
  > never rely on anything that wasn't at least seriously looked over by an LLM 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.
  - moffkalast 3mo ago
    I remember back in the pre-2023 days where SonarQube was a big deal for Java static analysis, and I let it rip across an entire 120k line project at one point upon which it found something like seven issues, out of which only one or two were actual bugs. It was almost entirely useless. I think even Qwen would've done leagues better today. 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.
    - KronisLV 3mo ago
      > everything technically checks out 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.

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.

20k 3mo ago

Analysing codebases with LLMs to find security vulnerabilities is completely unrelated to committing code generated with LLMs

alchemism 3mo ago
It's a fair comparison. There's a fair amount of plausible-sounding bullshit being peddled as a transparent advertisement for an ai-driven "code security" firm.
bsamuels 3mo ago
and how do you propose fixing the hundreds, if not thousands, of valid, impactful security bugs that frontier models will find?
- slopinthebag 3mo ago
  That seems like an unfounded assumption. Why should one assume that Git Annex has hundreds or thousands of critical, exploitable security vulnerabilities?
  - bsamuels 3mo ago
    This isn't a problem that is isolated to Git Annex. There are many maintainers out there taking anti-LLM stances, and you don't have to look very far to find OSS projects drowning from the wave of bugs. https://daniel.haxx.se/blog/2026/05/26/the-pressure/ https://daniel.haxx.se/blog/2026/05/26/the-pressure/
    - slopinthebag 3mo ago
      Wave of bug reports which is quite a different thing. If you aren’t happy with their stance towards LLMs you can fork and fix yourself if you feel it’s necessary.
- gspr 3mo ago
  If you can't fix them without LLMs, then you can't fix them. You probably shouldn't be trusted with maintaining the codebase in the first place.
  - simonw 3mo ago
    How about if you don't have time to fix them without LLMs?
    - gspr 3mo ago
      Then you don't have time to maintain the codebase. Sad, but sometimes true.
      - simonw 3mo ago
        Welcome to volunteer-driven open source. (Update: you're a Debian developer so you're even more familiar with how that world works than I am.)
      - sscaryterry 3mo ago
        When given the choice between putting food on the table, and being a purist, I'd take some bread. It is hard out there.
        gspr 3mo ago
        Sure. I did not mean to throw shade at people whose professional survival depends on doing this. 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.
        sscaryterry 3mo ago
        You are trying to establish that it is bad based on your beliefs. 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.

moffkalast 3mo ago

In ten years we'll look at human written code like the unreliable garbage it is, and never rely on anything that wasn't at least seriously looked over by an LLM. It won't be even close.

KronisLV 3mo ago
> never rely on anything that wasn't at least seriously looked over by an LLM 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.
- moffkalast 3mo ago
  I remember back in the pre-2023 days where SonarQube was a big deal for Java static analysis, and I let it rip across an entire 120k line project at one point upon which it found something like seven issues, out of which only one or two were actual bugs. It was almost entirely useless. I think even Qwen would've done leagues better today. 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.
  - KronisLV 3mo ago
    > everything technically checks out 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.