In 2022, Tiran and I sat in front of our entire team — forty people — and laid out what we believed the world would look like by 2030.
The headline was this: technology will move beyond commodity value. Meaning the act of building software — the code, the sprints, the delivery — would no longer be where the value lived. The value would shift upstream, to the thinking. To the precision of the problem definition. To the specification.
We expected eight years to be right. It took three.
Spec-first development is a software methodology in which a complete product specification — covering user journeys, architecture, data model, permissions, and edge cases — is written and approved before a single line of production code is written. The specification acts as a contract between the client and the development team, guiding AI agents and human engineers through the build with no room for ambiguity. That’s what we do at specshop.dev. This article is the story of why.
What We Saw That Most Agencies Didn’t
I want to be honest about something. We weren’t smarter than the other 40-person studios running in 2022. We weren’t operating on secret information. GitHub Copilot had just launched. ChatGPT wasn’t public yet. The “AI will replace developers” discourse was still largely theoretical.
What we saw — clearly enough to act on — was a direction, not a destination.
Every business model that derives its value from the execution of a known process is vulnerable to automation. Always has been. Software development agencies, at their core, derive most of their billable value from execution: writing code that someone else has already defined, in formats that have been established for decades, using patterns that are well-documented enough to be learned by any sufficiently trained system.
The part that wasn’t automatable — the part that couldn’t be commoditised — was the thinking that happened before the code.
The decision that closed a 40-person studioThe conversation where you discover that the client doesn’t actually want what they asked for. The architectural decision that determines whether the system is maintainable in two years or a nightmare. The spec.
We made a decision most founders find uncomfortable: we shut the agency down on purpose. Not because it was failing. Because we could see what it was becoming, and we didn’t want to be the last ones to notice.
Why Spec-Driven Development Isn’t New
— and Why That Matters
Specification-first development has existed as a concept for as long as software engineering has existed. The waterfall model — for all its problems — got one thing right: you don’t build what you haven’t defined.
Agile, correctly understood, didn’t abandon that principle. It compressed the definition-build cycle into shorter loops. The spec still existed. It was just smaller and faster.
What happened in the last three years is not that spec-driven development was invented. What happened is that the cost of not doing it became impossible to hide.
When you write code manually, bad requirements slow you down. You notice them. You stop. You have a conversation. The friction is visible.
When an AI agent writes code, bad requirements generate confident, production-quality-looking output that doesn’t do what you need. The code compiles. It passes basic tests. It looks finished. And then you discover, three weeks into a build, that the entire feature set was built on an assumption the client never confirmed.
“Vibe coding can be great for quick prototypes, but less reliable when building serious, mission-critical applications. The issue isn’t the coding agent’s coding ability, but our approach. We treat coding agents like search engines when we should be treating them more like literal-minded pair programmers. They excel at pattern recognition but still need unambiguous instructions.”
Unambiguous instructions. That’s a spec.
The Data Behind “Vibe Coding” Failing at Scale
This isn’t conjecture. The production data on AI-assisted development without structured specifications is now damning enough to be worth examining directly.
Sources: Gartner research on AI in software engineering · GitClear 2024 analysis of AI-generated code churn
Independent telemetry from multiple 2025 studies found that developers report feeling faster, but organisational throughput doesn’t increase proportionally. Individual task speed goes up. System-level output doesn’t follow. The root cause in every case is the same: the AI was given a prompt, not a specification.
Code that works in a vacuum. Breaks in production. The 41% churn figure isn’t because AI writes syntactically wrong code — it’s because AI solves the stated problem in isolation while missing the architectural context of the broader system.
What a Spec Actually Does
(That a Prompt Can’t)
A prompt describes what you want in this moment.
A spec describes what the system needs to do — permanently, under all conditions, for all users — and why.
The difference isn’t semantic. It changes everything downstream.
When we built a three-sided delivery platform — separate interfaces for the rider, the kitchen, and the customer — in three days, people assumed it was because we were fast. That’s not the right frame. We were fast because we were precise first.
The spec is where you resolve the “but what happens when…?” questions before they cost anything.
Not because the document is inherently valuable — because the conversation that produces it forces everyone to confront what would otherwise hide in the gaps between assumptionsWhen the scope is fully defined before a line of code is written, there is nothing to iterate on. Speed is the side effect of precision.
“The developer steers the AI agent to author and review code. The developer’s still very much in the driver’s seat, but it’s a different workflow.” Research cited during the launch shows that addressing issues during the planning phase costs 5 to 7 times less than resolving them during active development.
Five to seven times. That’s not a marginal efficiency gain. That’s a different economic model.
Why the Industry Just Caught Up
to Where We Were in 2022
Here is the timeline as it actually happened.
Tiran and Janaka build their spec-first model and spec2web around a specific insight: the spec has to be the source of truth. HTML is the output, not the thing you maintain. The 40-person studio closes on purpose.
Launches Spec Kit as an open-source methodology, publicly naming spec-driven development as the antidote to vibe coding.
Launches Kiro, an entire IDE built around spec-first workflows, presented at re:Invent as the future of production-grade AI development.
Calls spec-driven development “one of the most important practices to emerge in 2025.”
Identifies AI-native software engineering — where AI is embedded into every phase of the SDLC from design through deployment — as a top strategic trend for software engineering leaders globally.
We didn’t follow this trend. We built the toolchain three years before the trend named itself.
I’m not saying this to be arrogant. I’m saying it because the pattern matters: the studios winning right now in AI-native development aren’t the ones who adopted these tools earliest. They’re the ones who understood why the tools work — and had already built their delivery model around that understanding.
What “AI-Native” Actually Means
(It’s Not What Most People Think)
There are roughly three types of organisations responding to AI in software development right now.
Same process, faster. Junior developers using Copilot to write boilerplate faster. Same sprints, same standups, same ambiguity in the requirements — just with AI-generated first drafts. Productivity gains are real but shallow. Technical debt accumulates faster than the speed gains justify.
The “we don’t need developers anymore” narrative. Mostly noise. Gartner is unambiguous: AI augments, it doesn’t replace. The 10% of a project that requires human judgement becomes more valuable when AI handles the mechanical 90%, not less.
The actual shift. The spec becomes executable. The human role moves upstream permanently: from writing code to defining the precise context that agents need to produce production-quality output. Every spec teaches you to write better specs. The toolchain compounds.
“Once the spec is solid, AI agents become interchangeable. The speedup comes from alignment, not faster typing.”
Type 3 is the only model that compounds. specshop.dev was built for Type 3. Not because it’s fashionable — because it’s the only model we believe is honest about what AI actually is, and what it actually needs.
The Question Worth Asking Your Current Studio
When you hire a development agency — or a freelancer, or a studio — in 2026, there is one question that separates the operations built for the previous model from the ones built for this one.
“Can I see the spec before you start building?”
If the answer is “we do discovery in sprint zero” or “we start with a prototype and iterate” — that’s a process designed for a world where human developers fill in the ambiguity gaps in real time.
If the answer is “yes, and your approval of the spec is the gate before any code is written” — that’s a studio that has built its model around the insight now validated by GitHub, AWS, Thoughtworks, and Gartner.
At specshop.dev, the spec is not a deliverable. It’s the product. The code is the output.
We figured that out in 2022. The market confirmed it in 2025.
What Comes Next
By 2030, 0% of IT work will be done by humans without AI, and 75% will be done by humans augmented with AI. The augmentation layer — the human judgement that guides AI toward correct, maintainable output — is the spec.
The studios that understand this now are building toolchains, methodologies, and delivery models around it. The studios that don’t are getting faster at building the wrong things.
We’re not interested in being faster at building the wrong things.
Frequently Asked Questions
What is spec-first development?
Spec-first development is a software methodology in which a complete product specification — covering user journeys, architecture, data model, permissions, and edge cases — is written and approved before a single line of production code is written. The specification acts as a contract between the client and the development team, guiding AI agents and human engineers through the build phase with no ambiguity. The result: projects that ship faster, cost less to rework, and match what clients actually needed.
Why does spec-first development work better with AI?
AI agents produce code as good as the instructions they receive. A vague prompt produces vague code. A precise specification produces precise code. When developers write code manually, bad requirements create visible friction — you notice them and stop to clarify. When an AI agent writes code, bad requirements generate confident, production-quality-looking output that doesn’t do what you need. A spec removes ambiguity before the AI starts, making AI genuinely faster rather than just faster at building the wrong thing.
What is the difference between vibe coding and spec-first development?
Vibe coding is AI-assisted development where developers iterate rapidly through prompts without formal upfront specification. Spec-first development is the opposite: every user journey, data model, and edge case is documented and client-approved before AI agents begin building. Vibe coding optimises for speed of initial output. Spec-first optimises for total project cost, alignment with business outcomes, and zero scope surprises mid-build.
What should I see and approve before a software build begins?
Before any build begins, you should see and approve a complete specification document — not a proposal, and not a timeline. A proposal describes a schedule. A specification describes a system: user journeys, data model, permissions model, integrations, and edge cases. Only a specification protects your budget when scope conversations arise in week six. If your development partner can’t show you this before building, they’re skipping the step that determines whether the project succeeds.
How did GitHub, AWS, and Thoughtworks validate spec-first development?
GitHub launched Spec Kit in Q3 2025 — an open-source methodology that explicitly named spec-driven development as the antidote to vibe coding. AWS launched Kiro at re:Invent 2025, an entire IDE built around spec-first workflows. Thoughtworks called it “one of the most important practices to emerge in 2025.” Gartner identified AI-native software engineering as a top strategic trend for 2025. We built for this in 2022 — three years before the industry named it.
If you’re building a web product and you want to understand what spec-driven development looks like in practice — before you commit to a line of code — start here.
The spec is free to discuss. The build follows from it.