I'm struggling to understand who or what this is for. The example shows creating an API, which is something that a technical person would understand the requirements for, but then it completely hides the generated output that the person just has to just... trust I guess. I feel this type of product has already been made redundant by 'agentic development environments' like Warp. (which have all the same issues lol)
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.
I'm curious if you do anything to control how the code evolves over time. Test suites are often incomplete and it's possible that behavior that is not fully specified may be unintentionally relied on.
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. This seems like a nightmare for maintainability and debugability.
> 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.
Thanks for the reply! I still worry about debugability. What if the generated code doesn't actually follow the spec? I understand that then generated tests would fail, but I assume there will be cases where Specific will fail. With no access to the code, it seems like there's no way to correct this. Is there any sort of escape hatch for these cases?
Funny, I've spoken about something like this to a colleague couple weeks ago. This could be a future of software development we're headed towards, if the DX is done right.
There are definitely cases where the spec is much easier to understand than the code that implements it.
Think systems with complex lifecycles or lots of required boilerplate.
Have you thought of embedding the specs into existing code?
E.g.
# @spec: if any method takes longer than 1s to execute, a warning must be logged
class X: ...
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.
What I find intriguing about this, from a conceptual point of view, is how similar the workflow is to the evolution of biological life.
Passing tests is a measure for the fitness of the system; how it achieves this goal doesn't matter. The code itself might be awful, or only work due to side effects or emergent properties, but it works!
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.
Sorry but looking forward to the open source version. With all due respect to your work I assume that what you are building will be quickly reproduced as OSS. Also, for a backend I think a typical entity relationship definition or declarative DSL are better than AI (e.g. deterministic and less error/security prone).
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
Thank you for your kind reply. Now that you mention integrations with external APIs, 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.
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. For top APIs there are, in general, good wrappers with tests to use.
> 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.
I'm struggling to understand who or what this is for. The example shows creating an API, which is something that a technical person would understand the requirements for, but then it completely hides the generated output that the person just has to just... trust I guess. I feel this type of product has already been made redundant by 'agentic development environments' like Warp. (which have all the same issues lol)
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.
I'm curious if you do anything to control how the code evolves over time. Test suites are often incomplete and it's possible that behavior that is not fully specified may be unintentionally relied on.
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. This seems like a nightmare for maintainability and debugability.
That's a good question!
> 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.
Thanks for the reply! I still worry about debugability. What if the generated code doesn't actually follow the spec? I understand that then generated tests would fail, but I assume there will be cases where Specific will fail. With no access to the code, it seems like there's no way to correct this. Is there any sort of escape hatch for these cases?
Funny, I've spoken about something like this to a colleague couple weeks ago. This could be a future of software development we're headed towards, if the DX is done right.
There are definitely cases where the spec is much easier to understand than the code that implements it.
Think systems with complex lifecycles or lots of required boilerplate.
Have you thought of embedding the specs into existing code?
E.g.
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.
What I find intriguing about this, from a conceptual point of view, is how similar the workflow is to the evolution of biological life.
Passing tests is a measure for the fitness of the system; how it achieves this goal doesn't matter. The code itself might be awful, or only work due to side effects or emergent properties, but it works!
The page is a bit sparse ;)
What will the pricing be after the beta? And what are you exactly offering? Only a database or also authentication or storage?
Can you maybe compare it to something established like Supabase?
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.
Sorry but looking forward to the open source version. With all due respect to your work I assume that what you are building will be quickly reproduced as OSS. Also, for a backend I think a typical entity relationship definition or declarative DSL are better than AI (e.g. deterministic and less error/security prone).
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
Thank you for your kind reply. Now that you mention integrations with external APIs, 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.
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. For top APIs there are, in general, good wrappers with tests to use.
> 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.