Cian Clarke
Cian is Nearform’s head of AI. His areas of expertise span Generative AI, Natural Language Processing and Cloud Native Architecture. Prior to NearForm, Cian was a co-founder of ServisBOT, a startup in the Conversational AI space, and an early member of the FeedHenry team, acquired by RedHat in 2014. He has experience deploying trusted AI solutions across highly regulated environments such as Banking, Payments, Gaming and Government. An open source advocate, Cian has authored & contributed to many projects. When not working, Cian is an avid sailor & coffee aficionado
Why front-loading clarity with specs produces dramatically better results than one-shot prompting, and how to make the transition.
At Nearform, we came of age in the Node.js era. Event-driven programming and JavaScript backends have been our bread and butter for a decade. But lately, we've been asking ourselves: what does the next ten years look like? Where can we really make our mark? The answer that's captured our attention is AI-native engineering, specifically using specs to move much faster than traditional development allows.
I want to share what our experience has been over the last six to nine months in this world, from the traditional vibe coding approach through to what we consider the current state of the art.
There's a progression in how organizations adopt AI for development. Many companies think enabling Copilot means they're doing AI-native engineering. It doesn't work that way. Line-by-line assists don't bring mass productivity gains. They make individual moments faster without transforming the overall process.
Taking it further with agent mode spanning multiple files brings measurable gains, but this approach has a real ceiling. Unless you introduce new techniques and frameworks, you'll hit limits on what the models can achieve. Spec-driven development represents the current state of the art in my view. The gains are quite measurable, and crucially, it removes the ceiling that limits pure vibe coding.
It's remarkable to consider the timeline. Copilot has been around since June 2022. The term "vibe coding" was only coined in February 2025. Cursor's 2.0 release came out just two weeks ago. Kiro codified spec-driven techniques into an interface in July. Something is definitely in the water.
Let me describe what traditional vibe coding looks like in practice. I like to do a little demo, building a 3D unicorn rendering engine using vibe coding tools. You one-shot prompt what you want, the model starts building, then you realize you forgot a requirement along the way (let's say making the unicorn's mane customizable).
Then you notice it's building in Vue.js, but you know React. You ask for a rewrite. Then you realize the model didn't complete the mane color feature you asked for, just stubbed it out. The model gets stuck, starts iterating, and here's the consistent pattern: when models get stuck in vibe coding mode, they often wind up pointlessly cycling. Introduce a new debug logger, re-tool the test runner, pointless busy work since it's not sure how to fix the problem it's created.
Along the way, the model can often add features you didn't ask for. You spend time backing those out.
You run out of tokens. Then there's the results:
Non-determinism can really yield some hillarious outputs. In the case of the unicorn, more often than not I wind up with something that looks more like a sausage dog. Sometimes it comes out upside down. Sometimes it's lost a leg through what I can only describe as a tragic hallucination.
The spec-driven approach flips this dynamic entirely. Much like how engineers do better when forced to decompose problems and articulate the why behind what they're building, models appreciate the same methodology.
Instead of one-shot prompting, you start by asking the model to draft a PRD (in this case, a Unicorn Rendering Engine). You review the generated requirements (and remember you want to cusomise unicorn mane colour), hallucinated requirements that you don't need get removed, and you add specific context from your experience as an engineer that you think will make the model successful (for example - how to render a Unicorn in Three.js. Think Minecraft.)
From the PRD, you generate a technical spec that codifies architecture decisions (e.g. Use React, not Vue). The requirements document defines the what and why. The tech spec defines the how.
Then you decompose everything into a backlog of discrete tasks. Each task has just enough context for the model to complete it successfully. Much better bounded context windows. Separate context for each task rather than accumulating confusion.
The spec-driven unicorn actually looks like a unicorn. It has a mane. You can change the mane color. It comes in rainbow by default. You can change the body color. It's orders of magnitude better than the vibe-coded version, even though it takes longer to produce.
Bad Unicorn:
Good Unicorn:
What's happening? By grounding the model in specs, outputs become much more deterministic. Fewer wasted cycles on retooling, adding unwanted features, removing unwanted features. The spec-driven approach solves both the overeagerness problem, doing things you didn't ask for, and the undercompleteness problem, not finishing things you did ask for.
Of course, there isn't a huge market for unicorn rendering engines - but at Nearform, we've been using Spec Driven Development to help accelerate real commercial projects. We maintain a features backlog synchronized with a planning spec. Each task gets a branch. The spec updates as work progresses. We have staging gates that prevent anyone from moving forward without committing, pushing, and rebasing.
This matters because the pace of change in an agentic codebase is far greater than regular work. If someone forgets to rebase, the consequences compound quickly. The staging gate enforces discipline that becomes essential at scale.
We've sometimes struggled to apply SDD to large brownfield projects, but I'm confident the tooling will also catch up here. We've also found spec-driven is overkill for simple prototypes. For those, vibe coding tools do actually work much better.
We've found spec-driven fantastic for true MVPs, greenfield projects, and modernization work like upgrading from Node 10 to Node 22. It's particularly valuable for projects with challenging business cases where cutting timelines in half makes previously unviable work feasible.
Want to see the full presentation with live demos? Watch the complete AI Native DevCon Fall 2025 recording to see the unicorn demos and explore the BMAD method for deep spec-driven workflows.
