Campus AI Development Spec-driven development

The continuum Band 04

04

Spec-driven development

The spec is the source of truth. Code, tests and docs are derived from it.

Also called: Spec-first development

01Definition

The main artifact is a written, versioned specification: purpose and scope, data model, acceptance criteria and interface contracts. AI generates and regenerates code from the spec, and the work is checked against the spec rather than read line by line. Developers can work this way, and so can domain experts with IT support.

02Origins

The idea draws on older practices: model-driven engineering, design by contract, and behavior-driven development’s Given/When/Then scenarios. What changed with AI is that code became cheap to regenerate from a written spec.

Tools formalized it in 2025: AWS’s Kiro in July, and GitHub’s open-source Spec Kit on September 2, which moves work through specification, plan, tasks and implementation. Practitioners distinguish degrees, from “spec-first” (write a spec, then code) to “spec-as-source” (only the spec is edited by people).

03How it works

Person AI
01Write the spec
02Draft a plan
03Review the plan
04Implement tasks
05Test against criteria
06Change the spec first

Each change returns to step 1: the spec changes first, then the code.

  1. 01Write the spec: purpose, scope and non-goals, users, data model, acceptance criteria.
  2. 02The AI drafts a technical plan; a person reviews it.
  3. 03The plan is broken into small, testable tasks.
  4. 04The agent implements each task; tests come from the acceptance criteria.
  5. 05Changes go into the spec first, and code is regenerated or updated to match.

Typical tools: GitHub Spec Kit (specify → plan → tasks → implement → converge); AWS Kiro, which often uses the structured EARS requirements format; BMAD Method, with agile-style agent roles for larger projects; OpenSpec; or plain Markdown specs in the repository with any coding agent.

04Profile across the dimensions

How the work is done

Human role
Writes and owns the spec
Unit of work
A spec change
Source of truth
The spec
Agent autonomy
Acts within the spec
Lifecycle coverage
Design and requirements first; build and test follow

How you know it’s right

Code read by a person
Checked against the spec, not line by line
Verification
Acceptance criteria, executable specs
Traceability
Each requirement linked to its code
Delivery automation needed
Automated checks against the spec; deployment pipeline

Fit and risk

Upfront investment
High
Durability
Long-lived
Data and risk ceiling
Institutional data with IT support

Compare all five bands

05Lifecycle coverage

Plan
Design
Build
Test
Deploy
Operate

Solid: AI does core work · Hatched: partial or informal · Dashed: done by people. Compare all bands

06When to use it

Good for: Anything others will rely on or that must be maintained

One personUseful but can feel heavy. The spec mainly serves your future self and whoever inherits the tool.
A teamWhere it pays off most: the spec is the shared agreement that lets people and agents work in parallel without drifting. At Emerson, individual builders share one environment, so a second person can pick up any project.
How much spec a task needs
No spec (vibe coding)Under a day, one or two files, low stakes, solo throwaway work.
Lightweight specTwo or more days, several files, a handoff to a person or agent, tests that map to requirements.
Full specMulti-week features, public interfaces or data contracts, compliance, several agents or team members, design review before building.

The two common errors are a full spec for a task that needs a light one, and no spec for a task that needs at least a light one. To avoid “waterfall with markdown”: keep specs to about one screen, slice tasks to one session and one reviewable diff, start building against the first task early, update the spec when reality diverges, and map every acceptance criterion to a test. Adapted from Sarigoz, 2026.

Less suited to

  • Exploratory work, where you don’t yet know what you want
  • One-off scripts and throwaway prototypes

Signs you’ve outgrown it

  • Several teams or many agents work in parallel
  • Compliance audits need evidence for every change
  • Deployment and operations need automated policy checks

07Development environment

Where it runs: An agentic setup plus the spec in the repository and a spec tool (Spec Kit, Kiro).

Shared platform
A standard template with sign-on, logging, secrets storage and separate development and production
Automated checks
Tests derived from acceptance criteria, run on every change
Data
A development copy of institutional data, not production
On campus
Emerson’s shared environment is the model: it let domain experts build safely

Compare environments across bands

08Minimum controls

  • A short written spec: requirements, acceptance criteria, non-goals
  • Traceability from spec to tests to code
  • Security, accessibility and equity review before merge
  • A named owner, separate production and audit logs

Risks

  • Spec drift: code changes that never make it back into the spec.
  • False confidence: passing the spec doesn’t help if the spec itself is wrong.
  • Unread code: insecure defaults can hide behind passing tests. At Emerson, builders had to insist on encrypted credential storage.
  • Upfront cost: writing a good spec takes domain expertise and time.

09On campus

10Sources

  1. Delimarsky, “Spec-driven development with AI,” GitHub Blog, Sept. 2, 2025
  2. GitHub Spec Kit, “spec-driven.md”
  3. Böckeler, “Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl,” martinfowler.com, 2025
  4. Basgen & Frain, “Vibe Coding in Production,” EDUCAUSE Review, Sept. 2026
  5. Sarigoz, “Vibe coding vs spec-driven dev: a per-task decision guide,” BizStack, Sept. 11, 2026
  6. Augment Code, “Vibe Coding vs Spec-Driven Development (2026): When to Use Each,” Mar. 2026
  7. 10xTeam, “AI Dev Methodologies: From Vibe Coding to the Contracts Pattern,” May 2026
  8. BMAD-METHOD