B (36:36)
So a recent posting by one of the guys who's taken on the job of managing gnome's shell extensions was interesting and I wanted to share it so. But first of all, just to be clear about what GNOME is, for those who may be familiar with the Windows or Mac world, GNOME is to Linux and Unix, like operating systems, what Explorer and the Windows Desktop is to Windows or Finder, and the Mac OS UI is to Mac os. So it's the ui, it's the desktop, you know, File manager and so forth. All three GNOME Explorer and Finder, you know, are that for their respective environments. And GNOME is, you know, gnome. There was originally an abbreviation for GNU Network Object Model Environment. So since then it's taken on a life of its own and, you know, people just know it as gnome. Okay? Therefore a GNOME shell extension is an add on that adds a feature to the Linux desktop, which is what runs gnome. So here's what one of the shell extension managers wrote last week. He said, since I joined the extensions team, I've only had one goal in mind, making the extension developers job easier by providing them documentation and help. I started with the port guide and then I became involved in the reviews by providing developers code samples, mentioning best practices, even fixing the issues myself and sending them merge requests. Andy Holmes and I spent a lot of time writing all the necessary documentation for the extension developers. We even made the review guide guidelines very strict and easy to understand with code samples. Today, extension developers have all the documentation to start with extensions, a porting guide to port their extensions, and a very friendly place on the GNOME extensions matrix channel to ask questions and get fast answers. We now have a very strong community of GNOME shell extensions that can easily overcome or all the difficulties of learning and changes. The number of submitted packages is growing every month and we see more and more people joining the extensions community to create their own extensions. Some days I spend more than six hours a day reviewing over 15,000 lines of extension code and answering questions from the community. In the past two months, we've received many new extensions. This is a good thing since it can make the extensions community grow even more. But there is one issue with some packages. Some devs are using AI without understanding the code being produced. This has led to receiving packages with many unnecessary lines and bad practices. And once a bad practice is introduced in one package, it can create a domino effect appearing on other extensions. That alone has increased the waiting time for all packages to be reviewed. At the start, I was really curious about the increase in unnecessary try catching block usage in many new extensions being submitted. So I asked and they answered that it is coming from AI. Just to give you a gist of how this unnecessary code might look. Okay. And then he, he, in his posting he gives us a, a sample of this code that I'm going to dissect here in, in a second. So he, he provides us a, a sample of code that is that you know, is what he actually sees in submitted GNOME extension source where and it's got a whole bunch of lines. And then he says instead of simply calling and then he's calling a function super dot destroy he said, which you clearly know exists in the parent. And then he basically shows all of those lines and then the, basically the, a single line or single call is all you need. So he says at this point we have to add a new rule to the review guidelines. Any packages with unnecessary code that indicate they are AI generated will be rejected. This doesn't mean you cannot use AI for learning or fixing some issues. He writes AI is a fantastic tool for learning and helping find and fix issues. Use it for that, not for generating the entire extension. For sure, in the future AI can generate very high quality code without any unnecessary lines. But until then if you want to start writing extensions you, you can always ask us in the GNOME extensions matrix channel. Okay so for people who as I said are coders or, or code adjacent or code curious, this is, this is a, like there's a, just, just a perfect example of many different things going on here. So we're going to, we're going to look and understand this manager's annoyance so that we can also, and we need to look at it and understand it so we could talk about what AI is doing here and, and, and what's wrong. So first of all, modern high level languages have a construction known as tri catch. And Leo will be glad to know that this concept originated back in the 1960s with Lisp which used the semantics and catch and throw to essentially do the same thing. This first appeared in Lisp. So the Idea behind this is that if some code might produce an error at runtime, not when you're compiling it where the syntax passes, but when you're actually running it, where something bad happens, like you tried to divide something by zero, you can't, right? That's illegal. So that produces an error. The idea is that if you have some code that might produce an error at runtime, we don't want the entire program to just give up and explode. We, the coder, want to have the opportunity to contain the problem and to possibly handle it ourselves in some more of our own code. The suspect code code that might cause a problem is placed inside what's called a try block, which tells the runtime manager to literally try doing this. The try block is then followed by a catch block that's used to catch any runtime error that might unexpectedly occur while we're executing the code and inside that first try block. So in other words, we're telling the runtime manager, while code is executing inside this try block, don't freak out if anything bad happens, simply stop what you're doing for us there and execute the code. We have provided for this purpose in the catch block, which immediately follows the try block and we'll take it from there. So this allows code to be somewhat self healing and to handle its own errors internally, rather than simply crashing and saying, bam, this program has died. Okay, so now let's look at the specific case of this gratuitous AI generated code which this manager posted. In the example the manager provided we have some code in the try block that first of all cannot possibly fail. The code is already being extremely cautious. It first checks to see whether the super object contains a function named Destroyer. The test for that. Just asking the question, does this exist? Cannot produce an error. It will either return true or false. Either the super object exposes a destroy function or it doesn't. And then the way that conditional is written, only if the super object does expose a destroy function will that destroy function then be called on that super object. So this conditional that's wrapped in a try block cannot fail. It cannot cause an error. That could require the try catch exception handling mechanism to be invoked. It can't happen. But more than this, we learn from the context that the manager shared with us, which is that whatever that super dot destroy function is, it is apparently well known to exist and must exist in this Gnome shell extensions execution environment that makes it always safe to simply call the function. It will always be present and simply calling it can never fail. So not Only was the use of that try catch construction provably and obviously unnecessary to anyone looking at the code, because the conditional expression it contained, that's all it contains, is one conditional expression was first testing for the presence of the function and only calling the function if it existed. That conditional test itself was also completely superfluous because whatever that super destroy function might be, apparently it must always be present. That means that everything there, all of that code, other than simply calling the superdestroy function directly, was superfluous. It was gratuitous nonsense. So how did this happen? It happened because today's LLM based AI, as we've been saying recently as we've grown over the last year, to really deeply understand what is going on here, it doesn't understand even a little bit what it's doing. It doesn't know whether we're asking about the population of kangaroos in Australia or asking for code to destroy the super object. It's all the same to today's AI. It's all just language. Which brings us to the main point of this. The thing that I thought was most interesting was the observation that AI generated code could and would become infected with nonsense code like this. That's a very interesting observation on the part of this manager, and I'm sure it tracks everyone's intuitive and growing understanding of the way today's LLM based AI operates. Today's AI is all just astonishingly sophisticated pattern matching. So somewhere along the way, AI picked up that conditional test construction of making sure that a function existed on an object before calling that function would be good. It doesn't hurt to do that. But our code would get seriously bogged down. I mean, like the world's code would get seriously bogged down if we were to keep asking the runtime manager to verify the presence of of known existing functions before every time we called one. The point is that testing like this for a function that might not exist is a good thing to do, so there's a place for it. And AI picked up on that useful instance without any understanding of why, and is now salting the code it produces with that nonsense without need. Alternatively, you could protect yourself from a missing function by wrapping it in a try catch construction. We saw that too. So in this case, the AI did both of those things when neither were necessary. It didn't know why. It was just copying stuff it saw elsewhere where there actually was a need. But in this case, there's no need yet. It still copied that code because it saw it elsewhere without ever understanding It. So here's where the notion of infection of course comes in, which is from promulgation. We know that AI is training on what it finds out on the open Internet. Even if what it finds is code that it or some other AI previously emitted. That means that superfluous code like what we've just seen, which does not cause errors but adds nothing other than overhead and bloat, will tend to be self perpetuating. If this manager did not proactively strip this crap out of Gnome's open source shell extensions code base, it would remain there. It would get picked up by LLMs that were training on it, that would then further replicate it into the future. And the more it's replicated, the stronger it becomes. The pattern takes hold. Before long, code would be littered with this because non coders would be asking AI to write an extension without ever bothering or needing to look inside. Look, it works. Yes, and it's three times larger than it needs to be because there's all this am I me, Am I still me, Am I going to be me Crap. This, that's, that's like loaded into this. So I wanted to spend some time on this because I think it clearly represents a danger to open source code. The crucial thing to appreciate is that AI is producing code that it does not understand. It's amazing that it's able to do so, but it's not without, you know, some downside risk. And any code that doesn't actually cause an error, that forces it, it's. It doesn't cause an error that would force it to be debugged and to be corrected, that code won't be corrected or removed because it works. And if it's put back into circulation, other AI will train on it and it will continue to live and get amplified. So that said, I'm sure that all is not lost forever because I'm one. As I've been saying from the start, I am 100% just like this guy is who wrote at, at the end of his posting. I am 100% absolutely certain that some future coding AI, which we don't have yet that's been specifically designed for coding, will look at the code that was emitted by these early LLMs like we've just seen and shake its electronic head. It would be able to see and actually understand the code used in this example. It would know that super.destroy function must always be present in the super object. It would know that the super dot destroy function can always be counted on to be present. So it would Remove the conditional test for its presence. Then it would see that what's left in the try block, which is just that function call cannot possibly fail. It would completely remove the try catch construction and all of the code from the catch block, which would also be removed because it could never be executed. We're not there yet. The point is we could contain the problem in the short term, just, you know, by not blindly submitting AI code back into the public repository pool where AI will train on it and amplify bad practices. You know, not things that produce errors, but things that just produce bloat until in the future we end up having truly smart coding AI. I'm, I'm sure that's coming because code can be understood by a computer. I don't think language can necessarily be understood or at least not where, where we are today. Code can, it's. This is going to be possible. So there is hope for getting the, you know, even the human generated code cleaned up, I suspect leo. But anyway, I thought this was a really, it was just a perfect example of what is actually being seen in the wild, what AI is producing, why they've had to tighten the guidelines in this instance. And unfortunately it's unlikely that the majority of the AI generated code that is being put back into the public arena is being checked by people who know better than to allow this slop, which doesn't produce errors to persist. So the, the, the, the, the, the future is true coding AI that is able to look at this and just say, okay, we don't need any of this crap, let's get rid of. And we're, we're just going to call the function.
