188
Linus Torvalds posts his first AI-assisted patch to the Linux kernel, synthetic test clocks 23x performance leap — the bossman makes use of AI tooling himself after issuing clear pro-AI directives (www.tomshardware.com)
submitted 3 days ago by to c/technology@lemmy.world
139 comments fedilink hide all child comments
 

cross-posted from: https://piefed.social/c/linux@programming.dev/p/2509642/linus-torvalds-posts-his-first-ai-assisted-patch-to-the-linux-kernel-synthetic-test-clo

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 1 day ago (3 children)

At the architectural level, there's definitely a difference yes. But at the smaller scoped implementation level the latest models are pretty good compared to humans. Not perfect by any means, sure, but it's not all drivel anymore. It was 2 years ago, but today's definitely different.

Race conditions are generally harder to catch, even for human devs. And you're saying it as if Linus wouldn't have introduced it had he coded everything by hand, which I don't think is remotely guaranteed (like he never makes mistakes). And the review system clearly works just fine still.

Good developers can accelerate their work with agents, and you're right that you can generate tons of LLM-powered slop with it too. But that's why dismissing anything an agent wrote immediately is also wrong. The review determines if it's good enough, whether a human or an agent wrote it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 day ago* (2 children)

    I’m not really discussing smaller scoped patches, though. An LLM can change a single line in a file, sure, but the prerequisite there is that the file adequately contains the necessary context to do so. With small patches, you’re advantaged in that way.

    Larger patches suffer from a distinct kind of problem where the LLM can heavily over optimize submodules within the code, without proper consideration for the larger premise. This is a problem I’ve seen referred to as “decoherence.” In large projects, it can sort of take over the codebase after enough LLM engagement.

    Decoherence makes your codebase unmaintainable. The cost of every change increases logarithmically and the situation gets worse. The heavily optimized submodules are often incompatible semantically, so the agent also optimizes channels between them. This is an explosion in unwarranted complexity. This isn’t a human problem.

    Good developers can accelerate their work with agents. However, back to the topic on hand, reviewing agentic code changes is necessarily harder — because it’s prone to more issues that run far deeper. You have to review the code almost adversarially, with more cognitive load being used to unravel the gargantuan mess of barely sensible changes when viewed from a birds eye.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 day ago (1 child)

    You can also have multiple models review the result, seek consensus, and then review the results of that report. I find that's the best way to find legitimate issues, prior manual review. Huge time saver because the multitude of models can converge while you make yourself a cup of coffee, and you can find things that need to be fixed before you ask someone to spend their precious time in reviewing a pull request.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 day ago

    You don’t throw more oil on oil fires.

    Dont get me wrong, you can’t use AI to speed things up. But if you’re facing the problems I’m describing, then you need a targeted and explicit recovery effort — not just more bots.

    Remember part of the problem is the increased cost of every subsequent change.

    Humans will have this little voice in the back of their head, always screaming at them about how the architecture of an app should be adjusted to better account for a feature. We’re constantly reorganizing our apps, or backlogging features because we know that it should come with a reorganization.

    By contrast, an agent just does as it’s told. When you start using agents in a manner that outpaces your capacity to review and understand the breadth of its work, you’re necessarily ignorant of what changes should and shouldn’t necessarily be occurring. It creates the conditions for the problem which I’m referring to. Also, AI is really good at moving fast — so it created the preconditions of the conditions for the problem which I am referring to. It’s turtles all the way down.

  • permalink
  • fedilink
  • source
  • parent