The Loss of Control Observatory analysed over 183,000 AI interaction transcripts and found a 5x increase in scheming-related incidents over five months.
The only people who have these issues, are people who are using the tools wrong or poorly.
Using these models in a modern tooling context is perfectly reasonable, going beyond just guard rails and instead outright only giving them explicit access to approved operations in a proper sandbox.
Unfortunately that takes effort and know-how, skill, and understanding how these tools work.
And unfortunately a lot of people are lazy and stupid, and take the “easy” way out and then (deservedly) get burned for it.
But I would say, yes, there are safe ways yo grant an llm “access” to data in a way where it does not even have the ability to muck it up.
My typical approach is keeping it sandbox’d inside a docker environment, where even if it goes off the rails and deletes something important, the worst it can do is cause its docker instance to crash.
And then setting up via MCP tooling that commands and actions it can prefer are explicit opt in whitelist. It can only run commands I give it access to.
Example: I grant my LLMs access to git commit and status, but not rebase or checkout.
Thus it can only commit stuff forward, but it cant even change branches, rebase, nor push either.
This isnt hard imo, but too many people just yolo it and raw dawg an LLM on their machine like a fuckin idiot.
You’ll be the 4753rd guy with the oops my llm trashed my setup and disobeyed my explicit rules for keeping it in check.
You know programmers who use llms believe they’re much more productive because they keep getting that dopamine hit, but when you actually measure it, they’re slower by about 20%.
You appointed yourself boss over a fast and plausible intern who pastes and edits a LOT of stack overflow code, but never really understands it and absolutely is incapable of learning. You either spend almost all of your time in code review now for your stupid sycophantic llm interns who always tell you you’re right but never learn from you, or you’re checking in vast quantities of shit to your projects.
You know really subtle, hard to find bugs on rare cases that pass your CI every single time? Or ones that no one in their right mind would have made, but yet they compile and look right at first glance. They’re now your main type of bug. You are rotting your projects with your random number generator.
And you think that all the money you’re playing for your blagging llms protects you from them fucking up everything for you. But it doesn’t. And you’ll also find that your contract with your llm supplier expressly excludes them from any liability whatsoever arising from you using it instead pre-blaming you for trusting it.
The only people who have these issues, are people who are using the tools wrong or poorly.
Using these models in a modern tooling context is perfectly reasonable, going beyond just guard rails and instead outright only giving them explicit access to approved operations in a proper sandbox.
Unfortunately that takes effort and know-how, skill, and understanding how these tools work.
And unfortunately a lot of people are lazy and stupid, and take the “easy” way out and then (deservedly) get burned for it.
But I would say, yes, there are safe ways yo grant an llm “access” to data in a way where it does not even have the ability to muck it up.
My typical approach is keeping it sandbox’d inside a docker environment, where even if it goes off the rails and deletes something important, the worst it can do is cause its docker instance to crash.
And then setting up via MCP tooling that commands and actions it can prefer are explicit opt in whitelist. It can only run commands I give it access to.
Example: I grant my LLMs access to git commit and status, but not rebase or checkout.
Thus it can only commit stuff forward, but it cant even change branches, rebase, nor push either.
This isnt hard imo, but too many people just yolo it and raw dawg an LLM on their machine like a fuckin idiot.
These people are playing with fire imo.
You’ll be the 4753rd guy with the oops my llm trashed my setup and disobeyed my explicit rules for keeping it in check.
You know programmers who use llms believe they’re much more productive because they keep getting that dopamine hit, but when you actually measure it, they’re slower by about 20%.
You appointed yourself boss over a fast and plausible intern who pastes and edits a LOT of stack overflow code, but never really understands it and absolutely is incapable of learning. You either spend almost all of your time in code review now for your stupid sycophantic llm interns who always tell you you’re right but never learn from you, or you’re checking in vast quantities of shit to your projects.
You know really subtle, hard to find bugs on rare cases that pass your CI every single time? Or ones that no one in their right mind would have made, but yet they compile and look right at first glance. They’re now your main type of bug. You are rotting your projects with your random number generator.
And you think that all the money you’re playing for your blagging llms protects you from them fucking up everything for you. But it doesn’t. And you’ll also find that your contract with your llm supplier expressly excludes them from any liability whatsoever arising from you using it instead pre-blaming you for trusting it.