Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
GNOME AI Programming

New Rule Forbids GNOME Shell Extensions Made Using AI-Generated Code (phoronix.com) 67

An anonymous reader shared this report from Phoronix: Due to the growing number of GNOME Shell extensions looking to appear on extensions.gnome.org that were generated using AI, it's now prohibited. The new rule in their guidelines note that AI-generated code will be explicitly rejected:

"Extensions must not be AI-generated

While it is not prohibited to use AI as a learning aid or a development tool (i.e. code completions), extension developers should be able to justify and explain the code they submit, within reason.

Submissions with large amounts of unnecessary code, inconsistent code style, imaginary API usage, comments serving as LLM prompts, or other indications of AI-generated output will be rejected."

In a blog post, GNOME developer Javad Rahmatzadeh explains that "Some devs are using AI without understanding the code..."

New Rule Forbids GNOME Shell Extensions Made Using AI-Generated Code

Comments Filter:
  • by RitchCraft ( 6454710 ) on Sunday December 14, 2025 @12:49AM (#65857027)

    "Some devs are using AI without understanding the code..." - Well isn't that the point of "vibe coding"? That's what those pushing AI tell us, right?

    • Surely you can't be a developer and not understand the code.
      • by Himmy32 ( 650060 )
        Vibe coding definitely wasn't the beginning of some developers lacking understanding. Just a force enabler on their submissions to trusted community repos.
        • by dfghjk ( 711126 )

          but it may be the beginning of non-developers masquarading as developers

          • by allo ( 1728082 )

            And being developer is not about code. If LLM get good enough that you can program using instructions instead of code, that's not bad. People may be snobs just like they now may tell the $language1 is so much worse than $language2, but in the end it matters if people can use it.
            But for the instructions you still need to do the analytic thinking. Even if the tool writes the code for you, you need to see the big picture and what is needed in it. Otherwise you either get some software gluing together things th

            • It's not really the same as the process of using an LLM to create the code isn't repeatable. You might not get sufficiently working code feeding in the same instructions.

              The equivalent of this using a traditional computer language would roughly be to compile the code into binary, and then throw away the source code.
              • Why does repeatability matter? Once the code is written it's written. You may iterate but there's no reason to go back to the prompt if you got the result you want.
                • If you can't understand the code as allo writes above, then the prompts leading to the code is all you have. If that is not repeatable, how do you even know what to modify?

                  There might be some process here that can be used as a sustainable workflow but it's not at all obvious.
                  • by allo ( 1728082 )

                    I'm not believing in it being useful (as it is more cumbersome than learning a syntax), but of course you could setup a workflow programming in English. You can ask the LLM about the code (it understands and you do not), you can ask it to make changes, you can ask it to write tests, you can ask it to explain it, you can let it run it. People already do and they get to *something* working, the question is how good they are in maintaining and extending it.

                    The problem is the high level picture. Yes, a current

                  • I don't think it's acceptable to not understand the code. The LLM helps you write it faster, but you, the developer, need to have enough of an idea of what you want to verify it did the right thing.
                  • Test suite failures?
                • by StormReaver ( 59959 ) on Sunday December 14, 2025 @09:39AM (#65857461)

                  Why does repeatability matter?

                  Repeatability is a fundamental requirement of maintainability. A code generator that can't generate the same code over successively iterations over time is a useless, dangerous code generator.

                  ...there's no reason to go back to the prompt if you got the result you want.

                  Wants change over time, and code has to be extendable without breaking what's already there. Just because you got what you want now doesn't mean that what you want will stay the same over time. Without repeatability, your new wants will likely destroy the code that satisfied your prior wants. Replacing working code] with new LLM-generated code is a guarantee of breaking existing features.

                  • Look at the existing code. Think about how you want it changed. A few years ago you would spend 2 hours making those changes. Now you spend 5 minutes describing what you want, and verifying you got the expected change. Or maybe you ask it to achieve something and look at what it does instead of spending 2 hours studying APIs. In either case, nothing gets checked in you don't understand.
                • Because then the understanding that went into that code is non existent. By definition, nearly all LLM generated code is tech debt right out of the gate because a human didn't write it, thus it is not understood by anyone.

                  And since the EXACT same series of prompts will arrive at different code, I can't give my series of prompts to anyone else to implement anything. At least with giving specifications to different developers, and getting different code, I can go ask the devs how they arrived at that code. An

                  • To be clear, prompts are not a source of truth. They can't be. English isn't a precise enough language. You can pass them around as an example, but you cannot and should not expect identical results and that's okay. The prompts are not the code. The code is what got generated. The code is what will be modified in six months when requirements change. If you can't understand the code you have no business checking it in. Unless your task is specifically to provide useful prompts to others, you should treat pro
              • by allo ( 1728082 )

                Why shouldn't it be repeatable?

                I hate how people hear the word "stochastic" and without understanding think things would be random. Same Input (Seed is a part of that) gives same output. 100% repeatable. If you don't like having a seed controlling variance, set the temperature to 0.

                • Why shouldn't it be repeatable?

                  I hate how people hear the word "stochastic" and without understanding think things would be random. Same Input (Seed is a part of that) gives same output. 100% repeatable. If you don't like having a seed controlling variance, set the temperature to 0.

                  Ok, fair point. However from what I have seen the current set of tool aren't really supporting this kind of repeatable workflow (yet?). You'd need to be able to store the seed/context window, and a repeatable reference to the actual model used.

                  • by allo ( 1728082 )

                    Good question. I think most tools (I only tested few) use low temperature 0.1-0.3 which means reproducible actions but slight variations. The reason is, that if you use T=0 and the task (e.g. LLM tool call syntax) fails you have no alternative. If you have T=0.1 you can generate a second for the LLM to get the syntax right.

                    To get a feel you best try yourself how sampling affects the output: https://artefact2.github.io/ll... [github.io]
                    Set temperature minimal to get all probabilities but the most likely one to be very s

      • There are loads of developers out there who currently rely on IDE features (that have been around for at least 15 years by this point) to write code that they dont understand, or simply copy and paste from other codebases or websites.

        Committing code you dont explicitly know how works is well embedded in many software development circles these days.

        • Ok, but are these people then performing their job adequately? If you are working in a team that uses code reviews, what do you do when you get a question about some part you don’t understand? It’s going to be pretty hard to get the PR approved in a well functioning review process.
          • I think you vastly underestimate how many devs there are working for companies basically independently.

            Ive been working as a developer for about 20 years now, and in IT for 30 - the first time I actually joined a “team” was less than a decade ago, before then I always worked as an individual developer for small companies (who usually had 2 or 3 devs, all working independently on stuff).

            I would safely say that the number of devs who have no one checking their code, doing reviews, or engaging in s

            • by Bongo ( 13261 )

              Why pay for two when one gets the job done?

              • Why two?  For the same reason even  the very best fighter-pilots have a "wingman". Perhaps most code  addresses  non-life-threatening activity; any crap that handles MOST cases will due.  But -- say -- code that runs my pacemaker or will run the laser system removing my cataracts was/is  certainly developed with multiple-Dev oversight.
            • This is an interesting perspective. I have a similar time of experience 25+ years in embedded development. We didn't always have formal code reviews, but I've rarely not worked in a team. Usually 3-4 people in the same discipline as me, and then cooperating with other disciplines.

              But as our perspectives are so different, I can't help to wonder what the actual ratio between single devs and team devs really is? Never seen a study on this.
        • It's important to know every "high level behavior" of what your code is doing.

          For example, even if you write a simple "Hello World" app, there's many layers of processing. Even if you write your "Hello World" app in assembler, there's a ton of various OS subsystems and hardware firmwares and microcontrollers involved. But at the end of the day, you trust your OS and hardware, and understand that your "Hello World" app will most likely just output "Hello World", but there's a always possibility of rare qui

          • You can trust your OS and hardware because it wasn't vibe coded.. Try again.
            • You can trust your OS and hardware because it wasn't vibe coded.. Try again.

              How do you know that though? Ken Thompson called out the risk of trusting trust [wikipedia.org] more than 40 year ago. I doubt you solder together your own hardware. As to the OS, even if you build it from source, can you verify each component to guarantee it wasn't developed with AI or with bad intentions?

              • We're talking qualitatively, but at completely different scales. The comment chain I replied to posits an equivalence between trusting a complex instruction given as an English language prompt to an LLM code generator, versus trusting a chain of well documented API calls with deliberately restricted semantics. It's completely different.

                Even when you add in the possibility of deception, there is no equivalence of trust. Vibe coding intrinsically doesn't follow the expected engineering patterns and practices

    • I think it's a viable way of "coding", but if the result doesn't compile ("imaginary APIs") or doesn't fit the requested style, then it shouldn't be submitted.

      I certainly let AI code things for me for research or as utilities, without attempting to fully understand the code. I ensure it does what I want and often try to get the opinion of more than one AI. It's a nice tool for getting stuff done that's not my main work. But submitting such code would require at least a code review and ensuring it works. At

      • by _merlin ( 160982 )

        Are the extensions written in a scripting language? Because if they are, the imaginary API usage won't actually break it until you execute that code path. And if the AI-generated code is really bad, the code might not even be reachable.

  • Just make them use formal methods and be done with it?

  • by NotEmmanuelGoldstein ( 6423622 ) on Sunday December 14, 2025 @04:02AM (#65857141)

    ... using AI without understanding ...

    There's a name for that: Script kiddie. But I remember it happening before the me-too behaviour got a name. When the Windows Vista side-bar appeared, thousands of people copied the source code for a clock widget, put their name in title, changed the colour scheme, then published it on Microsoft gallery. There were thousands of widgets with identical code, including the original copyright message.

  • Easy fix (Score:4, Funny)

    by goslackware ( 821522 ) on Sunday December 14, 2025 @06:27AM (#65857221)

    Claude AI Prompt:
    For the attached code, justify and explain the code.
    Remove unnecessary code, inconsistent code style, imaginary API usage, comments serving as LLM prompts, or other indications of AI-generated output.

    • by HiThere ( 15173 )

      Plausible, if it's good enough. The real problem here is lots of shitty code being submitted. So much that they need quick ways to get rid of most of it.

      As for "explain the code", that's trickier. I remember struggling to explain why I did something a particular way a few months later. When I figured it out again, it was the right approach, but it wasn't obvious why.

      • by gweihir ( 88907 )

        Does not work. I just ran a study with a student on this. Most vulnerabilities are not found, including by the expensive models.

    • Claude AI Prompt: For the attached code, justify and explain the code. Remove unnecessary code, inconsistent code style, imaginary API usage, comments serving as LLM prompts, or other indications of AI-generated output.

      I did your experiment to very simple Java code with Claude 4.5, literally less than 200 lines total, and it made changes that don't compile. It hallucinated an API call that doesn't exist. I even got excited seeing thinking "oh shit, Claude, your way is SOOOO much better than mine...why didn't I notice that API method?"...oh...because it doesn't exist! Friday?...used it like 5x, 2 of the times it inserted commas and semi-colons in the wrong places and didn't compile. It's very clear it has no clue what

      • by tlhIngan ( 30335 )

        Funny, given about 7-8 years ago I was tasked with coding in Java (something I barely have skills in except back in the Visual J++ days because it was the cheapest way to get Windows NT).

        No "vibe coding" for me, but I managed to piece together something that worked just by scouring the documentation I had, some code examples and a lot of Android Studio (IntelliJ) helping me with the syntax intricacies. The code worked, was relatively clean and I could explain it all. I'm sure a seasoned Java developer could

  • by allo ( 1728082 ) on Sunday December 14, 2025 @08:06AM (#65857331)

    GNOME doesn't forbid, but a certain distribution platform forbids it. And they take partial responsibility not to distribute harmful software.

    If you want to see how much ai users like "vibe coded" software go to some ai reddits and look how good the vibe coded project of the day fares.
    When everyone can code, everyone can produce crap they do not understand. What you often see:
    - YAGNI. Huge architecture even though you know the person will lose interest in maintaining the software in a month or two
    - Unreadable readme looking like someone with ADHD and a emoji fetish wrote it
    - Often custom licenses (probably AI generated) containing clauses that companies that make 100 mio or more cannot use the 500 line project under the open source license that should be granted to others (but effectively is not because of the clause)
    - Unsuitable programming languages of the tools like JavaScript/Typescript for command line stuff
    - 50th implementation of the same idea
    - Claiming to solve a billion dollar idea on a budget of just 100 dollar
    - Claiming to be the first who ever thought about this

    The list goes on and on. I think you get the idea and you may also get the idea why not ai generated code is the problem, but people who think they are programmers now because they can instruct an LLM.

    I'd love the people wanting to learn to code, but a few years ago they uploaded their better hello world to github and thought it is great and nobody cares. Now they upload the 50th ChatGPT-like LLM frontend that requires five services in the backend and even though the code follows best practices you can see at which places they will get problems once they need to extend it with more features and adapt to changes in the used tools.

    I'd say there is nothing bad when you're proud about your first watercolor image and your mom may hang it into her kitchen and is proud of you. And your friends think their part and compliment you and maybe give you a hint or two how to become better. But you shouldn't see that as reason to be disappointed that art galleries don't want to have it. It is great work for what you are able to do, but not a great work compared to what other people can do. As long as you're humble about it, you can get encouraging feedback even though people know it is crap, the problem starts when you claim that it should hang next to the Mona Lisa.

  • by gweihir ( 88907 ) on Sunday December 14, 2025 @11:53AM (#65857693)

    AI code above a certain very low complexity level is riddled with security bugs. One study found around 50% prevalence. That is really bad. In addition, people needing that AI to generate the code are NOT capable of finding and fixing them, even if they try. AI is not capable of finding or fixing them reliably either (including the models up to $200/month, I just ran a study with a student), with about 50% across-the board failure for real-world vulnerabilities and nearly 100% failure for CVEs. They do find merely 100% of toy examples, unless they are obfuscated. Oh, and get this: The "coding assistants" are doing significantly WORSE. We are still investigating why that is.

    Hence banning AI generated code is the only sane thing to do unless you are fine with everything going to shit.

  • Shockingly, it has been revealed that most developer don't understand machine language at all.
    Henceforth, devs will be asked to explain and justify every machine language instruction.

    • I see what you did there but LLMs aren't compilers. There is no source code except the prompts, and those do not really work for someone else to later add stuff or fix bugs.
      If there was working source (prompts) that could be revision controlled and that could be patched and regenerated, then I guess it would be workable to not tinker with the generated code.

      You wouldn't compile your C once, and then force any fixes to be direct binary patches to the executable, would you?
    • What an idiotic thing to write. You are trolling or either think you understand something you clearly do not.

      • by mad7777 ( 946676 )

        Thank you for your valuable input! Your opinion has been logged, noted, and duly discarded.

  • Don't worry - at the pace the Gnome development team comes up with and removes APIs, no extension will be accepted ever again.

Modeling paged and segmented memories is tricky business. -- P.J. Denning

Working...