I agree that is part of the future of AI, you describe what kind of UI you need and the app generates a combination of UI components to match your needs.
I expect this to be a simple NLP mapping via local/cloud AI model to a JSON/DSL that describes the interface. Naturally, this won't work well for complex UI that are context aware but will do well for most simple apps/dashboards.
My question is: How do you plan to make this a business?
We're live with five businesses and 2000 daily users! The technical challenges in setting the mapping, ai model, and dsl that creates reliable outputs is the engineering value we deliver.
Doing this with the AI generating the backend is definitely going to be challenging, it's essentially the user vibecoding operations that mutate data and hoping for the best.
When I envisioned this, I though about this being more frontend focused by having UI components/sections that disclosure which actions (endpoint calls) they can access. This would be virtually risk free.
But I supposed you guys are trying to solve a much bigger problem then.
This is such an important step forward as we start to understand the 2nd order implications of AI and how it will change UIs in the future.
We used to have to allow + review 3rd party plugins for software so that people could customize it, but when the cost of development is near-0, we can simply hand over the development reigns to customers.
i love this because it seems like you've turned vibecoding up to 11 unleashing the non-technicals in your org to ship vibecode slop straight to prod. it's an idea so obviously terrible to most engineers that maybe it's actually really really smart. much bolder than yet another AI-driven dashboarding tool or smart notebook.
to address the elephant in the room... how do you think about technical debt incurred by users who likely do not understand the underlying data models, consider auth, etc?
I agree that is part of the future of AI, you describe what kind of UI you need and the app generates a combination of UI components to match your needs.
I expect this to be a simple NLP mapping via local/cloud AI model to a JSON/DSL that describes the interface. Naturally, this won't work well for complex UI that are context aware but will do well for most simple apps/dashboards.
My question is: How do you plan to make this a business?
We're live with five businesses and 2000 daily users! The technical challenges in setting the mapping, ai model, and dsl that creates reliable outputs is the engineering value we deliver.
Doing this with the AI generating the backend is definitely going to be challenging, it's essentially the user vibecoding operations that mutate data and hoping for the best.
When I envisioned this, I though about this being more frontend focused by having UI components/sections that disclosure which actions (endpoint calls) they can access. This would be virtually risk free.
But I supposed you guys are trying to solve a much bigger problem then.
This is such an important step forward as we start to understand the 2nd order implications of AI and how it will change UIs in the future.
We used to have to allow + review 3rd party plugins for software so that people could customize it, but when the cost of development is near-0, we can simply hand over the development reigns to customers.
Yes -- the future of SaaS looks more like a system of record, on top of which AI serve what's needed on the fly based on what the customer needs.
i love this because it seems like you've turned vibecoding up to 11 unleashing the non-technicals in your org to ship vibecode slop straight to prod. it's an idea so obviously terrible to most engineers that maybe it's actually really really smart. much bolder than yet another AI-driven dashboarding tool or smart notebook.
to address the elephant in the room... how do you think about technical debt incurred by users who likely do not understand the underlying data models, consider auth, etc?
Exactly ;) One of our customers say "we've given their entire team superpowers"
I've been dealing with technical debt for half of my career. Here's what we're doing to prevent it:
- We don't ship to prod or to the main repo -- each feature is a scoped, sandboxed, separately version controlled "app".
- We have a proxy layer to pin API versions, so if the underlying contracts change, we still support all past created apps.
- Authentication follows your SaaS platform's RBAC and authentication tokens, making it easy to share within a team or across multiple tenants.