Part 4 of our series on intent-driven development. Start with Part 1, or read Parts 2 and 3 first if you want the technical workflow before the outcomes.
The first three posts in this series covered the mechanics: why the spec is now the source of truth, how to build the CLAUDE.md context layer, and how OpenSpec moves a feature from proposal to deployed code without manual implementation. This post covers what those mechanics actually produce — the delivery changes we observed on the client project when the spec-first approach ran end to end.
The honest version: this is not a theoretical argument. These are patterns from a real backend integration engagement. The backend layer is the right place to evaluate this, because it's where the cost of poor specification is highest — integration work connects front-end applications to enterprise systems, and every ambiguity in that connection eventually becomes a support ticket, a rework cycle, or a missed sprint.
The Problem That Preceded All of This
Before any framework or tooling decision, there was a recurring friction pattern that we kept running into across backend delivery work.
Requirements arrived in fragments. A screenshot here, a meeting note there, a Slack thread from three weeks ago that someone had to go find. Engineers spent time reconstructing intent before writing anything. By the time code reached review, the original requirement had often drifted — decisions made mid-sprint weren't documented, and the next sprint inherited the ambiguity.
Distributed team members spent more time clarifying scope than building. The silent tax was rework: features rebuilt not because the code was wrong, but because the understanding was. The team was working hard and still delivering less than the pace of effort should have produced.
This was not a code problem. It was a specification problem. And the fix wasn't a better IDE or a smarter AI prompt — it was a disciplined approach to capturing intent before implementation ran.
What the Spec-First Shift Changed
When specifications become the artifact — reviewed, version-controlled, and agreed on before a line of implementation runs — three things change immediately.
Disagreements surface earlier. On the client project, engineering, product, and stakeholders argued about the spec, not the pull request. That's the right place to argue. A disagreement at the spec stage costs an hour. The same disagreement at the PR stage costs a sprint.
Onboarding gets faster. A new engineer joining the project reads the spec history and understands not just what the system does, but why it does it that way — the decisions, the tradeoffs, the things that were explicitly ruled out. That context normally lives in people's heads. Spec-first moves it into a document that survives team changes.
AI becomes genuinely useful. This is the one that changes the economics. A spec is the input that lets an AI assistant produce reliable engineering output. Without it, the AI produces plausible code that may or may not match what the project actually needs. With it, the AI executes against a precise brief that the team has already approved. The combination of spec and AI is meaningfully more accurate and faster than either operating alone.
The AI DLC Framework
The broader context for how we approached this is what we call the AI DLC — AI Development Lifecycle. It's our framework for using AI as a structured engineering partner across the full arc of software delivery, not as a code completion shortcut at one point in the process.
The framework rests on four principles: AI is fed structure, not open-ended prompts; humans validate every meaningful proposal before it merges; governance is built into the workflow, not added afterward; and AI accelerates the mechanical work so engineers can focus on the parts that require judgment.
The result isn't AI-written code. It's AI-accelerated engineering, with the same accountability and quality bar as before. OpenSpec is the tool that operationalises this framework — it provides the structure that makes the AI's contribution reliable.
What It Produced on the client Project
The backend integration layer was the proving ground. Here's what running the full spec-first, AI-assisted workflow actually unlocked.
API endpoint scaffolding. New endpoints were generated from specifications, including request validation, response shaping, and error handling — consistently structured every time. The spec defined the behavior, the inputs, the outputs, and the constraints. The AI proposed the implementation. Engineers reviewed and approved. No endpoint was built on an interpretation of a verbal requirement.
Enterprise system integration. Calls into upstream systems were planned, parameterised, and documented before code was written. The back-and-forth that integration work usually requires — clarifying what the downstream system expects, what error states it returns, what the team agreed to do when data isn't available — happened at the spec stage, not mid-implementation.
Test generation from specs. Specifications doubled as test plans. The AI proposed test cases directly from the spec, which engineers refined into a suite. Because the acceptance criteria were written into the spec at the start, testing wasn't a separate effort that happened after delivery — it was embedded in the same document the code was built from.
Debugging with traceability. When issues surfaced, the AI cross-referenced live behaviour against the original specification and identified the divergence. What would normally take hours of investigation often resolved in minutes, because the spec provided a precise reference point for what the system was supposed to do.
Compliance and security consistency. Sensitive data handling, access scoping, and validation rules were encoded in the spec once and applied consistently across every endpoint that required them. Standards weren't enforced by convention or code review habit — they were written into the specification that every implementation was built from.
The Delivery Outcomes
Across the client engagement, the spec-first approach produced observable changes in how work moved through the team.
Implementation cycles shortened. Features that would have previously taken a full sprint moved in days, because the distance between approved spec and deployable code collapsed when the AI was executing against a precise brief rather than interpreting an ambiguous one.
Rework dropped. When agreement happened at the specification stage, fewer features came back for a second pass. The cost of misunderstanding moved from the end of the delivery cycle — where fixing it is expensive — to the beginning, where fixing it is cheap.
Sprint predictability improved. Spec-first planning gave engineering leads a clearer view of what would actually ship and when. The unknowns that normally materialise mid-sprint — edge cases, integration gaps, scope that was assumed but not agreed — were surfaced during spec review instead.
Quality became consistent. Every endpoint and integration looked like it was built by the same team against the same standards — because it was. The spec provided the standard, the AI applied it, and the engineer validated it.
What Didn't Work at First
Honest accounting includes the things that require adjustment.
Using AI without spec context produced fast but unreliable output. The speed was real — but so was the cost of fixing what the AI got wrong when it was working from an open-ended prompt rather than a structured brief. Every shortcut taken by skipping the spec came back as rework.
Specifications that became checklists stopped being useful. A spec should describe intent — what the feature needs to accomplish, what constraints it operates under, what done looks like. When specs drifted into enumerating implementation steps, they stopped capturing intent and started just duplicating what the code would eventually say. Short, outcome-oriented specs outperformed long, procedural ones.
Skipping the human review step in the name of speed always backfired. The review checkpoint between spec generation and implementation is not overhead — it's the mechanism that keeps the AI's interpretation aligned with the team's actual intent. Every time it was bypassed, the result was a correction cycle that cost more time than the review would have.
The Compounding Effect
The most significant outcome from the client project wasn't any single delivery improvement. It was the compounding effect of running the same disciplined process across every feature.
Each feature added to the spec history. Each spec became the context for the next one. The AI's output improved as the project's specification library grew, because the brief it was working from became richer and more precise over time. Engineers onboarded faster on later phases because the decisions and tradeoffs from earlier phases were documented. The team spent more of its time in flow and less in clarification.
This is the structural advantage of spec-first development: it improves with use. The investment in writing good specifications on the first feature pays dividends on every feature that follows. The teams that adopt it earliest will compound the advantage fastest.
The Bigger Shift
For decades, the principle in software engineering has been that code is the source of truth. The running implementation is the ultimate record of what a system does.
When AI can generate, refactor, and rewrite code from high-level instructions, that principle inverts. Code becomes the output — the thing that falls out of a specification, rather than the thing that defines the system. The specification is what persists: the human intent, captured in a form that both engineers and AI can act on.
The teams that recognise this shift early — and build their workflows around it — will deliver more, rework less, and maintain systems that stay comprehensible as they grow.
The client project was one proof point. The framework is repeatable.
This is the fourth post in our series on intent-driven AI development. Start from the beginning →


























































