Why Codeplain is betting on spec-driven software development

Every major paradigm shift starts with a murmur – a few lone voices that question the status quo, which grows into a chorus that’s difficult to ignore. In the world of software development, these murmurs have been frequent enough, but few have carried the resonance to spark lasting transformation.

Of course, there have been a few revolutions through the years, such as the shift from punch-cards to high-level programming languages, and the rise of open source and cloud computing, but by and large, the way we write and reason about code hasn’t fundamentally changed in decades.

This could be set to change in a major way, however, if a new approach catches on.

Spec-driven development (SDD), as it has become known, upends the traditional code-centric workflow, leaning on natural-language, plain-English instructions ("specifications") as the single-source-of-truth for how software should be built and behave.

While spec-driven development is still in its embryonic stages, a handful of companies and advocates are betting that it will transform software development as we know it. One of these is Codeplain, a startup that quietly announced itself to the world this month, with the promise of “spec-driven, production-ready code generation” – something that goes far beyond the limitations of vibe-coding.

Rethinking how software is built with spec-driven development

Codeplain is the handiwork of Dusan Omercevic, a software developer and engineer who sold a previous enterprise SaaS startup to LeanIX in 2021 (which in turn was acquired by SAP).

For context, Omercevic had been programming for the best part of four decades, and now with a little time and resources at his disposal, he saw this as an opportunity to go back to basics. Moreover, with LLMs now on the agenda after “basically zero progress” in traditional programming through the years, this seemed the perfect moment to rethink how software is built.

“After I made the exit, I returned to my roots and started doing a lot of coding and programming research,” Omercevic told AI Native Dev. “I started researching how the future of software development will look given that we [now] have large language models, and that led me to spec-driven development.”

It’s still early days for Codeplain, and while the company is keeping a lot of its roadmap under wraps for now, there are a few things that we do know. The company is building around the idea that specifications can serve as the authoritative blueprint for software. These specs don’t just document intent; they drive code generation, testing, and validation, ensuring that what gets built matches what was originally envisioned.

At the heart of this is ***plain, an open source specification language designed to express software intent in clear, human-readable form. Its syntax, Omercevic says, builds on familiar Markdown conventions, with structured sections, headings, and annotations that define features, behaviors, and constraints. In practice, this means developers can outline requirements or functionality in plain English while still producing machine-readable specs that drive code generation, testing, and validation.

Codeplain hasn’t published any snippets of what its new syntax will look like, something that most of us will have to wait at least another couple of months for as they finalize its design. But Omercevic confirmed that it will initially focus on a “couple of application domains,” rather than the entire field of software engineering.

“We want to leverage the expressivity of natural language while also having the precision and control of traditional programming,” he said. “And to do that, we had to take natural language and add some structure to it, and that is the language \[\\\plain\].”

A quick peruse of the company’s launch blog post reveals the kinds of problems Codeplain is trying to solve. Traditional coding often entangles the “what” (intent) with the “how” (implementation details), making it difficult to separate purpose from mechanics. Vibe-coding, meanwhile, can leave developers wrestling with ambiguity and fragile, one-off instructions.

Even when AI-generated code works, the original “why” behind it is easily lost, complicating later changes.

But perhaps the thorniest challenges for spec-driven development itself are the inherent ambiguity of natural language, in addition to what Omercevic dubs “functionality flickering.” On the one hand, plain English can be interpreted in multiple ways, leaving room for specs to be misunderstood. On the other, even when the intent seems clear, AI can still generate different behaviors due to “underspecification”.

For example, leaving a button’s colour undefined might yield a green button in one generation, and a red one in the next. The phenomenon has always existed in software, but AI-powered code generation amplifies it, because models can churn out countless variations quickly and cheaply, making the inconsistencies far more visible — and harder to dismiss as edge cases.

Codeplain’s answer to functionality flickering is twofold: make specs as detailed as possible, and stabilize the gaps with what Omercevic calls “micro decisions.” If a spec inadvertently omits an important detail, like the colour of a button, the underlying code generator chooses once, records that choice, and repeats it consistently in future runs. The result is that specs capture what really matters, while micro decisions ensure the rest doesn’t “flicker” unpredictably between generations. “It's one of the key challenges of spec-driven development,” Omercevic said. “If you want specs to be the single source of truth, then they need to include all the important information.”

It’s also worth stressing that unlike other AI coding tools on the market, Codeplain really is all about the written instructions. If something goes wrong with the software, the idea isn’t that you dive into the code and implement the fixes.

“If software is not working as you want it, you change it in the spec – it’s our core belief that this is possible, and that this is the future of software.”

Specs vs. prompts

It would be easy to pigeonhole Codeplain in alongside the myriad “vibe-coding” tools out there, from Lovable to Cursor and beyond. After all, anyone who can read and write “plain English” can surely write detailed specifications to build software… right?

If only it were that simple. Specs are not synonymous with prompts; specs must be unambiguous, repeatable, and comprehensive enough to serve as the single source of truth — qualities that plain English alone doesn’t guarantee.

But more than that, building complex software systems isn’t just about writing down what you want. It requires an understanding of architecture, dependencies, constraints, and trade-offs — the kind of technical knowledge that determines whether a system will scale, remain secure, or even compile. Without that grounding, a specification risks becoming a wish list rather than a workable blueprint.

And so while software developers are not strictly the target for Codeplain, they are undoubtedly the core market.

“We don't require programming knowledge, but we are focused on technical people,” Omercevic said. “You need to be technical. You need to have an engineering mind, which means that existing software developers are our customers. We want to take existing developers and show them this new paradigm.”

This also raises all manner of difficult future-gazing questions. If tools like Codeplain require an engineering mindset, how will the next generation of junior developers gain the skills to use them effectively? Will universities and coding bootcamps adapt their curricula to focus less on traditional programming syntax, and more on systems thinking and specification design?

Omercevic says software development has already gone through evolutions in the past, pointing to the shift from low-level assembly language programming in the 1950s and 1960s to higher-level languages that became mainstream in subsequent decades.

“I did some assembly programming back in the day, and [since then] we lost a lot of detailed understanding of how machines work,” he said. “But you still needed to be very technical. You still needed to understand a lot about computers.”

This tallies with what Tim O’Reilly recently wrote in The End of Programming as We Know It, which discusses how each new abstraction changes the developer’s role rather than eliminates it. Moreover, if historical precedence is anything to go by, we might actually see more programmers, not fewer, as new tools lower barriers and make software creation more accessible.

“There’s a lot of chatter in the media that software developers will soon lose their jobs to AI -- I don’t buy it,” O’Reilly wrote. “It is not the end of programming. It is the end of programming as we know it today.”

With spec-driven coding tools such as Codeplain now in the mix, Omercevic sees this as the next step in the long evolution of programming abstractions.

“We believe that developers are staying around, only we’ll give them ten times more power than before,” he said.

Spec-driven development: The state of play

Codeplain isn’t the only company working in the fledgling spec-driven development space. In the startup space there’s Tessl (which operates AI Native Dev), which recently launched a spec-driven framework and registry to make AI coding agents reliable.

Big Tech is also taking note. Back in July, Amazon debuted Kiro, an agentic IDE that turns natural-language prompts into structured specifications like requirements, design notes, and implementation guides, then uses them to steer the development process (listen to the AI Naive Dev podcast all about Kiro).

And earlier this month, GitHub open-sourced Spec Kit, a toolkit that treats specs as living, executable artifacts to guide AI agents. It’s a more structured antidote to vibe-coding, and while it’s still early days, it’s possible that GitHub may eventually position Spec Kit as something more akin to Kiro.

Before all that, though, there was SpecLang, a research project that emerged out of GitHub Next back in 2023. The purpose? To develop a plain-English programming language with AI turning those “specs” into working code. Notably, one of the original SpecLang creators was Johan Rosenkilde, a researcher and engineer who was also part of the original team that created GitHub Copilot.

Fast forward to 2025, and Rosenkilde is now an official Codeplain advisor and investor, a signal that at least some of the vision behind SpecLang is finding new life in commercial tools.

“We are working closely on how to take natural language and make it suitable for precision programming,” Omercevic said. “We are adding additional researchers and practitioners, because we want this to be as wide an effort as possible.”

Elsewhere, Codeplain has also secured an undisclosed amount of seed investment from the likes of Silicon Gardens in Slovenia, as well as angel backers such as Damir Sabol, now a director of software engineering at Google after the internet giant acquired his startup in 2022.

So it’s clear that there is growing momentum in the spec-driven software development space.

Omercevic, for his part, is remaining coy about Codeplain’s business model and exact launch plans. For now, it’s all about getting things ship-shape ahead of a fuller public unveil later this year.

Does AI make developers more productive?

It’s impossible to discuss spec-driven development without acknowledging the broader role AI is playing in software development today. Everything from code suggestion and automated code review, to test generation, debugging assistance, and full-blown code generation has become part of the developer’s toolkit — all driven by LLMs.

However, while the myriad AI coding tools out there are unquestionably powerful and showing clear signs of mainstream adoption, there is a growing sense that their benefits are maybe not all they’re cracked up to be – for everyone, at least.

A study presented by Yegor Denisov-Blanch, software engineering productivity researcher at Stanford, looked at data from nearly 100,000 developers from across hundreds of companies. The findings suggested that while AI could deliver productivity gains of around 20%, the reality was far more nuanced: some teams see dramatic improvements, while others experience little benefit (or even setbacks), depending on factors such as task complexity, codebase maturity, programming language, and project size.

Interestingly, Denisov-Blanch also pointed to a proclamation made by Meta’s head honcho Mark Zuckerberg on the Joe Rogan podcast back in January, when he claimed that AI will soon be able to replace most mid-level engineers.

“I think Mark was a bit optimistic, and he was probably acting like a good CEO would, to inspire vision, and also probably to keep the Facebook stock price up,” Denisov-Blanch said. “But what Mark also did was create a lot of trouble for CTOs worldwide.”

This “trouble,” according to Denisov-Blanch, lies in the notion that Zuckerberg’s gravitas would prompt CEOs everywhere to press their technical leaders on where they stood in their transition to AI – and for most CTOs, the honest answer would likely be ‘not very far.’

“I do think that AI increases developer productivity, but there's also cases in which it decreases developer productivity,” Denisov-Blanch continued. “So AI, or using AI for coding, is not a one-size-fits-all solution, and there are cases in which it shouldn't be used.”

Omercevic agrees that there are successes to point to, but they remain more the exception than the rule.

“I know some developers who are doing amazing stuff with agents, but they spent months optimizing their approach, and they can't really teach others how to go about it,” he said.

The problems aren’t purely about AI being thrust upon unwilling developers, of course. In some cases, developers may have a natural aversion to AI, and when they encounter their first problems, they use that as justification to abandon ship.

But collectively, this bubbling undercurrent of frustration is where the folks at Codeplain are setting out their stall.

“We are really focused on helping developers adopt AI in a way that works for them,” Omercevic said. “I'm a developer myself, I’ve worked with developers my whole life, and I really hate what's happening at the moment. Developers are super frustrated, because they get all this hype from the market, a push from the CTO that they need to adopt AI, but actually it's making them less productive.”