H
Howardism
Plate IIAI Coding PracticeHOWARDISM

Is Persistence the Line Between Prompting and Spec-Driven Development?

No — persistence is an observable proxy for the property that actually matters, which is authority: whether later work is judged against the artifact. The corpus breaks the persistence test in both directions (CLAUDE.md, WORKFLOW.md, REVIEW.md, tickets and Martin's own dependency-rule file are persistent and nobody calls them specs; the grilling transcript, Carey's why-conversation and Martin's deleted plans are ephemeral and do the whole specification job), and both cited positions turn out to be misread — Pocock's sentence contains two clauses, persist *and return to*, and only the second survives; Martin does keep a specification file in the repo, scoped to constraints a checker enforces. Authority classifies every corpus case correctly; persistence is what makes authority cheap. Cluster is almost entirely practitioner-opinion, and nothing measures persistence-per-se

Article metadata
Publication details
Published:September 2, 2026
Filed:Essay
Domain:AI Coding Practice
Tags:DerivedAI Coding WorkflowPlanningDefinitions
Reading:18 min
Source:AI-synthesised
About this piece

Articles in this journal are synthesised by AI agents from a curated wiki and are refreshed automatically as new concepts arrive. Topics, framing, and editorial direction are curated by Howardism.

Illustration for Is Persistence the Line Between Prompting and Spec-Driven Development?

Sources#

The question#

From Spec-Driven Development as the New Waterfall: is persistence the right definitional line between prompting and spec-driven development, as Pocock proposes and Martin's practice assumes?

Verdict#

No. Persistence is a proxy — cheap to observe, correlated with the thing that matters, and wrong at the edges in both directions. The property the corpus actually uses to separate a spec from a prompt is authority: an artifact is a spec when later work is judged against it. Persistence matters only because storing an artifact is the cheapest way to make judging-against-it possible.

Three findings support this, and the first two are corrections to the question's own premises:

  1. Pocock's proposal has two clauses and only the second survives. He asks "are you persisting your specifications, right? are you returning to those specifications?" (Full Walkthrough: Workflow for AI Coding — Matt Pocock). Return is the operative clause, persistence is the enabling one, and his own reason for deleting PRDs — doc rot, an agent finding a stale document and being misled by it — is a harm that requires reading back, not merely storing.
  2. Martin's practice does not assume the persistence line. He does keep a specification file in the repo. What he refuses to keep is a plan.
  3. The corpus classifies persistent artifacts as specs or non-specs on a different variable, and it already has a name for it — the policy / work-graph / enforcement split in Agent Control Plane Patterns: Tickets, Loops, Specs, and Memory Files and Agent Context Files.

Correction 1: Pocock's line is persist and return#

The exchange is worth reading as posed, because the wiki page compresses it. Pocock's frustration is with the label, not the practice — "you can have like 10 different interpretations of it and every time you pass information to an agent… Is prompt engineering spec-driven development? Like it kind of is" — and he reaches for persistence as a way to stop the term from swallowing everything. But the sentence he actually produces is a conjunction, and the two conjuncts are not the same test.

His own workflow separates them. He generates exactly two documents after a grilling session — a PRD (destination) and a Kanban (journey) — and then, per Design Concept Grilling, neither deletes nor keeps the PRD in the ordinary sense: he closes the GitHub issue. In his words: "I just mark it as closed. It can fetch it if it wants to, but it's got a visual indicator that it's done." The artifact persists; its authority is revoked. That is not a persistence rule, it is a return rule with a persistence-preserving implementation — and it is the practice the doc-rot argument actually licenses, since a stale document harms only when something reads it back as current.

Two further details from the same source make persistence a poor fit for his own view. He declines to optimise the PRD at all ("I don't think there's a lot of value in that… the thing that really matters is getting alignment with the AI, which is you do in the grilling session") — so the durable document is the low-value artifact and the ephemeral conversation is the high-value one. And his push/pull distinction is an authority distinction, not a storage one: CLAUDE.md content is pushed to every agent unconditionally, a skill is pulled when the agent chooses; he recommends pushing coding standards to the reviewer and letting the implementer pull them. Both files are equally persistent. The design decision is entirely about which one binds.

Correction 2: Martin persists a specification file — with a checker attached#

The page reads Martin's "no, I do not… the specifications are ephemeral, they go away" as a flat refusal to persist. In the same interview, forty minutes earlier, he describes the opposite for a different artifact class:

"I've also put together another deterministic tool where I can define which module should depend on which, which one should not depend on which, how the dependency should flow. That goes into a nice tight little specification file that the agents cannot violate. There's another little checker that runs at the end and if they violate it, they've got to fix it somehow." — Uncle Bob on Software Fundamentals in the Age of AI

That file is persisted, repo-resident, read on every run, and binding — the strongest form of spec in his whole practice. So Martin's position is not specs are ephemeral; it is constraints persist and are mechanically enforced, while plans are ephemeral and enforced by nothing. His stated substitute for the persisted spec — the CRAP scorer, the mutation tester, the dependency-rule checker (Reviving Impractical Quality Tools) — is the same point made about the enforcement mechanism rather than the file: he is not deleting the durable statement of intent, he is moving it into things that fail the build.

Read this way his practice does not assume the persistence line at all. It assumes something closer to Deterministic Pre-Execution Gates' rule that the corpus states elsewhere as "the skill makes violations rare and the hook makes them close to impossible" (The Committed-Artifact Chain): advisory prose is the weak artifact, executable constraint is the strong one, and storage is incidental to both.

Test 1: persistent artifacts the corpus does not call specs#

If persistence were the line, all of the following would be spec-driven development. None of them is described that way anywhere in the corpus.

Persistent artifactWhy it fails the "spec" reading
CLAUDE.md / AGENTS.md / SOUL.md / .cursorrules (Agent Context Files)Versioned, inspectable, deterministically injected every session, dual-audience — maximal persistence and maximal return. The corpus files it as the policy plane: it governs how an agent behaves inside a work envelope, not what is being built
WORKFLOW.md (Symphony, Ticket-Driven Agent Orchestration)Repo-versioned prompt-as-policy — "work an issue, check out a repo, put it in progress, add the PR". Process, not product
SPEC.md (Symphony)Persistent and genuinely a spec — but note it specifies the orchestrator, and OpenAI compiles it into six languages to fuzz its ambiguities. Its spec-hood comes from being the thing implementations are checked against, not from sitting in a repo
The ticket graph (Ticket-Driven Agent Orchestration)The most durable and most authoritative artifact in the whole control-plane stack, and explicitly "objectives, not transitions" — it selects work, it does not specify it
REVIEW.md, hooks, lint config (The Committed-Artifact Chain, Deterministic Pre-Execution Gates)Persistent, agent-read, binding, uncontroversially not a spec
Martin's dependency-rule file (Uncle Bob on Software Fundamentals in the Age of AI)Persistent, and its author says in the same conversation that he keeps no specs

The CLAUDE.md row is the decisive one. It satisfies every clause of the persistence test — persisted, returned to, on every single session, by construction — and if that made a workflow spec-driven, then essentially every Claude Code user is doing spec-driven development and the term distinguishes nothing. That is precisely the failure Pocock was trying to avoid when he reached for the test.

Test 2: non-persistent artifacts that do the whole specification job#

The under-inclusion side is worse, because it misfiles the corpus's most specification-heavy position.

  • The grilling transcript. Design Concept Grilling is the left pole of the PRD-replacement spectrum — the position with maximal pre-build specification, 10 to 100 questions, sessions running an hour. Its output artifact is "the conversation history itself", consumed once by a write-a-PRD skill and then gone. By the persistence test the corpus's most spec-driven position is prompting.
  • Carey's recorded why-not-what conversation (Prototype Over PRD). A transcript, handed to Claude, discarded; what it produces — "the prototype is the spec" — is the durable artifact but is not a document at all. Carey specifies more precisely than a PRD, on his own argument that "two people [can] look at the same doc and have two different products in mind", with no persisted specification anywhere in the loop.
  • Martin's own deleted plans. The plans he writes govern the entire build — the agents follow them past the point a human would have stopped, which is his whole complaint. They do 100% of the specification job for the duration of the work. Only the storage differs from the plan.md in The Committed-Artifact Chain, which the corpus certainly calls spec-driven.
  • A spoken constraint. Karpathy's MenuGen fix — "these must be unique user IDs we tie everything to" (Vibe Coding vs. Agentic Engineering) — is the human residue he names as "spec" outright, and it was said, not filed.

Test 3: the reductio Pocock supplies himself#

His example against the label is "you just fix that loading issue in the header" — a one-line instruction to a colleague. Persistence answers "not a spec," which feels right. But write the identical sentence into a committed TODO.md and the same test answers "spec-driven development," with nothing about the work having changed. A definitional line that a git add can flip is tracking the filesystem, not the methodology.

The line the corpus does draw: authority#

Across every case above, the variable that separates spec from prompt is whether downstream work is evaluated against the artifact:

  • plan.md is a spec because "the PR [is] reviewed against plan.md" (The Committed-Artifact Chain).
  • Fung's checked-in spec is a spec because "Claude is very good about verifying against spec drift" — Code as Source of Truth states the check, not the storage, as the payoff of committing it.
  • Evals are the spec because "the PRD describes intent; the eval defines done", and at Shopify the rubric literally becomes the RL reward (Evals as Product Spec).
  • Martin's dependency file is a spec because a checker fails the run on violation.
  • CLAUDE.md is not a spec because nothing is checked against it — the corpus has a documented case of a correctly-targeted CLAUDE.md rule being loaded, current, and simply not followed, with no gate to catch it (Agent Context Files).
  • The ticket is not a spec because it names an objective and the work is judged against the objective's artifacts, not against the ticket text.

Code as Source of Truth already states the strong form as a rule, taken from the Anthropic playbook's legacy-migration sidebar: name exactly one system as the source of truth per artifact, and let everything else hold a copy or a link. That rule is unintelligible on a persistence reading — Jira, the repo and the markdown working copy are all persistent — and exactly right on an authority reading, since it is precisely a rule about which durable copy binds.

The alternative lines, ranked by how much corpus they explain#

Candidate lineVerdict
Authority — is later work judged against it?Best. Classifies every case in Tests 1–3 correctly, is already the corpus's own taxonomy, and is what both Pocock and Martin are reaching for underneath the persistence language
Return / re-read (Pocock's second clause)Strong, and the correct reading of his argument, since doc rot is a read-back harm. Fails only on CLAUDE.md, which is returned to maximally and is not a spec — so it needs authority to finish the job
Executability / mechanical checkabilityA sharp sub-case of authority, and the one Martin actually acts on. Cleanly separates advisory prose from enforced constraint (Deterministic Pre-Execution Gates), but under-includes: intent.md and a destination PRD bind human decisions without any checker
Source-of-truth precedenceThe formal version of authority, already written down as the per-artifact rule in Code as Source of Truth. Answers "which artifact wins when two disagree" and nothing more — a tiebreak rule, not a definition
Human review / a named accepter (The Committed-Artifact Chain)Weakest of the plausible lines, and the corpus knows why. Pocock deliberately does not review his own PRD; the chain's own compounding-corrector problem means a commit log "records that a human accepted, never that a human read" (Is Human Review of AI-Authored Code Still a Real Control, or Already Rubber-Stamping?). A line no cited practice honours
Implementation visibility (DHH, Vibe Coding vs. Agentic Engineering)A different genus of answer and worth naming: DHH draws the neighbouring vibe-coding line on the human's behaviour (do you look at the implementation?) rather than on any artifact. It is binary and observable, which is what makes it attractive for the same reason persistence is

Why persistence looks right anyway#

The honest defence, and the reason to keep it as a heuristic rather than discard it: authority is a disposition and persistence is an observable. You cannot see whether an artifact binds later work without watching the next month of work; you can see whether it is in the repo in one second. And persistence is close to necessary for authority — the corpus holds no case of an artifact governing later work without some durable form (Martin's checkers are code; Carey's prototype is committed; the grilling transcript's authority ends exactly when the conversation does). So the defensible statement is:

Persistence is the cheapest enabling condition for authority, and therefore a decent field test. It is not the definition, and it misclassifies the corpus's own poles in both directions.

One structural confirmation: the corpus's spectrum of positions (The PRD-Replacement Spectrum at AI-Native Speed) is ordered by how much specification precedes the build, and carries "durable artifact" as a fifth descriptive column rather than as the ordering key. Every position on it has some durable artifact — PRD-plus-Kanban, a one-pager, the chosen PR, the prototype, and past the right pole, Martin's checkers. If persistence were the axis, the spectrum would collapse to a single point.

Evidence tier#

This cluster is almost entirely practitioner-opinion, and the question is a definitional one that no source in the corpus was written to answer.

  • Pocock (workshop, practitioner-opinion), Martin (interview, practitioner-opinion), Carey (talk), DHH (podcast), Fung (talk) — five first-person reports, no measurement of spec form anywhere among them.
  • The Committed-Artifact Chain is vendor-claim with, by its own page's accounting, no measurement of any kind — every "how to measure it" block names an indicator to collect.
  • Planning / Execution Division of Labor is the only telemetry in the cluster (400K Claude Code sessions, ~70% of planning decisions human) and it measures the decision split, not the artifact form. It cannot adjudicate this.
  • The two nearest measured things in the vault are both about context files, not specs, and about content rather than storage: Khatri's bounded null on correctness, and NVIDIA SkillEvaluator's +41 Correctness on proprietary-knowledge skills (both on Agent Context Files, both with stated methodological limits).

So the verdict above is a conceptual result — it is derived by testing a proposed definition against the corpus's own classifications, and it is as good as those classifications are. It is not an empirical claim about outcomes, and it should not be read as one.

What would overturn this#

  • A measurement where storage-per-se moves an outcome. Hold content and read-back behaviour fixed and vary only whether the artifact is committed; if rework, defect rate or drift differ, persistence is an independent variable rather than a proxy and the verdict weakens sharply. Nothing in the corpus runs this; Khatri's ablation harness is the closest existing instrument, and the The Committed-Artifact Chain indicator set (spec.md commits dated after the first plan.md) is the closest existing metric.
  • An artifact that binds later work with no durable form at all — later work genuinely checked against something that exists only in a conversation. That would break the "persistence is near-necessary" half and demote it from proxy to coincidence.
  • A social mechanism for persistence independent of reading. If committing a spec changes behaviour because it is visible rather than because it is read — team commitment, auditor acceptance, the "auditors and regulators already accept them" pressure named in Code as Source of Truth — then storage does real work that authority does not capture. The corpus has one adjacent hint that committing a file changes the world without anyone reading it, but it is a security surface rather than a methodology argument: a committed CLAUDE.md functioning as reconnaissance for an attacker (Agent Context Files, UK AISI INC-2026-07-28-01).
  • Usage settling by fiat. If a major tool ships a "spec-driven development" mode whose literal mechanism is persistence, the term will follow the tool. That would settle the sociological question and leave the conceptual one exactly where this page leaves it.

Connections#

Sources#

§ end
Cited by 8
Related articles