9 ms·
The idea behind this spec is to give users full access to their own data. For example, ORM-backed data could be consumed by an MCP server, an autonomous agent,
by iosifnicolae2 8mo ago
The idea behind this spec is to give users full access to their own data. For example, ORM-backed data could be consumed by an MCP server, an autonomous agent, or a vibe-coded app. The goal is to make the data layer flexible and interoperable so that any client can build on top of it.
Looking ahead, I believe the best product managers will be the end users themselves. They'll want to vibe-code their own frontends and connect them to a secure backend.
That raises a key question: how do we design a backend that's secure, safe, and robust enough to support a wide range of use cases while still being extensible enough for user-driven customization?
- carlual 8mo agoThis closely aligns with what I expect ZenStack could help in the AI era, which you could tell from the two demos I created : -[MCP](https://zenstack.dev/blog/database-to-mcp https://zenstack.dev/blog/database-to-mcp) -[Agent](https://zenstack.dev/blog/ai-agen https://zenstack.dev/blog/ai-agen) From my experience, a declarative and flexible AuthZ layer is the cornerstone of everything.
- iosifnicolae2 8mo agoThere are a few differences between ZenStack and the proposed specs — see this comparison: https://claude-zenstack-comparison-page-8lwqi-superapp-docs.bringes.workers.dev/docs/comparisons/zenstack https://claude-zenstack-comparison-page-8lwqi-superapp-docs....
- carlual 8mo agoThat's really a honest and thoroughly comparsion, thanks for sharing! To be clear, what I mean is the goal that it could be consumed by an MCP server, an autonomous agent, or a vibe-coded app are the same.