Specific is a platform for building backend APIs and services entirely through natural-language specifications and tests, without writing code. We then automatically turn your specs into a working system and deploy it for you, along with any infrastructure needed.
We know a lot of developers who have already adopted spec-driven development to focus on high-level design and let coding agents take care of implementation. We are attempting to take this even further by making the specs themselves the source of truth. Of course, we can’t blindly trust coding agents to follow the spec, so we also support adding tests that will run to ensure the system behaves as expected and to avoid regressions.
There is so much ground to cover, so we are focusing on a smaller set of initial features that in our experience should cover a large portion of backends:
- An HTTP server for each project. Authentication can be added by simply stating in the spec how you want to protect your endpoint.
- A database automatically spun up and schema configured if the spec indicates persistence is needed.
- External APIs can be called. You can even link out to API docs in your specs.
You currently can’t see the generated code, but we are working on enabling it. Of course, we don’t claim any ownership of the generated code and will gladly let you export it and continue building elsewhere.
Specific is free to try and we are really eager to hear your feedback on it!
Try it here: https://app.specific.dev
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.