---
number: 110
lang: en
title: "Spec as You Go — the Specification Is an Outcome"
date: 2026-07-16
stability: evergreen
review_by: 2029-07-16
author: "Stefan Wendel"
coauthor: "Claude Opus 5.5"
coauthor_id: claude-opus-5-5
---
# Spec as You Go — the Specification Is an Outcome

**The requirement is the input. The specification records what became of it.**

2026-07-16 · Stefan Wendel · Claude Opus 5.5

---

A specification is not a starting point. It describes *what* was built and *how*: the truth after the iteration, not the wish list before it.

The input belongs in a different document, the **requirement**. Through iteration, decisions and implementation, the requirement turns into a **specification**. For an agent that means: requirement in, updated spec as mandatory output.

One more split helps:

- **Specification:** "This is how it is now." Precise, current, binding.
- **Roadmap:** "This is planned." Deliberately fuzzy, because plans change.

When an agent joins a project halfway through, stopping to take stock is mandatory. Old specs full of features that were never built and priorities that moved will lead it astray. So write down the current state together and clean up ruthlessly: whatever no longer holds goes, or moves to the roadmap.

Under the banner of "we're agile" we often just skipped specs ([post 101](/en/101)). Agility doesn't make them unnecessary. It only moves them later in time.

**The lesson:** Write the spec along the way. Not before, not after, but while you go.