Vibe coding is funky, or so the platform engineers who have popularised this declarative-derived approach to software application development would have us believe. In contrast to imperative coding, where a developer with its step logic, loops and state changes, vibe coding makes use of high-level prompts to drive AI agents that codify a user’s creative intent (aka, the vibe of what they want) and build some or all of the required codebase, or a smaller component part of an application or data service. But musical trends change, so is vibe coding always able to keep step?
Let’s imagine a typical scenario that a developer might experience. They get the spark of an idea (or a vibe) and open their integrated development environment (IDE) and start hacking. To speed up the process, they throw a couple of prompts into an LLM, such as “build a dashboard that feels modern” and the process starts.
The model then scaffolds a user interface (UI) i.e. it generates the basic structure, layout and boilerplate code… and then fabricates a /stats endpoint (an API route providing real-time data, metrics, or usage analytics) to populate the UI and assumes authentication is already handled with an auto-renewing session. But the problem is, none of those contracts actually exist in the developer’s system. Meaning when they come to merge the outputs, they quickly end up looking clumsy on the dancefloor as the vibe gets less funky.
Oh oh oh, it’s magic
For a few hours, it felt like magic, but it doesn’t take long for ambiguity to compound. It’s a reality that Cian Clarke, has seen play out more times that he cares to remember. Clarke is head of AI at Nearform, a company known for its work as a digital consultancy of experts who build high-performance AI solutions, software platforms and data-driven products for enterprises.
“Vague prompts end up increasing hallucinations and the model starts to create busy-work for itself. Eventually, you’ve got a repository of slop. While context windows might help at the prompt boundary to mitigate the issue, they aren’t architectural memory. Ultimately, this approach doesn’t really help you to build a feature, it simply creates technical debt,” said Clarke.
Instead, he says, the teams that win are the ones who “encode intent precisely” because that’s where the real value lies. It’s almost like, even when the vibe is funky, taking the trouble to lay down some dance steps to guide the way. In software application development terms, we call that spec-driven development (SDD) and it is one of the strongest emerging methods helping engineers stay in the vibe.
This is because it translates business intent into machine-readable constraints, which both humans and AI can follow.
Crafting context engineering
“This means that the most critical skill for the modern developer is no longer syntax memorisation, it’s context engineering. That doesn’t mean we lose creativity; it means we channel creativity in a different way. This is the era where developers need to hone the craft of eliciting invariants and encoding contracts – and focus on making them the single source of truth that guides design, generation and verification,” detailed Clarke. “Let’s first be honest about why vibe coding is dying. It worked when teams were small, and the stakes were low because in the early days of a startup, or during rapid prototyping, moving fast and breaking things is a valid strategy.”
But says Clarke, AI tools aren’t mind readers, so they can’t interpret vibes. When you feed an LLM ambiguous, high-level instructions, it will inevitably create ambiguous, hallucinated code. In reality, ambiguity in prompts increases entropy, missing constraints create hallucinated dependencies and absent schemas lead models to invent structures. In the short-term, this might create superficially impressive code, but in the long-term, it means the developer is setting themselves up for a whole load of rework, inconsistency and low reproducibility.
AI requires precision to generate useful, scalable output. Without it, developers spend more time debugging the AI’s mistakes than they would have spent writing the code themselves from scratch.
Slipping into silos
Vibe coding also creates massive knowledge silos, as knowledge only exists in the head of the original developer (or the context window of a chat session that’s now long gone). This makes scalability a near impossibility, as the codebase becomes a graveyard of half-baked ideas glued together by intuition, rather than architecture and onboarding new team members becomes a nightmare,” explained Clarke.
We’ve seen this movie before. The rise of PowerApps, low-code platforms and rapid WYSIWYG builders promised the same. The result was a suite of unmaintainable black boxes, with no versioning or deployment governance.
The business impact of this is undeniable. Reliable software can’t be shipped on vibes and neither new engineers or AI agents will be able to reconstruct intent. This means shipping becomes unpredictable, and the business pays the price for misaligned features and missed timelines.
Clarke thinks that spec-driven development (and we’ll go with SDD hereafter) solves this challenge by encoding product intent as machine-readable context, including APIs, data shapes, state flows, non-functionals and acceptance tests. A plan decomposes work into a task graph, then code – whether human or model-written – must satisfy the oracles before it can ship. This turns ambiguity into clear constraints and allows the system to evolve. Essentially, it takes the initial creative spark and forces it through a prism of clarity.
“This might be the antidote to the chaos of vibe coding, but it’s not a return to the heavy, waterfall documentation of the 90s. SDD creates a lean, rigorous process, where detailed functional requirements, constraints and desired behaviours are defined before a single line of code is written. It’s a natural evolution to vibe coding, shifting the primary artefact from prompts or documents to structured, machine-readable intent that both humans and agents can reason over,” said Clarke.
The technical methodology
SDD generally follows a structured workflow, which mirrors how high-performing, human teams operate (but in a way that’s also optimised for AI execution):
1. It starts by defining specs: Stakeholders and senior engineers start by collaboratively creating detailed requirements – what a happy path through the system looks like, error states, acceptable timeouts, API contracts, acceptance tests and security constraints required.
2. Then AI decomposes the specs: Once the specs are defined, an AI model will break these down into a granular task backlog, with explicit dependencies. Tasks suitable for parallel work by teams of agents will also be flagged at this point.
3. Incremental build begins: Multiple contributors (human or agent) then progress in parallel on decomposed tasks. Layer by layer (boilerplate, UI, backend logic), the software grows. Each layer is developed incrementally, with different team members or agents each owning their ‘slice’.
4. Testing: Unit, property, integration and automation tests execute on completed PRs to ensure the work passes quality gates, doesn’t cause any regression and meets acceptance criteria as called out in the spec. Crucially, SDD forces teams to think critically about the problem they’re faced with up front. It bridges the gap between human intent and machine execution, and a great spec forces you to understand the ‘why’ behind the ‘what’.
“Many developers fear that such structure kills creativity, but that’s not the case with SDD. SDD channels the creativity of vibe coding into a workflow that can actually scale. It propels contributors up the value chain, keeping engineering scrutiny on target architecture, cross-cutting patterns and the health of the wider codebase. Engineers spend fewer cycles debating brace placement or fixing broken dependency chains, and more time crafting the architecture and user experience,” clarified Clarke.
Importantly, though, SDD isn’t the magic formula for every scenario. It thrives where complexity meets necessity. This means it’s perfect for projects where you’re starting new applications from scratch, or looking to add well-defined, discrete functionality to a legacy system.
The rise of a new developer
What all this means is that the traditional developer role is shifting from writing individual lines of code to orchestrating the entire development process. Essentially, it’s paving the way for a new ‘context engineer’.
Context engineers aren’t ‘cave dwellers’ waiting for a Jira ticket to slide under the door, they’re active participants who engage with product managers, designers and users to extract the truth of what needs to be built before starting to build it. They lead requirement-gathering sessions and articulate technical constraints to non-technical stakeholders, without hiding behind jargon. They’re focused on flow, rather than function, and always start by considering how new features fit both into the larger ecosystem and the target architecture of the system.
“The future of coding isn’t about being replaced by AI, it’s about learning how to direct it. If you can’t articulate exactly what you want, then AI won’t be able to build it. Mastering SDD is the key to staying in control and becoming an indispensable part of the modern software team. But we do also need to be realistic – if all you need is rapid prototyping to test a vague idea quickly, vibe coding will be better suited. However, when the prototype is validated, that’s when it’s time to rebuild with SDD, extracting behaviours into contracts, stabilising the schema, writing acceptance tests and rebuilding the implementation against those artefacts,” concluded Nearform’s Clarke.
We’re seeing this evolution in real-time. Plan-mode in modern editors and other AI-native approaches used by teams like Anthropic are producing strong results because they rely on context, not vibes.
Perhaps it’s time to change our dancing shoes, stop guessing and start spec’ing.