Spec-driven development aims to change that: the source of truth is no longer the code itself, but a clearly defined intent that the code can be regenerated from, tested against, and maintained with.
At WeAreDevelopers in Berlin, I spoke with Predrag Radenkovic, CTO at Codeplain, about why some developers are skeptical of “review the spec, not the code” – and where this approach works today, and where teams still need to be careful.
What is the main shift from prompt-driven coding to spec-driven development? #
Predrag: Prompt-driven coding operates at the level of code. Every decision an engineer makes gets translated directly into the implementation. All the maintenance happens on the level of code, where the intent behind the original solution is no longer available to the coding agent.
Spec-driven development raises the level of abstraction. You treat the spec as the only source of truth: you define the necessary detail in natural language, and the system is built and validated from that. The intent persists in a simpler, more readable form. So you’re maintaining specs instead of code, and regenerating the code from them.
Agentic skills are what make that workable in practice. Developers don’t want to write specs from scratch, but they’re happy to read them, so the agent drafts the spec incrementally, and the developer reviews and shapes it.
Why are integrations a good fit for AI-assisted development, and where does direct LLM-based code generation usually break down? #
Predrag: With integration development, you’re essentially becoming an** expert on third-party systems** that LLMs already know better than any human. Agents are strong at researching the domain, understanding the APIs, checking implementations against the current documentation.
Where classic AI-assisted development falls short is maintenance. Integrations break in production all the time, and once you have a large number of them, you’re constantly patching code against systems you don’t control.
With spec-driven development, the intent lives in the spec. So, when a third-party system changes and breaks an integration, the fix is usually a very small edit to the spec, and then you regenerate the code from it.
Codeplain treats reusable specifications as the source of truth. What makes a good spec, and what do developers often get wrong when writing one? #
Predrag: Good specs are complete, precise, unambiguous, and free of conflicting requirements. Also, their functionality is split into smaller chunks of reasonable complexity. Free-form specs aren’t ideal because the agent has to process everything at once and validating the requirements gets hard. Structuring the spec into units is what makes it both readable and checkable.
That’s why we built the ***plain language. It lets engineers express intent precisely and keep full control over the functionality that gets implemented from it.
What we’ve noticed over 2.5 years of working on spec-driven development is that engineers aren’t especially good at writing precise specs, but AI agents are. And the other way around: engineers are willing to review a spec thoroughly. That’s the reason why we built agentic skills for writing and validating specs.
If implementations can be checked against the specification, how does that change testing, code review, and trust in AI-generated code? #
Predrag: The first premise of the SDD lifecycle is that engineers thoroughly review the specs. Once the specs are accurate, much of the work is done. Codeplain’s code generator then builds the code and, more importantly, validates that it conforms to the specs.
We do this through black-box tests written entirely from the specifications and executed against the code that was built. In the end, it’s up to the engineer to do manual testing and, if they want, to check all the test scenarios our platform created.
From your experience scaling integrations, what was the biggest technical lesson about using structured specs instead of direct code generation? #
Predrag: When you develop integrations, you become an expert in someone else’s system without creating any additional value compared to your competitors. And it gets harder as the volume of integrations grows. The biggest issue, though, is maintaining them, because** around 5% of integrations break each month due to changes in systems you can’t control**.
Coding agents are already great at researching and understanding external systems, and we use them to help us write the proper specifications. Once an integration is fully defined in a spec, it’s easier and faster to maintain, because the review cycle boils down to changes in the specs and the rest is automated.
Some developers are skeptical of ideas like “review the spec, not the code”. Where does this approach work today, and where should teams still be careful? #
Predrag: We picked integrations as the beachhead for our platform with exactly this question in mind. The approach works best where the implementation can be validated completely, where you can check the behavior against the spec without a human in the loop. Integrations fit that well, and we’ve seen the same hold in a couple of other verticals: scraper development and ETLs.
Where teams should be careful is anywhere full validation isn’t possible. Anything with a user interface, for example, can’t be checked the same way today. But we see a solution on the horizon. The technology just needs to mature, and it’s moving quickly.