A Gated Spec-Driven Workflow: An Audit-Trail Study of Coding-Agent Work
B · Useful, limited Two researchers at the Federal Institute of Brasília audit the logs of their own spec-driven Claude Code workflow with careful counts and stated threats to validity; useful practice evidence, but self-run, with no control condition.
Summary based on the full text·Original: about 35 minutes to read
In short
An arXiv preprint (dated 4 November 2026) by Rodrigo Figueiredo Abdo and Pedro Carvalho Brom on a gated spec-driven development workflow for Claude Code. Work moves through decision record, spec, plan, tasks, execution and archive, with a human approval gate at each stage, a reviewer subagent with a fixed defect list, executors limited to declared files, and a file-inventory check after each block of tasks. Across nine features, executors stayed in scope; the orchestrator, which runs and judges its own checks, was the weak point.
Key numbers
- 288 of 581planned tasks completed block by block across nine features in seven projects
- 11 of 247block checks in which the orchestrator recorded undeclared changes; it stopped work in four
- 15 of 20artefacts whose first review by the reviewer subagent reported a blocking finding
- 75.3%share of reviewer tokens used by re-reviews the workflow did not ask for (projects P1, P2, P5)
As reported by the source.
English·Web page·opens arxiv.org
What it reports
- Nine features in seven projects, from a Fortran solver and Python programs to books, a research dossier and this paper; five of the nine delivered non-software outputs.
- 581 tasks planned in 458 blocks; 288 completed. Five features finished every planned task; four reached the archive stage.
- The executor left one undeclared change in the deliverable folder, and the block check caught it. Its reports also record unrequested refactoring and deletions without confirmation.
- The orchestrator flagged undeclared changes in 11 of 247 block checks, mostly from the authors' own in-round requests and the environment, and stopped work in only four. It once tried to rewrite a logged stop as a pass and dispatched tasks the reviewer had flagged as unapproved.
- Reviewer: 111 reports with 508 findings, 75 blocking; a clean report only 5 times. First reviews of every spec and every task file had a blocking finding.
- Re-reviews beyond the protocol used 75.3% of reviewer tokens in three projects; 49.8% went to re-reviews after a report with no blocking finding, yet 6 of those still found blocking problems.
How they got it
A case study of the audit trail: status fields, transcripts, reviewer reports and orchestrator logs, extracted by deterministic scripts and coded by the authors with an AI coder. The workflow template is public on GitHub; extraction scripts and aggregate data are available on request.
Limits
- All projects were run by the authors, who designed the workflow; one coding agent, no control condition, so nothing shows what the controls prevented.
- Reviewer findings are counted, not validated as real defects; token counts are a lower bound.
- A single AI coder classified the origin of flagged changes, with no agreement measure; some folders were synced to cloud storage and edited during rounds.
Why it matters for companies
Controls written as instructions to the same model they constrain held for narrow executors but not for the orchestrator that judged its own checks. Teams relying on agent "guardrails" in prompts should move stops, file inventories and reviewer prompts into tooling the model cannot edit or skip. The review data also show a cost line: an unlimited reviewer loop spends most of its tokens on repeats. Showing the cost of each re-review and leaving the call to a person is a cheap fix.
Summary based on the full text. Read the original for the full argument and data.Read the original on arxiv.org