158
Longtime Linux Developer Steps Down From Some Roles Due To Patch Flood Caused By AI (www.phoronix.com)
submitted 1 day ago by to c/linux@programming.dev
28 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 32 points 1 day ago (5 children)

I'm a programmer. I vibecode a bunch of prototypes and personal projects. I couldn't imagine being inconsiderate or stupid enough to submit pure hallucinated code to any project, let alone a kernel project. And to have an agent open the PR for me, with code I haven't read or don't understand? absolutely insane

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 9 points 1 day ago

    Same here. Vibecoding my own tools is fine, because I’m the one who pays for the bugs. A kernel patch is different: thousands of people pay for them, so understanding every line is the minimum.

    Anyone who sends code to public software should follow a simple code of ethics. A low barrier to entry is great, it’s how most of us started. But the bar for responsibility should rise with how many people run your code, and right now it doesn’t.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 22 hours ago* (last edited 19 hours ago)

    I can't imagine myself doing that either, but I've seen that happen so often that it's just disheartening. I've asked for explanation of code in PRs and got "idk, the AI generated that" way too many times, and that's from professional software engineers, people who should know better. The corner-cutting is just too much for me

    Edit: typo

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 21 hours ago (2 children)

    Yup. I "vibe coded" changes to a number of projects, but I either kept it on my own fork (it's open so upstream can grab it any time they want), or thoroughly reviewed before submitting.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 20 hours ago* (1 child)

    Yep, pretty much. The only times I've ever submitted LLM generated code to a public project was when it was more or less identical to what I would have written by hand; and even then, I've never once considered having an agent hallucinate a PR...

    I knew the problem, I knew what the fixes would look like, I had the LLM draft the changes, I read it through and fixed up some slop and documented it appropriately. The code it generated: I understood, I wanted, I polished, I committed, and I owned as my code which I and nothing else was soley responsible for.

    That, to me, is a little bit different than pure vibe coding; where most of the time I won't even read it. Sometimes I don't even care what languages it's in. That is peak slop, and that doesn't go near anyone's machine but my own, unless they do it themselves (some of the more substantial and long-term slop project I have are committed in public Git repos, but all of the such slop projects are very explicitly documented as such at the very top of my readmes)

    My use of LLMs in real projects, where permitted, is entirely different. Mostly used for review and local (not committed) testing. Sometimes tedious mechanical changes, prototyping, factfinding, and brainstorming. But I do the thinking, and it's my code. My personal vibe projects and random scripts etc are more and more and less disposable, and I don't claim such strong ownership; it's cathurding, not programming.

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

    Yep, that's why I put it in quotes. As a software engineer of 10+ years (professionally, on a personal level, 20+ years now), I can understand code even if I am unfamiliar with the language and the frameworks in question. I know what needs doing (not just random "do this feature, make no mistakes" bs prompting), I know roughly how it can be done, and I let the LLM fill in the gaps.

    Plus I also work with a fleet of agents and a collection of skills to ensure its not crap being written. Multiple agents work with specific roles (say, embedded development expert, PlatformIO expert, and so on), there's a continuous verify-repair-improve loop, strict code quality guidelines and non-LLM checks in place. Of course it's not perfect, but it gets things 99% of the way, and at the end I just need to review and confirm things.

    For example one of the things I maintain is a private fork of CrossPoint reader, into which I've integrated BookOrbit, not just as a plugin that awkwardly allows retrieval of your books, but as an actual on-device library that downloads the right EPUBs and syncs not just reading progress but statistics (words per minute, page size and turns, reading time, etc.) as well. The library itself functions similar to a Kindle - all books are listed and with a tap you can download them. LLMs take care of rebasing my changes, with proper reporting on what's going on and why and how, how the rebase went, what upstream has fixed so I can drop the local version and so on. LLMs take care of API changes to be updated for, optimisations, the list goes on - but before any change is executed, I go in and get an understanding of what really changes.

  • permalink
  • fedilink
  • source
  • parent