THE ILLUSION OF VELOCITY
The pattern is always the same. You type a vague idea. The AI builds a skeleton. Buttons, pages, and routes appear. Data models materialize. Everything looks functional on the surface, and the thought arrives almost involuntarily: This is amazing. We can move so fast.
Then you try to integrate it into real work.
That is the moment the illusion breaks. Real work is not a greenfield demo. Real work has a codebase with history, conventions, and constraints. So you start asking the AI for the things that actually matter:
- Respect our conventions.
- Fit it into our architecture.
- Align with our real data models.
- Follow our constraints.
- Add a small rule here.
- Change a behavior there.
And then — chaos.
HOW IT BREAKS DOWN
The magic quietly falls apart the moment context matters. The model stops understanding what you actually want, and the symptoms compound:
- It misinterprets requirements.
- It invents logic you never asked for.
- It creates hidden assumptions you only discover later.
- It breaks existing behavior.
- It ignores naming conventions and types.
- It hard-codes temporary hacks everywhere.
The clearest tell is the diff. You ask for a change that should touch three files, and you get two thousand lines across thirty. At that point most of us reach the same conclusion, the one every developer arrives at eventually:
"Nah. I can do it better myself."
That instinct is understandable. But it is also a signal that we have been asking the wrong question. The problem was never that the AI writes too little code. The problem is that we hand it too little definition.
THE MISSING PIECE
Before an AI can generate reliable features, it needs the same things a human engineer needs before they can do good work:
- Exact rules and precise constraints.
- Clear flows.
- Explicit inputs and outputs.
- Defined error cases.
- A shared language across teams.
We don't need more code. We need better definitions. This is where Spec-Driven Development comes in.
WHAT SPEC-DRIVEN DEVELOPMENT ACTUALLY IS
Spec-Driven Development (SDD) is a workflow that centers the entire product lifecycle around a single source of truth: the specification.
The spec defines exactly how a feature behaves — inputs, outputs, validations, error shapes, persistence rules, and business constraints. Everything else flows from it: UI, services, tests, mocks, documentation, and maintenance. Instead of treating the prompt as a throwaway instruction, SDD treats the definition of the work as the most durable artifact in the process.
In practice, SDD moves through four phases, sitting on a foundation that never changes:
1. Specify — define exactly how the feature behaves.
2. Plan — map the spec onto architecture and approach.
3. Tasks — break the plan into discrete, ordered work.
4. Implement — execute task-by-task against the spec.
Underneath all four sits a constitution — the shared rules, standards, and governance that the agent is never allowed to violate. These are the constants: the conventions, the architectural boundaries, the things that make our code ours. The phases change with every feature; the constitution does not.
BUILDING SDD INTO OUR WORKFLOW
At Lusha R&D, we packaged this workflow into a single skill that our agents run end-to-end. It takes a ticket and returns a production-ready pull request — without leaving our engineering standards behind.
The pipeline runs like this:
1. Read the ticket. It pulls the task, scope, and acceptance criteria from our issue tracker.
2. Read the spec and design. It reads the specification and the visual design from Figma.
3. Gather context. It maps the codebase, its conventions, and existing patterns.
4. Ask clarifying questions. Crucially, it resolves ambiguity before writing any code, rather than guessing and producing the two-thousand-line diff.
5. Build a plan. It produces a reviewable plan, broken into ordered tasks.
6. Execute task-by-task. It implements against the plan while holding to our code standards and design system.
7. Run dual QA agents. Functional and visual QA sub-agents verify the work.
8. Review and iterate. When a gate fails, the findings flow back into execution — the agent fixes the issues and re-runs QA, looping until both gates pass.
9. Open a pull request. Only once the work has cleared review does the result become a reviewed, production-ready PR.
The step that changes everything is the fourth one. An agent that asks before it builds is an agent that has understood the constraints — which is exactly what was missing in the chaos described earlier. The step that guarantees the outcome is the eighth: nothing reaches a human until it has survived its own review cycle.
QUALITY GATES THAT AREN'T OPTIONAL
Two sub-agents act as built-in quality gates before any code reaches a human reviewer.
Functional QA runs the feature and checks behavior against the spec: inputs, outputs, and validations; error cases and edge conditions; and whether existing behavior still works. It is looking for regressions the way a careful engineer would.
Visual QA compares the resulting UI against the design system and the Figma source: layout, spacing, and type fidelity; correct use of design-system components and tokens; and pixel alignment to the design.
Critically, these gates are not a pass/fail stamp at the end of the line — they form a review cycle. When either agent finds a problem, the result is not a failed build but a new set of tasks. The findings are fed back into execution, the agent corrects the work, and QA runs again. The loop repeats until both functional and visual checks pass cleanly. By the time a pull request opens, the code has already been reviewed and revised — not once, but as many times as it took.
Because these checks are part of the pipeline rather than a manual afterthought, validation happens every time — not only when someone remembers to do it.
WHAT WE GAIN
Working this way changes how we ship, and the gains stack on top of each other:
- Faster delivery. Features ship in a fraction of the time.
- Parallel projects. We can run several initiatives at once without losing context.
- Conventions enforced. Code standards and styling are required, not optional.
- Higher code quality. The process catches edge cases and risks we would easily miss.
- Validated by default. Functionality and design are verified on every change.
- Easier onboarding. New developers ramp up quickly, and engineers of any background can confidently ship code.
The deeper shift is one of mindset. The instinct to take the keyboard back — I can do it better myself — fades, not because the AI suddenly got smarter, but because we finally gave it the definitions it needed. Vibe coding got us to the demo. Spec-Driven Development is what gets us to production.
