115
Longtime Linux Developer Steps Down From Some Roles Due To Patch Flood Caused By AI (www.phoronix.com)
submitted 12 hours ago by to c/linux@programming.dev
24 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 6 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 5 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 5 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