Specs and tests: the stable stack for AI coding
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
When you let coding agents work in parallel, the thing that keeps you sane is a written contract: a spec plus tests that every change gets checked against. A spec is the agreed behavior of the work, in plain words, before any code runs. Models and tools rotate fast. The contract is what holds still. Cursor will happily spin up several agents at once, and that speed is exactly why the spec matters more than it used to.
Here is the failure mode in one sentence. Parallelism punishes fuzzy scopes first, because two agents with overlapping, unwritten boundaries will both reach for the same file and you only find out at merge time.
Why fuzzy scopes break under parallel agents
Brooks's law was about people: add workers to underspecified work and it ships later, not sooner. The same thing happens with agents, except you can add a worker in seconds. So the spec becomes the bottleneck on day one instead of week three.
The classic trap is trusting reviewers to absorb intent that nobody wrote down. It feels fine while one person owns the change. It falls apart the moment three forks run at once and none of them carry a record of what they were allowed to touch.
Review cannot recover what the repo never recorded. No amount of model quality writes that record for you. That is the job of the spec.
Set up the four artifacts that keep agents in bounds
The stable stack is not a framework. It is a small set of artifacts that stay true while agents work in parallel. Four of them cover most of the pain.
A scope ledger lives in the parent chat and is five lines: goal, allowed paths, forbidden paths, verification command, merge owner. Review stops being an argument about what the prompt meant and becomes a check of the ledger against the diff.
A child receipt block is what each parallel child returns: the paths it touched, the commands it ran, the tests that prove its regression guards. Parents merge evidence instead of confidence, which kills the machine-speed telephone game where summaries quietly drop the files the child actually edited.
A decision stub sits in the PR template and forces three lines: constraints considered, alternatives rejected, verification proof. Green CI with no written "why this approach" is how a queue fills up with changes nobody can defend later.
A connector card is one markdown file per MCP server: allowed actions, forbidden actions, owner, rollback. A connector wired for a demo tends to drift into data nobody put on the diagram, and the card is where you write down what "off" looks like before you need it.
Here is a starter delegation boundary you can drop into a repo and adapt:
---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
- "**/*"
alwaysApply: false
---
- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.
In our methodology the spec belongs to the Plan step: agents inherit what Plan wrote down, and nothing else. If you want the rest of the cluster, the related patterns live on the agentic coding governance page, and AI coding tools that keep working after rollout shows what the same contract looks like at tool-selection time.
Check the contract at merge time
A spec did its job when the reviewer never has to ask why the agent touched a given file. The answer is already in the diff, the receipt, and the ledger. Run merges through a short gate so nothing slips by on vibes.
| Gate | Question |
|---|---|
| Risk routing | Were red folders touched, and who approved? |
| Replay proof | Which commands prove the regression guards? |
| Receipt match | Does the PR body list scopes plus a verification transcript? |
| Rules precedence | Which .mdc, SKILL.md, or CLAUDE.md governed behavior? |
Picture two clocks: one for shipping, one for explaining. When only the shipping clock ticks, you borrow against the explaining clock and pay it back later with interest.
Some decisions stay off autopilot no matter how good the agents get. Threat models, customer promises, and blast-radius calls belong to a human.
Put this research to work
This is most useful for Cursor teams picking which rule, subagent, skill, or MCP boundary to standardize next. Start by turning the scope ledger into a .mdc rule, an AGENTS.md note, a subagent receipt, or a review checklist before your next parallel run. Then compare the spec-first path against your current Cursor review flow and connector scope, and keep whichever one leaves the shortest auditable trail.
Where to start
Pick one parallel change you have coming up and write its scope ledger first, before any agent runs. If your specs live in chat and your tests live in hope, we can help you move both into the repo: book a 15-minute sync.