‹ BackHN Continuity

Thread

In September, AI generated code has made up 17.25% of all Linux Kernel patches

32 points · 79 comments · tosh

  1. Ampersander · · focus · HN ↗
    The pressure to use LLMs is high in the companies that sell shovels in this gold rush. It would look bad if they did not use them. Linux developers work at those companies.
    1. simianwords · · focus · HN ↗
      in your version of the conspiracy theory, the developers are pressured to use AI for their patches in Linux from the company. not that they want to use it because they want to? Like everyone else?
      1. Ampersander · · focus · HN ↗
        I just wanted to bring up that it's AI companies (which all computer hardware companies are now) that develop the kernel. In that light 17.25% is actually a tiny share of commits to be written by the Machine God.
        1. simianwords · · focus · HN ↗
          Its not just that, you are implying that they are pressured to use AI and not using it out of their own will
          1. Ampersander · · focus · HN ↗
            The company is doing very well now and they know that it is all thanks to the AI data center build out. Their manager and leadership want them to use it. If the bubble pops, their stock based compensation becomes worthless. Their colleagues are in the same situation and some are tokenmaxxing.

            These things are what the pressure consists of. Some probably do feel pressured against their will. For some the encouragement changes their will. Some want to use it regardless of anything.

            But whether you call it pressure, encouragement, or incentives, its there and it does affect how people think and act.

            1. simianwords · · focus · HN ↗
              Or maybe.. people like the tech and use them? Instead of all these theories?
      2. bgregs · · focus · HN ↗
        I work for a company that contributes significantly to the Linux kernel, along with many other ventures. I can tell you for a fact that we are _heavily_ pressured to use AI tools for everything we do during the day (including writing documents for management review).

        Anecdotal, but the only people I've met who are truly excited about AI tooling were the lowest contributers prior to AI tooling becoming prevalent. The senior devs I interact with on a regular basis are largely negative on the trend, both for code quality issues and the burden it puts on them as reviewers. I can personally say that I am entirely burned out from reviewing the crappiest code I've ever seen, all day, every day, with no end in sight. When it takes less time to generate a revision than it does to review it, this is inevitable. Most people I work with have simply lowered their standards for code quality to meet management expectations for code velocity.

        1. simianwords · · focus · HN ↗
          Do you or your team contribute to the Kernel or you just happen to work in a company that contributes?
          1. bgregs · · focus · HN ↗
            Alright, I'll bite this one time, but based on your other responses I'm getting the feeling that you're not interested in points of view that differ from your own.

            I am not a kernel developer. That being said, I've been here for a bit and have worked across many different teams. Management communication and direction is not a secret here. It is well known what the expectations are for devs. I was directly told as much during a recent internal interview with a post-silicon team.

            If my lack of direct kernel experience somehow negates the messaging and mandates from management that I see every day, then I guess there's not much more I can contribute to this discussion.

            1. simianwords · · focus · HN ↗
              I think using AI for kernel dev vs AI for CRUD dev is an important distinction. In my company of mostly CRUD development, we are not pressured to use AI but we all use it willingly. There are a few who complain but they are a loud minority - almost everyone likes this tech.

              The reason I asked you is because I already have anecdotes and real life data for CRUD devs.

              I just can't fathom why people would be pressured to use AI. My hunch is that some people kind of begrudgingly admit that it actually makes people faster and they use it. These kind of people would rather like doing things a bit slowly.

              1. bgregs · · focus · HN ↗
                > I think using AI for kernel dev vs AI for CRUD dev is an important distinction.

                I completely agree!

                > I just can't fathom why people would be pressured to use AI.

                I can only speculate, and I obviously don't have any insight into why the mandates and usage targets exist, so I won't comment on that. I absolutely see value in using AI tooling as an additional validation step, but the generative side is what gives me pause. Maybe I've just seen too many cases of irresponsible use, but I'm not fully convinced that using the tools for _writing_ code produces better results.

                You were right to callout the distinction, and my apologies if I responded too bluntly. One of your original replies referred to company mandates as "conspiracy theories", which is where my hesitation to engage came from.

                Anyway, I think we're largely in agreement regarding your closing paragraph.

                1. simianwords · · focus · HN ↗
                  No issues, glad that we agree. I personally do use it for generative and I fully see the value for my CRUD engineer type of use. I think kernel development requires more scrutiny and we are not there yet where we can blindly use LLMs for Linux.

                  But my main point is that it is a bit strange to see these patches that are self disclosed as AI use and then come to conclusion that they were pressured to use it rather then use it because it is useful. I have never come across this kind of pressure, which is why I call it a conspiracy theory.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.