What are you talking about, kernel panics are part of life with consumer hardware. They would happen even if it was windows?
You're right. I don't use SSH that often due to kubernetes, infact I only use ssh for connecting to my desktop to access my tmux sessions and it's great. I know where you're trying to go with this and it's simply not true.
Who said anything about tmux? We're talking about neovim which is extremely light weight and the LSP's don't sit around being active all the time. They have a set duration where they terminate when unused which is simply not possible in most IDE's (LSP based ones are OK, but have problems reconnecting).
> kernel panics are part of life with consumer hardware.
This isn't right. It was certainly true in the nineties, but I haven't seen one in years on Windows and I spend many hours a day in it both for work and play.
DDR5 where yields are pushed with module level ECC? Janky amd gpu drivers, "RGB" controller drivers misbehaving, some hardware that is just as bad as it was in the 90's since they all use driver sourcecode copied from the 90s.
Kernel panics are almost entirely about bad RAM on all systems today. But last time I was stuck on Windows, about 2017ish, I was suffering constantly from blue screens in a way that never triggered on linux.
yes I mentioned tmux as a project management/switcher tool what about it? (how good (nvim) is with tmux and the low low memory usage.
I haven't had a kernel panic once on reliable hardware. Linux is way more stable than windows device drivers and progressively less reliable graphics drivers.
Perhaps they're more functional. Hooks are configured in the same settings file, which makes me pretty skeptical in the absence of explicit confirmation that they represent a stronger security boundary. (But of course, this is a fundamental challenge with LLM agent security - if you're using a well-aligned model that doesn't want to be prompt injected, how do you go about auditing something like this?)
ya they definitely cant stop everything. nothing can be stopped if you allow python honestly, but hooks are guaranteed to fire on every tool use so you can bake in explicit rejections for different patterns based on regex which can catch a lot of nonsense
Reinforcing an avoidance tactic is nowhere near as effective as doing that PLUS enforcing a positive tactic. People with loads of 'DONT', 'STOP', etc. in their instructions have no clue what they're doing.
In your own example you have all this huge emphasis on the negatives, and then the positive is a tiny un-emphasized afterthought.
I think you're generally correct, but certainly not definitively, and I worry the advice and tone isn't helpful in this instance with an outcome of this magnitude.
(more loosely: I'm a big proponent of this too, but it's a helluva hot take, how one positively frames "don't blow away the effing repro" isn't intuitive at all)
The trick is to explain why something is important, not just to emphasize it. For instance:
"As an LLM, when Claude used 'sed', it can quickly and easily break files that are difficult for the user to fix. Claude must be aware that an LLM's actions seem effortless to it but to the user it represents hours of work getting things back in order."
You're most certainly wrong on this one. Superior models give superior products and security over time. Until every 3-6 months stops bringing a large improvement in coding capability and scaffolding, there's no reason to assume we are nearing a hard limit.
You also have to factor in that bespoke software is... bespoke. ie. much more suited to your org's use-cases than the primary solution is. Way less bloat. Way less vulnerability when you don't need an enterprise SaaS solution and instead can host on your private networks.
And as far as security considerations: Imagine you had a separate Opus 4.6 agent tasked with managing and monitoring and updating devoted to a specific slice of vulnerabilities. Of course this is highly inefficient, but it would take care of the vast majority of vulnerabilities that even enterprise SaaS have. This is simply a scaffolding issue at this point, not model ability. Scaffolding issues like this will continue to dominoe.
>Until every 3-6 months stops bringing a large improvement in coding capability and scaffolding, there's no reason to assume we are nearing a hard limit.
How much of that is better models, and how much is it AI companies throwing more resources at each one? E.g. larger context windows and higher token/s correlate with the better models.
I also suspect AI is going to make software more secure rather than less.
Even today it can probably find a lot of issues automatically. With basic knowledge of what to look for, it certainly helps in understanding data flow too.
Agreed. This sentiment you are replying to is a common one and is just people self-aggrandizing. No, almost nobody is working on code novel enough to be difficult for an LLM. All code projects build on things LLM's understand very well.
Even if your architectural idea is completely unique... a never before seen magnum opus, the building blocks are still legos.
Another heavily overengineered AND underengineered abomination. I'm convinced anyone who advocates for these types of tools would find just as much success just prompting claude code normally and taking a little bit to plan first. Such a waste of time to bother with these tools that solve a problem that never existed in the first place.
No to be fair I do see what he's saying. I see a major difference between the more expensive models and the cheaper ones. The cheaper (usually default) ones make mistakes all the damn time. You can be as clear as day with them and they simply don't have the context window or specs to make accurate, well reasoned desicions and it is a bit like having a terrible junior work alongside you, fresh out of university.
The cheaper models can't be taught or improved due to their inherit limitations, which makes it a huge pain to even try with even the simplest of tasks. Perpetually, no matter your instruction file(s).
I agree. The more expensive models I must admit have impressed me, but sometimes they take so long and are so expensive you might as well do it yourself. That being said if you're feeling particularly lazy there is now a "do it for me" button built into code editors, but until perhaps 2035 this technology is still somewhat pedestrian compared to what it could be in the future.
> The only people who use LLMs "as a tool" are those who are incapable of doing it without using it at all.
Do you mean that? It's clearly false, but I don't want to waste time gathering famous-person counterexamples if you already know it's a huge exaggeration at best.
reply