Specs and tests: the stable stack for AI coding

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, Anysphere's AI code editor, 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.

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.

Common questions

Do coding agents need specs and tests to be reliable? Yes. Agents inherit ambiguity faster than people do, so anything left unwritten gets resolved differently by every fork. Specs pin the expected behavior and tests prove it runs, and together they give parallel agents a contract that does not depend on chat memory. Without it, each fork invents its own answer.

Why does parallel agent work fail without clear scopes? Because parallelism punishes fuzzy scopes first. Two agents with overlapping, unwritten boundaries will both touch the contested path, and the conflict shows up at merge time as a mystery you have to debug. A five-line scope ledger per fork keeps each boundary checkable against the actual diff.

What is a scope ledger? It is five lines carried in the parent chat: goal, allowed paths, forbidden paths, verification command, merge owner. That is the smallest spec that still lets a reviewer test an agent's diff against a written boundary instead of against someone's memory of the prompt. Anyone on the team can read it in seconds.

Where should the spec actually live? In the repo, next to the code, not in a chat window that disappears. A .mdc rule, an AGENTS.md file, a PR template, or a connector card all count. The test is simple: if a new reviewer can find the boundary without asking you, the spec is in the right place.

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.

Further reading

• Cursor docs: Agent
• OWASP Top 10 for Large Language Model Applications
• NIST AI Risk Management Framework
• Google Search Central: helpful, people-first content
• Google Search Central: generative AI content guidance
• Model Context Protocol specification
• OpenAI Skills repository