Thanks for mentioning this, but it's definitely not what we're trying to achieve.
We may have underplayed a little, only because we have existing users already finding value with our current setup.
The goal is more like v0.dev, where with a prompt, you can generate your entire internal tool. We think we're not too far away from this (as shown in the YouTube demo).
This is the exact thing I've personally tried several times and it doesn't work well. But it works with a prompt in our app right now.
Some reasons listed below:
1. Gpt hallucinates shadcn's big data table implementation more often than not. Also, you don't have props for everything by default (page size, filtering, sticky columns etc)
2. We have certain rules we ask our AI to stick to, such as always putting a table in a card and consistent padding. So there's lesser cognitive effort in you thinking about how to style your tools.
3. Current LLMs are shaky with next14 right now, especially on where to use server and client components.
We mostly shrunk away from pitching the AI because we thought people will find immediate value in the starter and be able to use it (like our existing users/customers), but in hindsight that was a mistake, especially considering the AI is already decently valuable.
Just like Retool (or any other platform), you're expected to bring your own endpoint (but you're also free to write it in our app if you want).
The value will be in closing that feedback loop:
1. Here's the shape of the data coming in from endpoint /api/xyz. Currently, generating an endpoint with AI with this much nuance is very low in terms of success rate (and I think is what you're talking about).
2. However, once you know the endpoint and what the data looks like, our tool becomes valuable because you can just specify in natural language, which component you want to use, and how it has to be laid out on the page.
Several people will prefer natural language over dragging and dropping UI elements on a screen. And the success rate is far higher for something like this.
I'll chime in with my personal experience: I spend about 50-60% of my time in GPT-4 just pasting code, prompting for what I want and then pasting it back into my code editor.
If this is my workflow most of the time, then surely this can be more streamlined. The way to streamline it would be:
1. Can I tell GPT-4 about my components (and always be up to date)
2. Can I ask GPT-4 to write to the file directly
3. If the output has an error, can I ask GPT to look at the compile time error and auto fix it?
The 3 things I mentioned above is something I do every single day. We're just looking to make it easier.
Mainly their implementation of React Server Components, which is a far simpler set of APIs to work with compared to traditional React. (Also very LLM friendly)
The value is in being able to prompt AI something like "Here's my data that comes from endpoint X. Give me a table that shows this data that is also searchable."
I personally find that valuable (along with not having to think about which auth vendor and component library to use).
All you do is write a single page in the tools folder and deploy.
We embed those tools in our parent web app, which has authentication, team permissions etc. So you will never interface with the code that does that.
You just have to focus on your business logic.
In terms of the AI copilot, the main value prop is knowing about our components, and using them to stitch together something fast. (Instead of the AI writing the component from scratch.)
@swyx I personally think it's not just about AI engineering, because step function improvements in foundational models means that everyone's AI stack is in trouble, not just ours.
For us, an underrated part of what is valuable is the components and their API design. Being able to have a <DataTable /> with just the right props for the right use cases, so that a foundational model doesn't go and build it from scratch is useful.
The reason is mainly because now you save money on tokens, and save time because faster inference (since abstractions are already in place).
tl;dr give AI the right tools > trying to compete at foundational layer. (We are building those tools.)
Sure, bear with me for this might be a long answer. I'll start with some of my own use cases I tried and then expand into where I think this space is going.
With Retool, I tried building a form where if I change one input, the other input needs to conditionally change. I struggled a little with figuring this out, more than I should have. I also find it unwieldy to do any complex state management with a low-code builder (as in the case above), so it was a no-no for me.
At the same time, I understand that this feels like "writing code all over again".
The reason we don't believe so is because there's a hidden cost (cognitive effort) associated with picking the right component library, the right framework, etc.
Eventually, you won't be writing too much code either way for CRUD because of AI.
Let's say you want to edit some of the styling. Instead of writing some TailwindCSS, you will just ask our AI to say "move this graph to the right of the table" and it will just do it.
We're opinionated to the point of having our own CSS rule engine, to make sure that the padding is always the same when adding new elements on to the screen, so the goal is for you to not write code as far as possible.
Have a look at https://v0.dev, it paints a good picture of what we're trying to do with this.
We think the value is not just in one thing or the other, but being very focused on the whole: component library, framework, etc. and not giving options.
The reason is because it ties together nicely when you prompt our AI to generate the tool you want.
When you say "Give me a table on data X and a bar chart that is groups field X on the same data", there is no cognitive effort expended in thinking about which component library to use, getting AI to know about said component library, and writing code straight into your project.
Thanks for bringing up Refine, we are closest to them in terms of product.
Unlike Refine, we are highly opinionated on what you should be using, including component libraries, NextJS etc.
We think there's value in constricting the scope of what you can use because with our AI (which is live today), you can prompt for the tool you have in mind and it's going to give you something that looks good out of the box, which cuts down feedback time by a good chunk.
Personally I think they are on the right track, which is why we're over-invested in them.
Generally in our experiments, GPT-4/Claude Opus is able to generate Next-flavored React Server Components (RSC) a lot easier than anything else, because their APIs are simple.
We think there's value in an opinionated boilerplate!
But beyond just boilerplate, once you deploy your tools on our platform, we embed them in our parent web app which has the things you wouldn't want to bother writing (authentication, RBAC etc).
Also, we have AI that allows you to prompt for the tool you want when developing locally. It's actually live today, and we also show it in one of the videos.
The bigger goal is to have AI scaffold out your tool with our opinionated stack (the feedback loop for that is much quicker than asking GPT to create an entire web app).
Retool is a great solution if you like low-code, so I think it mostly depends on what you like.
For us it's 2 reasons:
1. I had trouble with low-code builders when building more complex apps, so I had to fall back to code. In that sense, we aim to be a thin wrapper around code (by making sure you don't write things like authentication, RBAC etc.)
2. We have an AI offering that allows you to create your tool with just a prompt, and iterate on it. It works more often than not because we're heavily opinionated on what components to use and how our app should be setup. The feedback loop is also faster than low-code because you're just iterating with prompts, so there's lesser cognitive effort.
We may have underplayed a little, only because we have existing users already finding value with our current setup.
The goal is more like v0.dev, where with a prompt, you can generate your entire internal tool. We think we're not too far away from this (as shown in the YouTube demo).