What "spec-driven" means here
Spec-driven development, in this guide, is not a branded playbook you must install. It means writing a clear, checkable specification that humans and AI tools share as the target—before and during implementation—so "done" is not a vibe and not a prompt chat history.
A useful spec answers: what must be true when this change lands, how we will know, and what constraints must not be violated. It can live in a ticket, a design note, a test harness, or a short interface contract. The form matters less than whether someone (or something) can check it.
A2X uses this approach when it already fits the team. When the team prefers another process, the method is built around that preference instead. You do not have to adopt a named SDD product to work this way. For the broader claim—why verification, not prompting, is the bottleneck—see Why AI made your developers faster but not your team.
Why algorithm, CV, and embedded teams need checkable specs more
Generic web CRUD often fails loudly: a broken page, a red integration test, an obvious auth miss. Algorithmic code, computer vision, and embedded software fail more quietly.
The oracle is hard. Correctness may be a tolerance band, a distribution on a golden set, bit-exact equivalence to a MATLAB prototype, or behavior under timing and power limits. An AI assistant can produce plausible code that still misses the regime that matters.
The feedback loop is long. Simulation, dataset evaluation, and hardware-in-the-loop do not keep pace with chat. Without a checkable target up front, you multiply drafts into a scarce lab queue.
Context is implicit. Numerical libraries, fixed-point rules, memory budgets, MISRA-ish habits, sensor quirks—teams carry these in heads and tribal review. A model does not. Specs that surface those constraints reduce confident wrong merges.
Review alone does not scale. When AI raises change volume, asking seniors to reconstruct intent from a large diff is the expensive path. Intent written once, checkably, is cheaper than rediscovering it in every PR.
This is the deep-tech version of the productivity paradox: individuals draft faster; the team still waits on proving the work.
Specs that survive AI
A ticket that says "improve the tracker" or "optimize the filter" is not a shared target. Under AI, it becomes fluent code aimed at the wrong thing. Specs that survive look more like this:
Acceptance criteria in checkable language. Not "works better," but "on dataset D, false-positive rate ≤ X at recall ≥ Y" or "latency p95 under Z ms on board B."
Golden outputs and equivalence. For ports and refactors: reference outputs, checksums, or numerical equivalence tests with an explicit tolerance. AI is good at translation; equivalence is how you know the translation preserved meaning.
Tolerances and properties. Property checks and invariants ("output stays in [0,1]", "covariance stays positive semi-definite", "no allocation on the hot path") catch classes of failure unit examples miss.
Hardware and resource constraints. Memory ceiling, flash budget, ISR timing, power mode, peripheral ownership. If it is not in the spec, the model will invent a convenient assumption.
Risk and review tier. What can auto-merge on green tests versus what needs a human who owns the algorithm or the device. Specs should say which lane the change is in.
The point is not ceremony. The point is a target that both the engineer and the assistant can aim at—and that CI or the bench can falsify.
Fit SDD to the process you have
Deep-tech teams already have rituals: design reviews, MATLAB-to-C++ handoffs, board bring-up checklists, dataset ownership, DO-178-ish or defense review cultures. Spec-driven work should sit inside those, not replace them with a slide deck from another industry.
Start where intent is already written. If you have ICD documents, algorithm design notes, or test plans, make them the backbone and tighten what is checkable.
Prefer small upgrades over a rebrand. Add golden-output gates to an existing PR template. Put tolerances in the ticket template. Encode one hardware constraint as a CI check. Persistence beats a new methodology name.
Do not impose a foreign playbook. If the team rejects "SDD" as a label but already writes acceptance tests before merge, keep their language. A2X bends the method to the stack; it does not ask the stack to bend to a package. More on that fit is on the home page.
Human side and systems side
A spec that only lives in a wiki page will fade. A method that lasts has both sides.
Human side. Habits for writing the checkable part before a large AI-assisted draft; review that asks "does this meet the spec?" before "does this look clean?"; ownership of golden datasets and benches so oracles stay honest.
Systems side. Automation where it belongs: running equivalence tests, property checks, static limits, and policy gates before human review. Autonomy can draft against the spec; humans still own judgment on architecture, safety, and whether the spec itself was right.
When AI is in the loop every day, the systems side is what keeps verification from depending on heroics. The human side is what keeps the specs from rotting into vague tickets again.
Common failure modes
Vague tickets plus AI. The model fills in missing intent with something that compiles and looks idiomatic. Reviewers spend hours reconstructing what was meant. Fix the ticket shape before you scale the assistant.
Specs that are not testable. Beautiful prose that no test, dataset, or bench can falsify. If you cannot say how you would know it failed, it is not yet a verification asset.
Specs that ignore hardware. Software-only acceptance on an embedded change. Green unit tests, red device. Put the constraint in the target.
Acceptance rate as the success metric. Teams celebrate how much AI code was accepted while rework and review queues grow. Measure delivery and quality outcomes, not suggestion counts. The flagship guide covers that measurement trap in more depth: Why AI made your developers faster but not your team.
Imposing a toolkit before the oracle exists. Buying another review bot without golden outputs or tolerances for the algorithms that matter. Tools amplify a method; they do not replace a missing check.
Talk it through
If your team already uses AI coding tools and still feels stuck on verification—especially on algorithmic, vision, or embedded work—the useful conversation is about method, not another prompt workshop.
Book a call and we will talk through how you specify and prove work today, where AI helps, and whether an A2X engagement fits. Work starts with a short diagnostic as phase one of the engagement, then implementation with the team. No hard sell here; fit first.