240
GrapheneOS defends use of AI for coding (grapheneos.social)
submitted 1 day ago by to c/technology@lemmy.world
312 comments fedilink hide all child comments
 

GrapheneOS is currently defending its use of AI coding tools on Mastodon against complaints by various accounts claiming to be users.

We do not understand where you're coming from or why you're so incredibly angry with us. It's not justified and does not make sense.

you are viewing a single comment's thread
view the rest of the comments
[–] 4 points 19 hours ago* (last edited 18 hours ago) (5 children)

Ssshh…Most of those having a knee-jerk "AI BAD! YOU BAD!" reaction don't have any clue WTF an IDE is, how code completion works, nor the fact that by most metrics 95%+ of code now has "AI" in the chain…and has had that for YEARS.

https://github.blog/news-insights/research/survey-ai-wave-grows/

https://survey.stackoverflow.co/2025/ai

OMGWTFBBQ!

Here's a crazy idea…how about instead of "AI BAD! ME HATE AI" how about some nuance? Assume ALL software in 2026 has had AI assistance, and review it on its merits.

As for the devs at GrapheneOS directly…why were you (the general you) trusting them before? Humans can be plenty dicey in ways that affect code all on their own.

https://www.reddit.com/r/PrivacyGuides/comments/13s7mv3/why_i_deleted_grapheneos_louis_rossmann/

https://factually.co/fact-checks/technology/louis-grossman-grapheneos-drama-c1f2ae

Supposedly wonderful "human artisanal code" has plenty of fuckery.

https://en.wikipedia.org/wiki/XZ_Utils_backdoor

https://thehackernews.com/2024/03/urgent-secret-backdoor-found-in-xz.html

https://simonwillison.net/2026/Mar/31/supply-chain-attack-on-axios/

https://www.hivepro.com/threat-advisory/axios-npm-supply-chain-attack-what-you-need-to-know/

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 8 points 18 hours ago (4 children)

    Supposedly wonderful “human artisanal code” has plenty of fuckery.

    These are supply chain attacks and in the case of xz utils, the attacker had gone to extreme lenghts to hide the attack from a well-meaning, good-hearthed but overworked and burnt out solo maintainer.

    To compare this to bugs that people unwittingly introduce in normal human-written code is not sincere.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 17 hours ago* (3 children)

    Very well. Here -

    https://www.debian.org/security/2008/dsa-1571

    https://www.finnie.org/2024/05/13/i-discovered-the-debian-openssl-bug/

    That's the thing about "pure human slop": it doesn't need to be malicious to be catastrophic.

    The second link is particularly salient - kills the "supply chain attacks are special" argument because it is precisely about "unwitting bugs in normal human-written code just happen"

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 15 hours ago (2 children)

    Okay, but they still happen with orders of magnitude less frequency than bugs in AI code. Consider that the time between when rsync first adopted LLM-generated code and users en masse reporting rsync internal protocol errors during a backup was on the order of months.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 14 hours ago*

    I don't recall that one...but in fairness...AI generates a metric shit ton more code than humans. We'd have to normalize the results. Interestingly, looking it up now, someone DID normalize for that very case. Bug rate per commit for the AI-assisted versions landed within normal historical range. A pre-AI release had more regressions. The 3.4.3 regressions were primarily from the CVE security patches, not the AI work. Zero CVEs from the Claude-assisted commits.

    EDIT: Correct URL https://alexispurslane.github.io/rsync-analysis/

  • permalink
  • fedilink
  • source
  • parent