Orbstack is definitely much better but far from native speeds in my experience. From our perspective of wanting all users to have a good experience, we also can't really point folks towards Orbstack as a "solution" to make the local dev experience great.
Yes, exactly. Probably two different focuses between us, we are more focused on providing the full environment to build productively with coding agents, from local dev all the way to prod. The key thing for us is that the agent can write code, build infrastructure and test the entire system autonomously locally, and then deploying to production should be dead simple.
A bit of a different approach from the classic use case of docker-compose that is often orthogonal to the production infrastructure in some sense.
One thing I've used to great success though is taking an existing project or example docker-compose and simply asking the coding agent to translate it to Specific's IaC. Works a treat, especially as the coding agent can read all the code at the same time and connect it all together.
We have been trying to solve the same problem (and a bunch of other ones) with https://specific.dev as well. We’ve tried to stay away from Docker as much as we can though because of the still pretty bad experience on Mac.
Our approach is having our CLI handle port assignments (and pass any connection details/ports along as env vars) and that way being able to spin up “isolated” copies of the local dev environment. Has the added benefit of us being able to deploy the same config straight to production and switch in production database connections strings and anything else needed.
Totally agree that AI coding makes this even more important. We are working on a coding agent-first cloud and a large part of that is ensuring everything runs locally so folks can let their coding agents define the infra and test it all
Better Auth is absolutely great. Was pleased with how well it could be extended here to replace Supabase Auth with backwards compatibility
Part of this is a reimplementation of PostgREST, but as a Typescript library. The big difference is that this is designed to help you migrate away from the auto-generated and to an API that is better designed for your actual use case. That’s why this is a library so you can integrate it as part of your backend and gradually replace the PostgREST parts
The storage part is really only for Supabase-js, yeah. The idea being that folks will eventually move to a model where they integrate directly through S3 (if they want)
We have been working on this, letting any coding agent define infrastructure so we can define it effortlessly: https://specific.dev. We aren't just targeting non-developers though, we think this is useful to anyone building primarily through coding agents.
> But those things are exactly things that LLMs already solve, especially for vibecoders who don't even know what the code is doing. For them it'd be so much better if the LLM just went with the standard SQL setup rather than Supabase/RLS.
This is precisely the approach we are taking for Specific (https://specific.dev). We believe you can move just as fast as you can with Supabase (whether you're a developer or not) if you just let coding agents code. What they are missing is the infrastructure parts, which we provide, like a private Postgres database that a backend can be built around (and which can't just be publicly exposed).
With that, I was referring to the definition in the article: "The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code". That's how Specific works.
And I think that opens up a very interesting question about quality. If the human never touches the code, then "good code" gets replaced with "good specs" instead, and I don't think anybody knows what constitutes good specs in that context right now!
The note on how all those tools seem to mostly be spec-first and vague about spec maintenance was interesting to me. Me and my cofounder have been going all-in on spec-as-source, as we think it's really the most interesting use of specs, but it's also challenging to get of the ground. If anybody has any thoughts on this, I'd love to hear them.
Also in case somebody wants to try a spec-as-source tool, we'd love feedback: https://specific.dev
I think specs embedded into existing code is a good idea as well, in fact there is some work being done in this area, like the Kiro editor: https://kiro.dev/
We have gone the all-specs route for now because it gives us an opportunity to try build that DX that you mention (which will be critical), without having to adapt to existing codebases that are no covered by specs.
Ah yes, we haven't spent as much effort on it as we could. Mostly been building the product itself!
Pricing is still to be determined. I imagine we will charge for infra usage (processing, storage, etc) in line with other providers like Supabase. We will also charge per-seat for developing inside Specific, which will likely be a fixed price with some token usage limit.
As for what's part of the beta, we currently offer hosting for the API and processing of requests, as well as a database to back it. We are planning on expanding that to support more use cases like background jobs, cron jobs, and object storage.
We don't offer built-in authentication and aren't planning to at this point. That's because we think there are much better providers (like Auth0, Clerk, WorkOS) that you can easily integrate in your Specific app by just specifying it!
That's the main difference to something like Supabase. We provide the infra automatically for your app to do what you need it to, but aren't opinionated around user-facing aspects like authentication. We also have the opportunity to be quite a bit more flexible. Building integrations with external APIs on Supabase for example often requires writing edge functions. In Specific, you can simply make it part of your specification.
That's a fair take. We are planning on showing the output code to remove that need for trust, but focused on other things for the open beta.
As for who it's for, we are targeting technical people who might know how to build backends in code, but we believe it can be done more productively through specs. The specs remove the need for boilerplate code and more closely match the business requirements of the system. One common example of this amongst our users is building third-party integrations. That can require a lot of boilerplate code and libraries to achieve. In Specific, it can be as easy as linking out to API docs.
> If Specific regenerates code from the spec each time (which I'm not sure it does), there's the potential for different code each time even for parts of the spec that haven't changed
It doesn't. When the spec changes, the coding agent takes the diff and turns it into the equivalent change to the codebase. The tests also run each time so that the coding agent does cause a regression as part of this. Although as you say, test suites are often incomplete. We are aiming to make it easier to build complete test suites in Specific than in regular code though because they are a part of the spec and the agent can you help write them as well.
We haven't done much yet in this area but I'm quite excited about how to evolve the codebase over time. I think we have an advantage in that a system evolving also means the specs are evolving and growing. We can maintain a loose mapping behind the scenes between specs and code for the coding agent, to give it the right context and keep code changes localised even as a system grows large. We can also refactor incrementally as we go as given that it becomes the job of the coding agent, instead of a human that might put it off.
> I think it's fair to say that you should highlight that upfront in your webpage because it's a more clear pain point than building other parts of backends.
Good point! We should do that :)
> My two cents: in my experience with integrations there are many issues that you can't control yourself because third-party APIs are buggy, incomplete, etc
Yes, I have actually spent a large portion of my career building such integrations and Specific has grown out of that. In my experience, working with specifications makes it much easier to focus on the behaviour of the API you are integrating with, instead of the code architecture or boilerplate behind your integration.
That's fair! We have considered how we could offer an open-source version of Specific but haven't found a good model for it yet. We are definitely open to it though!
Curious to hear more about the entity relationship definition. The schema for the entities and relationships is naturally an important part of it but how do you define the logic needed around them? For example integrations with external APIs
I think you really hit the nail on the head, thanks for sharing!
Privacy is definitely at the center of what I'm building. My approach is to put full control of their own data in the users hands. Data is only shared with a service when a user explicitly allows it and the user is always aware of what that data is. Your idea of being able to share nothing at all is also something I've been thinking a lot about. Being able to verify an identity without leaking any PII is one of my main goals.
I also agree with you on the issue of governments. There are very few who have managed to introduce a digital ID locally. A large amount of countries coming together and building a common solution seems very far-fetched currently. Where I'm from, Sweden, we have a well functioning digital ID used by everybody. Funny thing is that it was created by the private banks and only later adopted by the government.
It's definitely a hard problem but judging by the evidence it's solvable, just hope I'm on the right path. If you have any more thoughts I'd love to hear them!