Agentic & Spec-Driven Development

Beyond the per-role tools in the AI Tooling Map, EmeSoft has adopted two techniques that change how we build software in 2026: AI coding agents and spec-driven development (SDD). Together they move us from ad-hoc prompting toward a disciplined flow where an executable specification drives autonomous agents - with humans owning the spec and the review.

flowchart LR
    OLD["Prompt-by-prompt<br/>(requirements live in chat)"] -->|fragile, unrepeatable| RISK[Drift & rework]
    NEW["Spec-driven + agentic<br/>(spec is the source of truth)"] -->|reviewable, repeatable| GOOD[Predictable delivery]
    classDef bad fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    classDef ok fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class OLD,RISK bad;
    class NEW,GOOD ok;

Part 1 - AI coding agents

An AI coding agent does more than autocomplete: it can plan a change, run terminal commands, edit across many files, run tests, and iterate toward a goal - while the developer supervises and approves. This is the most significant shift in day-to-day engineering, building on the Developer role’s pair-programming practice.

Agents we use

Agent	Form factor	Where it fits
Claude Code	Terminal / IDE agent	Deep reasoning on complex, multi-file changes and refactors; our default for non-trivial work.
OpenAI Codex	CLI / cloud agent	Strong terminal-task execution; well-scoped autonomous tickets.
GitHub Copilot	IDE + coding agent	In-editor pairing and PR-level agent tasks where work already lives in GitHub.
Cursor / IDE agents	Agentic IDE	Developers who prefer an integrated editor with agent mode.

Levels of autonomy

We use agents at the level of autonomy the task and risk justify - and never beyond what a human can review:

flowchart TB
    L1["L1 · Assist<br/>autocomplete, explain"] --> L2["L2 · Pair<br/>agent edits, dev approves each step"]
    L2 --> L3["L3 · Delegate (scoped)<br/>agent completes a well-defined ticket, dev reviews PR"]
    L3 --> L4["L4 · Background<br/>async agent runs a spec'd task, opens a PR for review"]

The higher the autonomy, the more important the spec and the review gate - which is exactly what spec-driven development provides.

Part 2 - Spec-driven development (SDD)

The weakness of agentic coding is that when requirements live only in chat history, output is unpredictable and unreviewable. Spec-driven development fixes this by making a written, versioned specification the source of truth. The agent implements from the spec; if you want to change direction, you change the spec and regenerate - not re-prompt from memory.

SDD targets the translation loss that creeps in as an idea moves from stakeholder need → requirements → architecture → implementation → validation. Without a shared artifact that preserves intent, every handoff becomes a fresh interpretation step - and AI can accelerate those steps but cannot correct ambiguity that was never resolved. A spec that travels with the work keeps all four handoffs anchored to the same intent: teams align first, then let AI accelerate execution.

Our primary tool: GitHub Spec Kit

We standardize on GitHub Spec Kit - an open-source toolkit created by Microsoft that turns spec-driven development into a repeatable workflow for AI coding agents such as GitHub Copilot. Rather than prompting first and aligning later, the team aligns first: a structured spec becomes the shared source of truth for humans and AI, and the agent executes against it.

Spec Kit structures work into a seven-step engineering lifecycle - define intent, remove ambiguity, plan with constraints, implement with AI, and validate against the spec. Each step produces a reviewable, version-controlled artifact that feeds the next:

flowchart LR
    C["Constitution<br/>principles & guardrails"]
    S["Specify<br/>requirements & acceptance criteria"]
    CL["Clarify<br/>resolve ambiguity & edge cases"]
    P["Plan<br/>architecture, flows & constraints"]
    T["Tasks<br/>implementation-ready units"]
    I["Implement<br/>agent builds & refines"]
    V["Validate<br/>output matches the spec"]
    C --> S --> CL --> P --> T --> I --> V
    V -->|change of direction| S
    classDef a fill:#eef6ff,stroke:#3b82f6,color:#1e3a8a
    class C,S,CL,P,T,I,V a

Constitution → Specify → Clarify → Plan → Tasks → Implement → Validate. Each step reinforces the next, which makes the workflow predictable and easier to scale across teams.
Clarify exists specifically to resolve ambiguity, dependencies, and edge cases before any code is generated - clarity early reduces total delivery time.
Spec Kit is agent-agnostic (Copilot, Claude Code, Gemini CLI and many others), so it layers on top of whichever agent a developer uses.
Right-size adoption. Not every change needs the full lifecycle - a small fix can skip ahead, while greenfield or complex multi-service work benefits from running the whole flow.

Alternative: OpenSpec

For change management on existing codebases, we also use OpenSpec - a lightweight, tool-agnostic SDD framework. Its flow is Propose → Apply → Archive: the agent produces a proposal, specs, design, and tasks; implements step by step against the task checklist; then archives the completed change as a record. It keeps scope explicit and auditable without the overhead of a full planning framework.

Choosing between them

	GitHub Spec Kit	OpenSpec
Flow	Constitution → Specify → Clarify → Plan → Tasks → Implement → Validate	Propose → Apply → Archive
Best for	Greenfield / new features	Changes to existing codebases
Style	Fuller planning workflow	Lightweight, change-scoped
Artifacts	Spec, plan, tasks (Markdown)	Proposal, specs, design, tasks (in-repo)
Agent support	30+ agents	20+ assistants via slash commands

Part 3 - How this fits the EmeSoft process

Spec-driven, agentic development does not replace our Scrum process - it strengthens it by making the specification an executable artifact that flows through the existing roles:

flowchart LR
    BA["BA + Stakeholders<br/>author the spec<br/>(/specify)"] --> SA["Architect/Dev Lead<br/>reviews plan<br/>(/plan)"]
    SA --> DEV["Developer + agent<br/>implement tasks<br/>(/tasks, /implement)"]
    DEV --> QE["Quality Engineer<br/>verifies vs spec<br/>& acceptance criteria"]
    QE --> BA

The Business Analyst and stakeholders shape the spec - it becomes the home of the acceptance criteria and a natural traceability record.
The Architect/Dev Lead reviews the plan and task breakdown before implementation.
The Developer runs the coding agent against the tasks, reviewing each change.
The Quality Engineer validates the increment against the same spec - the spec is the single reference for “did we build the right thing.”

This keeps the governance rules intact: AI drafts and implements, a human reviews, decides, and owns the merge.

Honest caveats

These techniques are powerful but not magic - see Where AI & Humans Still Struggle for the limits. In short: agents degrade on large messy legacy code, can confidently produce wrong-but-plausible output, and shift effort toward review. SDD adds upfront discipline that pays off on substantial work but can feel heavy for trivial fixes. Match the technique to the task.