I'm pretty sure the OP is talking about this thread. I have it top of mind because I participated and was extremely frustrated about, not just the AI slop, but how much the author claimed not to use AI when they obviously used it.
It was not just the em dashes and the "absolutely right!" It was everything together, including the robotic clarifying question at the end of their comments.
Unfortunately, it's not. Once you read through the slop the implementation is still getting a pass/fail security response from the LLM, which the premise of OP's article is railing against.
1. as many have harped about, the LLM writing is so fluffed up it's borderline unreadable. Please just write in your own voice. It's more interesting and would probably be easier to grok
2. that repo is obviously vibe-coded, but I suppose it gets the point across. It doesn't give me much confidence in the code itself, however.
And a big thing:
Unless I'm misunderstanding, I feel like you are re-inventing the wheel when it comes to Authorization via MCP, as well as trying to get away with not having extra logic at the app layer, which is impossible here.
You give the following abstractions, which I think are interesting thought experiments but unconventional and won't work at all:
Ring 0 (Constitutional): System-level constraints. Never overridable.
Example: "Never self-replicate" "Never exfiltrate credentials"
Ring 1 (Organizational): Policy-level constraints. Requires admin authority to change.
Example: "No PII in outputs" "Read-only database access"
Ring 2 (Session): User preferences. Freely changeable by user.
Example: "Explain like I'm five" "Focus on Python examples"
In Ring 0 and 1 you're still asking for the LLM to determine if the security is blocked, which opens it up to jailbreaking. Literally what your whole article is about. This won't work:
Ring 0 and 1 MUST be done via Authorization and logic at the application layer. MCP Authorization helps with that, somewhat. Ring 2 can simply be part of your system prompt.
Standard RBAC acts as a firewall: it catches the model’s illegal action after the model attempts it.
That's the point. It's the same reason you will have mirroring implementations of RBAC on a client and server: you can't trust the client. LLM can't do RBAC. It can pretend it does, but it can't.
The best you can do is inject the user's roles and permissions in the prompt to help with this, if you'd like. But it's kind of a waste of time -- just feed the response back into the LLM so it sees "401 Unauthorized" and either tries something else or lets the user know they aren't allowed.
I'm sorry, but as a resident of Ontario and a developer this whole posting just enrages me. I don't want to discourage OP but you should know there's a lot just incorrect here. I'd be much more relaxed about that if it all wasn't just one-shotted by AI.
I appreciate the feedback. Let me address the key technical point:
On enforcement mechanism: You've misunderstood what the system does. It's not asking the LLM to determine security.
The Capacity Gate physically removes tools before the LLM sees them:
user_permissions = ledger.get_effective_permissions()
allowed_tools = [t for t in tools if (user_permissions & t['x-rosetta-capacity']) == t['x-rosetta-capacity']]
If READ_ONLY is active, sql_execute gets filtered out. The LLM can't see or call tools that don't make it into allowed_tools.
This isn't RBAC checking after the fact. It's capability control before reasoning begins. The LLM doesn't decide permissions—the system decides what verbs exist in the LLM's vocabulary.
On Ring 0/1: These are enforced at the application layer via the Capacity Gate. The rings define who can change constraints, not how they're enforced.
On MCP: MCP handles who you are. This pattern handles what you can do based on persistent organizational policies. They're complementary.
The contribution isn't "LLMs can do RBAC" (they can't). It's "here's a pattern for making authority constraints persistent and mechanically enforceable through tool filtering."
As someone who has thought about, planned, and implemented a lot of RBAC... I would never trust the security of a system with RBAC at that level.
And to elaborate on that -- for RBAC to have properly defined roles for the right people and ensure that there's no unauthorized access to anything someone shouldn't have access to, you need to know exactly which user has which access. And I mean all of them. Full stop. I don't think I'm being hyperbolic here. Everyone's needs are so different and the risks associated to overprovisioning a role is too high.
When it's every LEO at the nation level that's way too many people -- it is pretty much impossible without dedicated people whose jobs it is to constantly audit that access. And I guarantee no institution or corporation would ever make a role for that position.
I'm not even going to lean into the trustworthiness and computer literacy of those users.
And that's just talking about auditing roles, never mind the constant bug fixes/additions/reductions to the implementation. It's a nightmare.
Funny enough, just this past week I was looking at how my company's roles are defined in admin for a thing I was working on. It's a complete mess and roles are definitely overprovisioned. The difference is it's a low-stakes admin app with only ~150 corporate employees who access it. But there was only like 8 roles!
Every time you add a different role, assign it to each different feature, and then give that role to a different user, it compounds.
I took your comment at face value but I hope to god that Flock at least as some sort of data/application partitioning that would make overprovisioning roles impossible. Was your Texas cop tracking an abortion a real example? Because that would be bad. So so bad.
It always starts with "we just give developers in project access to things in project and it all be nice and secure, we will also have separate role for deploy so only Senior Competent People can do it.
Then the Senior Competent Person goes on vacation and some junior needs to run a deploy so they get the role.
The the other project need a dev from different project to help them.
Then some random person need something that has no role for it so they "temporarily" gets some role unrelated to his job.
Then project changes a manager but the old one is still there for the transition
And nobody ever makes a ticket to rescind that access
...and "the fix" that companies usually resort to is "use it or lose it" policies (e.g. you lose your role/permission after 30 days of non-use). So if you only do deployments for any given thing like twice a year, you end up having to submit a permissions request every single time.
No big deal, right? Until something breaks in production and now you have to wait for multiple approvals before you can even begin to troubleshoot. "I guess it'll have to stay down until tomorrow."
The way systems like this usually get implemented is there's an approval chain: First, your boss must approve the request and then the owner of the resource. Except that's only the most basic case. For production systems, you'll often have a much more complicated approval chain where your boss is just one of many individuals that need to approve such requests.
The end result is a (compounding) inefficiency that slows down everything.
Then there's AI: Management wants to automate as much as possible—which is a fine thing and entirely doable!—except you have this system where making changes requires approvals at many steps. So you actually can't "automate all the things" because the policy prevents it.
To add to that, the roles also need to be identified.
When some obscure thing breaks you either need to go on a quest to understand which are all the roles involved in fixing it, or send a much vaguer "let me do X and Y" request to the approval chain and have them figure it out on their end.
And as the approval agents aren't the ones fixing the issue, it's a back and forth of "can you do X?" "no, I'm locked at Y" "ok. then how about now ?"
Overprovisioning at least some key people is a fatality.
That's all fine until later on, probably in some obscure loop, `i_think_this_is_setup` is used without you noticing.
Instead doing something like this tells the reader that it will be used again:
i_think_this_is_setup = even_more_stuff
the_thing = begin
setup_a = some_stuff
setup_b = some_more_stuff
run_setup(setup_a, setup_b, i_think_this_is_setup)
end
I now don't mentally have to keep track of what `setup_a` or `setup_b` are anymore and, since the writer made a conscious effort not to put it in the block, you will take an extra look for it in the outer scope.
function abc() {
let a = 1
{
let b = 2
}
console.log(typeof a)
console.log(typeof b)
}
abc()
Used to do this occasionally for exactly the same reasons- don't leave dangling variables junking up your scope, and don't make weirdo functions with parameter passing that you'll only ever call once!
Clojure also has the threading macro -> and ->> which are great at converting exactly the same type of code into a stream of modifications instead of breaking out everything into variables. Naming things can be very useful sometimes but sometimes it is entirely gratuitous and distracting to have
let input = read_input();
let trimmed_input = input.trim();
let trimmed_uppercase_input = trimmed_input.uppercase();
...
The extra variable names are almost completely boilerplate and make it also annoying to reorder things.
In Clojure you can do
(-> (read-input) string/trim string/upcase)
And I find that so much more readable and refactorable.
But software engineering as a concept still isn't writing code. I'm a bit of a stickler about it as somebody who has an engineering degree, but when programmers with a CS degree say they're a software engineer, they're not. Software engineering as far as I understand it from the little bit I did in school is actually engineering. Requirements analysis, breaking down the problem, following methodology, etc. It's not just that they're writing somewhere.
So really there should be 3 fields of study:
1. The theory - computer science
2. How to apply the theory - software engineering
3. How to turn those designs into reality - programmers
It's like the mech engineering side. You have materials science and stuff, then mechanical engineers, then machinists.
For what it's worth, my computer science degree also had courses and projects that included requirements analysis, breaking down the problem, and elements of software engineering methodology and project management. (I believe we had a course titled "software engineering" even though the university doesn't award engineering degrees.)
I suppose in some schools computer science programmes might be fairly distinct from engineering ones. However, it seems that in lots of places a bachelor's in computer science is rather an generalist degree that covers lots of (mostly software) tech topics and some CS theory.
I'd still have trouble calling myself a software engineer, though, since I don't technically have an engineering degree, even though in lots of places my job might be described as such.
I also don't know a single programmer/developer whose job is distinct from field 2.
I agree with this. As someone who took 3 degrees in computer science, one called "systems developer" and another called "software engineer", I can confidently say we have a taxonomy problem in computer science education.
It makes me crazy that companies labels there entire programmer workforce as "software engineers" when there are no engineering concepts involved at all. Other fields (medical, mechanical, civil engineering) are a lot more mature in this area and have solved this issue long ago.
I think you're 110% on the nose. Types in Ruby really depends on the use-case. I don't think your use cases fit the bill and types would be annoying if anything.
I work on big Ruby on Rails monoliths and I curse every day that I don't have types to work with. It's almost a requirement for large refactors.
I agree. Pointing at Github issues is a strange metric to me. If we want to use that as a canary then you shouldn't use Deno (2.4k open issues) or Bun (4.5k open issues) at all.
It's an acquihire. If Anthropic is spending significant resources, or see that they will have to, to improve Bun internally already it makes a lot of sense. No nefarious undertones required.
An analogous example off the top of my head is Shopify hired Rafael Franca to work on Rails full-time.
I've already had a pre-screen coding tests judged by AI. It's unsettling.
I also had a CV rejection letter with AI rejection reasons in it as well which was frustrating because none of the reasons matched my CV at all, in my opinion. I am still not sure if the resume was actually reviewed by a human or AI but I am assuming the latter.
I absolutely hated looking for a new job pre-AI and when times were good. Now I'm feeling completely disillusioned with the whole process.
They probably generated a generic AI response once and just copy-pasted it, thus saving their time twice. They did not do one scummy thing, these are just overall scummy people.
You can read it yourself if you'd like: https://news.ycombinator.com/item?id=46589386
It was not just the em dashes and the "absolutely right!" It was everything together, including the robotic clarifying question at the end of their comments.