I'm a little bit unclear why these permissions need to be enforced at the AI kernel layer. Couldn't you put the chatbot outside your normal system permissions boundary and treat it as an untrusted user? The bot becomes an assistant that helps formulate user requests, but doesn't have any elevated permissions relative to the user themself.
You're exactly right—treating the LLM as an untrusted user is the security baseline.
The distinction I'm making is between Execution Control (Firewall) and Cognitive Control (Filter).
Standard RBAC catches the error after the model tries to act (causing 403s, retry loops, or hallucinations). This pattern removes the tool from the context window entirely. The model never considers the action because the "vocabulary" to do it doesn't exist in that session.
Like the difference between showing a user a "Permission Denied" error after they click a button, versus not rendering the button at all.
As someone that has built many of these systems, it doesn't remove the tendency or "impulse" to act. Removing the affordance may "lower" the probability of the action, but it increases the probability that the model will misuse another tool and try to accomplish the same action.
Ya, makes sense—if the model is trained just to "be helpful," removing the tool forces it to improvise. I’m thinking this is where the architecture feeds back into the training/RLHF. We train the model to halt reasoning in that action space if the specific tool is missing. This changes the safety problem from training the model to understand complex permission logic to training the model to respect a binary absence of a tool.
It lets you apply styles to a single element without it messing up the whole rest of the page/site/app. i.e. it disabled the primary feature of CSS, the thing most people don't want from it.
I agree that the primary feature of CSS is what people don't want from it anymore. If you're building your app with components (web components, react, etc), those become the unit of reuse. You don't need CSS to offer an additional unit of reuse, it only complicates things at that point.
This is a great point. Style reuse was the dream of CSS, but we have all mostly settled that that's too fine grained for anything beyond a simple website. It's much easier to build, share, reuse a bunch of components.
This is technically true, but misses the point. Tailwind classes are fine grained utility classes, the fact that they are CSS classes at all is pretty much an implementation detail.
Compare tailwind classes to bootstrap classes and you'll see what I mean.
Why do people prefer it over CSS modules? They also solve the style containment problem, and do not require any effort to set up, or any additional library to learn?
You're probably confusing something with something?
CSS Modules are a JS-only third party solution re-invented/re-implemented in a dozen different ways for various JS frontend frameworks. Requires setting up, requires learning an additional library.
If you mean these CSS modules: https://github.com/css-modules/css-modules?tab=readme-ov-fil... then they need to be supported by whatever build chain you use. And you literally need to use them slightly different than normal CSS. E.g. for Vite yuo need to have `.module.css` extension. And they often rely on additional libraries to learn. E.g. you can enable Lightning CSS with aforementioned Vite which comes with its own CSS flavour: https://lightningcss.dev/css-modules.html
If you mean CSS import attributes, they only appeared in 2024 in Chrome and Firefox, early 2025 in mobile Android etc. and they don't provide magical local scoping out of the box: https://caniuse.com/wf-css-modules
I meant the CSS modules that are implemented by a build tool. And yes, mea culpa, they are probably a js-only solution, requiring a build tool to correctly interpret a css import (.module.css in the file name is a common convention; but it is tweakable), and the author to use the imported object instead of plain strings, when referring to the class names. But I don't know if having to write `class="styles.foo"` as opposed to `class="foo"` counts as learning. And apart from that, there isn't anything else to learn.
But, given that one would need build tools for tailwind as well, the requirement for build tools couldn't have played a role in the choice between the two.
The problem is having to look in a different file for styling a component, and having to come up with a name for (at least one) CSS class per component. In traditional CSS, classes are intended to be reusable. You write a class definition once, and then use it in a bunch of different elements.
When working with a component-based UI (like in React), the components are typically the unit of reuse. Those CSS classes are used in one place: the component they're defined for. It's annoying to have to come up with a name for them, and to have to work in a separate file, especially if I just want `padding-inline: 4px` or `display: flex`.
Some argue separation of concerns, but CSS is inherently tightly coupled to the structure of your HTML: there's no getting around that. `.foo > ul` breaks if you replace that `ul` child with an `ol`.
I do agree that more intricate styling is harder to read with Tailwind, and I have some other gripes, too, but in general it's a good trade-off for component-based UIs.
> CSS Modules are a JS-only third party solution re-invented/re-implemented in a dozen different ways for various JS frontend frameworks. Requires setting up, requires learning an additional library.
I mean, Tailwind is not that different here - you must use a build tool to tree shake the styles, etc.
The above is an unrealistic example, but, you can't achieve that with the style attribute. You'd have to go into your stylesheet and put this inside the @media query for the right screen size + dark mode, with :hover, etc.
And you'd still need to have a class on the element (how else are you going to target that element)?
And then 6 months later you get a ticket to change it to blue instead. You open up the HTML, you look at the class of the element to remind yourself of what it's called, then you go to the CSS looking for that class, and then you make the change. Did you affect any other elements? Was that class unique? Do you know or do you just hope? Eh just add a new rule at the bottom of the file with !important and raise a PR, you've got other tickets to work on. I've seen that done countless times working in teams over the past 20 years - over a long enough timeline stylesheets all tend to end up a mess of overrides like that.
If you just work on your own, that's certainly a different discussion. I'd say Tailwind is still useful, but Tailwind's value really goes up the bigger the team you're working with. You do away with all those !important's and all those random class names and class naming style guide discussions.
I used to look at Tailwind and think "ew we were supposed to do CSS separate from HTML why are we just throwing styles back in the HTML". Then I was forced to use it, and I understood why people liked it. It just makes everything easier.
Good for them! I own two sets of noise-cancelling Bose headphones and a (dumb) speaker, and they've all been pretty solid, and for half the price of equivalent Apple headphones.
I'm still using stereo speakers even though the local store seems to only sell single units. They have bluetooth but I don't see why they would need to be "smarter" than this.
And we'd be wrong about that. Different domains are showing wildly different characteristics, with some ML models showing superhuman or expert level performance in some domains (chess, face and handwriting recognition for example) and promising but as yet just not good enough in other domains (radiography, self-driving cars, question answering, prose writing). Currently coding is somewhere in the middle; superhuman in some ways, disappointingly unusable in others.
I don't we can make any conclusive verdict about the promise of ML for radiography right now; the life-critical nature of the application it's in the unusable middle, but it might get better in a few years or it might not. Time will tell.
We just need to tax the hell out of the AI companies (assuming they are ever profitable) since all their gains are built on plundering the collective wisdom of humanity.
This is a great idea. I've thought about doing something similar! On the other hand, I'm not sure it's a business. Is this using AI?
The pricing seems extremely high for what's basically a call to https://github.com/faker-ruby/faker but that makes sense if it has to pay for OpenAI tokens.
(who knows though, plenty of B2B deals signed for sillier things than this - good luck, OP)
Thanks! To clarify, the core engine isn't AI. It's deterministic pattern matching, so it runs in milliseconds with no token costs. There's an optional "Story Mode" that uses AI for narrative-coherent data (like "a churning SaaS with seasonal trends"), but the base product is just schema parsing + smart type inference.
The difference from Faker: you don't write any code. Paste your CREATE TABLE, get data back. Faker is a library you have to integrate, configure field-by-field, and maintain as your schema changes. Different use case — more like "I need a seeded database in 30 seconds" vs "I'm building a test suite."
Fair point on pricing though, still figuring that out. Appreciate the feedback.
When the Rust version has the same take-up as the C version I know and trust, I might use it. Until then I'll wait. What's available now is good. I'm in no hurry to use an alternative. I like the idea of a reliable black-box, and I don't overly care how the black-box does its magic.
It's both. I stopped asking questions because the mods were so toxic, and I stopped answering questions because I wasn't going to train the AI for free.
reply