At the risk of having everybody go full on flame war. I'm going to take a bit of an opposite position. Code written with AI assistance does not require AI to change that code. This article seems to be concentrating on who to blame, for an error in code, rather than concentrating on how in the heck we're going to fix those errors. Saying that if the code was written by/or with the help of, AI, you're now going to have to have corporate sponsorship to fix any subsequent error. Is like saying we can't fix our product anymore because Fred left the company and Fred wrote the original code. Since the mid-90s, much of the development in Linux was done by people with corporate sponsorship. Sometimes third parties, quite often they worked for a distribution. That was a corporation.
Fingers are crossed on this one. I had gone back to using opus 4.8 instead of using opus 5. Simply because 4.8 is much better at remembering what it's doing and following instructions than 5. 5 often had a tendency to get halfway through solving a problem and then I would have to stop it in the middle, because it had lost its way and was going off on a tangent rather than dealing with the problem. In that respect, 4.8 was a lot more stable.
Fingers crossed on this one. I had gone back to 4.8, because 5 was not very good at following instructions or remembering instructions. I found myself repeating quite often what I wanted and what I was trying to do. Opus 5 was more like haiku than it was 4.8 in that respect.
As I read this article, as a non-coder (for a living) I noticed that what is being assumed is that the code produces a desired result. To that I will agree. You can really produce some bad code that has a positive outcome.
But as a counter proposal, I will submit that code can get so bad, that the product no longer produces a desirable result, no longer produces it in a manner that people want, or doesn't produce it at all.
Code that produces no desirable result or no result at all. Is as bad as it's going to get. It's a worthless pile of ASCII characters.
I too got laid off at the end of April. So what I've been working on since then has been AI. But of course, being the contrarian that I am, I'm trying to make small language model AI usable. The end goal is to complete all the pieces I need to create an AI empowered tool that you can point at an authorized Network, and it figures out on its own. What needs to be monitored. Learns what normal looks like on your network. Build your dashboards. Working both as systems monitoring and network monitoring. So right now my GitHub is full of both things that I need, for personal use, in this goal. Also with things that I need because they will become tools for the final product. https://github.com/linuxrebel. You'll get to see my contorted mind at work
For those of you who remmber the days of monolithic monster programs,you also remember the process of throwing more hardware at the problem. Then someone came along and asked "What if we broke it into chunks and then only load what we are using, when we are using it?
There was a time when the entire OS and the program you were running where both loaded into RAM and you ran from there. Limiting capabilities because hey 1MB of RAM was expensive.
We are reaching a similar point with LLMs. As useful and wonderful as they may be. The idea that you can just through a larger context window at it and it will solve your problem is proving false.It's being proven that the more you have the LLM actively remember, the dumber it can get.
This White Paper marks my research into this issue and what I've found out about how to maximize what an SLM can remember, preserving data integrity, performance,and keeping your data local rather than feeding it to the all consuming.
Feel free to give me feedback and thanks for reading.
I just had a wild thought. Combine Hister with my RepoSearch app. Point it at a companies Internal github/gitlab and have a searchable knowledge base of your git repos.
