• lobsters__pushcx@crustaceanson.theshelf.topM
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      9 days ago

      Yesterday I got an email responsibly disclosing two vulnerabilities in Lobsters, found with LLMs. They’ve been there 8 years. I have lost track of how many years-old vulns and bugs that LLMs have been identified in our codebase in the last two years. LLMs are making Linus’s Law true. Feels very much like the opposite of common, or that common is being redefined to a higher baseline quality level.


      score 4 · canonical

      • I see LLMs as scab, as scar tissue. They don’t solve anything, but they rush in to fill a void.

        Software has shown itself to be one such void: there’s massive unmet demand for software literacy: both to find bugs in existing software, and to create new software or customize existing tools.

        I just want to make sure the vision for the future is one of broad human code literacy. Nothing about AI should change the imperative that we break down the systemic barriers that prevent more people from being literate. Only broad human literacy will result in the creation of systems that sustainably and continuously serve the needs of their users.


        score 3 · canonical

  • lobsters__2@crustaceanson.theshelf.topM
    link
    fedilink
    arrow-up
    1
    ·
    9 days ago

    We have to accept that software engineering has changed a lot, and what we used to love doesn’t exist anymore.

    Overall there is a lot more noise, open-source is a mess, we learn about many data leaks every day, we get spammed about new business concepts that are more than ideas but half baked apps, we lose our jobs, but the software quality of some projects is improving.


    score 1 · canonical

    • A little part of me thinks that the open-source thing is by design. Maybe I’m giving the Machine God worshippers in the Valley too much agency, but it seems like making life hell for FLOSS and the funding going into Omarchy to win the hearts and minds of coders before “socialism” and Libre ideas corrupt them is an intended outcome.


      score 2 · canonical

  • I personally am not happy about this, the last place I want AI to touch is my Linux.

    Is that for ethical reasons or code quality reasons or both?

    If it’s the former then fair enough. If it’s the latter, one could make a credible case that Linus Torvalds is the most experienced code reviewer in the world.


    score 2 · canonical

    • This is true but I find it almost entirely irrelevant. Everyone’s code review practices are skewed by their incentives. Therefore “code review” is not one thing and very little of it is objective.

      When accepting the code from a human-submitted patch set, Linus loses none of his own productivity when rejecting the code. One of his super powers is having almost no specific productivity goals for the kernel code. He has plenty of productivity goals related to the kernel development process and he would certainly see a change-less release cycle as unproductive. However there has been no lack of supply on the change side for 30 years. When he is reviewing the code of an LLM, in the pursuit of some code production goal of his own, the quality bar for him accepting the code is lower. How much lower is an open question. However I think it is beyond debate that the demands of code review for others is drastically different than code review for our own ends.

      Critically, rejecting a human-submitted patch has a long term productivity benefit in many cases. Each of those rejections is a chance for Linus to not just make the engineer better informed about the kernel but also more familiar with the processes and values of the kernel project. I think it is safe to say that no one has become a subsystem maintainer without having many patches rejected. When Linus rejects a code generation from an LLM there is barely even a signal of positive intent to discard it. The code just goes unused.


      score 1 · canonical

    • I can’t comment that he will fail to review LLM code, but code churned by LLMs has different failure modes than human written code, so reviewing it is different. Notably LLMs easily use good terms and the code looks plausible, disregarding whether it is correct or wrong; while sloppy (no pun intended) code made by a person has often tells – i.e noticeable habits, wrong terms pointing out that they are new to the domain etc.


      score 1 · canonical

      • I think Linus Torvalds has rejected quite a few patches where a competent person implemented under protest the outcome of a corporate decision-making process. Which might not have low-level tells but might be absurd globally.

        Corporations are often human-hostile alien-logic decision-making machines, just like LLMs. They are just slower.


        score 2 · canonical

        • procedurally these may be similar, but my point is that LLMs get to the goal differently than humans, so the review skills are not obviously transferable between different types of authors. corpo logic may be alien, but that applies to outcomes, not means of coding.


          score 1 · canonical

      • Interesting. I review (and reject) a lot of LLM code, much of it in Rust or other typed languages. Less than 10% of the problems I have found are caused by subtle bugs. At least 90% of problems could be described as “over-expedient architecture” or “badly factored architecture.” This may be because I use a long list of linters and other automated checkers, and I’m not shy about asking LLMs to write proptests.

        Honestly, I like to imagine I’m careful. But the LLM probably finds as least as many of my bugs as I find of its. The biggest complaints I have all lie higher up.

        (People who don’t read the code, who don’t design good test strategies, or who use agents swarms mostly get what they deserve.)


        score 1 · canonical

        • lobsters__jackdaniel@crustaceanson.theshelf.topM
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          8 days ago

          sure; my point is that reviewing llm code and human code is not the same thing, even when we put aside the sheer volume and velocity - so the masterclass review skills of Torvalds of human coda are not necessarily as good guardrail as the grandparent suggests.

          edit: to add a metaphore - a top class swimmer is not necessarily a top class runner and vice versa


          score 1 · canonical

    • Yeah. If I had to pick literally one single human to read through 100,000 lines of bullshit PRs and firmly reject the bad ones, well, Linus has spent the majority of his “development” time doing that for 30 years now. And he’s not especially shy about rejecting bad code. (By which I mean mainstream media was starting to write about his rejections, and so he was sent for remedial social skills training.)

      So just to troll a bit, my new position on this issue is that only Linus should be allowed to use LLMs. I trust Linus to read the code and tell Claude what he really thinks.


      score 5 · canonical

  • Reading the patch message is honestly disheartening. I think everyone can agree that AI has some utility as a code reviewer at least. Whether to use it to generate code is controversial but certainly many people decide to. But replacing actual written communication, in English, for humans, with slop is a line that I wish we could all draw. According to Linus “the first draft” was written with an LLM.

    No reference, no on-stack bounce buffer, no seqcount, no check after the copy, and no limit on the size of the read.

    They stopped at what the validation cannot see:

    Known problems, and what I’d like eyes on

    I’m so viscerally sick of this style of writing that communicates so poorly and shows lack of human thought behind it.


    score 3 · canonical

    • This is just a branch found in the wild, right? It’s not actually submitted and meant for reading yet?

      I’d hold the judgement on the message which may be just auto-generated without paying much attention, because it’s not going to be posted as-is.


      score 1 · canonical

      • lobsters__dlisboa@crustaceanson.theshelf.topM
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        8 days ago

        I really think it’s a native language blindness a lot of people here have, but I’ve been reading technical “programming English” for 20+ years and LLM speak is exactly like tech blog speak from 20 years ago. As a non-native speaker with a flair for language acquisition I see this a mile away.

        LLMs just copied human production, people have been writing this prose style forever and it has been ingested as training data.

        Like I just went to your blog Simon and I can go to the earliest entries and read a style that LLMs would mimic today. The seeds of the mimicry are there, maybe not all in one article but as an aggregate.

        And I mean this as no disrespect whatsoever, it’s just language and there’s nothing necessarily wrong with it. They copied you, not the other way around.


        score 1 · canonical

        • Why are you so confident of that, if you’re a non-native English speaker? I’m a native English speaker, and I have also written and read many technical blog posts for over a decade, and I see Claudish all over the place.

          If what you said were true, then I would have never have seen Claudish, and that’s obviously not true.

          If you genuinely haven’t seen Claudish in English on the Internet in the last year, then I would suggest that’s because your English is not as native as you think it is. Or maybe you just don’t use Claude that much. (I use Claude all the time, because it is useful, but that also makes its tics very apparent when I encounter them on a blog. And yes it immediately makes me suspicious of sloppy thought.)


          Actually one prominent and sorta sad example is that I’m basically certain Professor Joe Hellerstein has been using Claude to write blog posts since April 2025. The timing is pretty suspicious on its own.

          https://jhellerstein.github.io/blog/

          e.g. https://jhellerstein.github.io/blog/cost-of-committing/ - so many Claudish tics here

          I was reading his papers on distributed systems (CALM, Bloom, etc.) over 10 years ago. That was technical prose.

          I don’t know if he had a blog prior to 2025, but I bet if he did, you can compare the prose and see that it’s now done with Claude.


          score 1 · canonical

  • For a long time, Linus refused to merge any patches having to do with hooking up a debugger to the kernel because he viewed debuggers as a crutch. His reasoning was, a competent programmer should be able to trace every line of code by hand and understand exactly what it does along with all side effects it has. And that finding bugs should be hard because it teaches you not to makes them in the first place.

    I guess a leopard can change its shorts.


    score 1 · canonical