Specs the team can run — one artifact that pins down “done,” guards every future change, and talks to the business.
The team friction “Done” lives in too many heads. A prose ticket means one thing to its author, another to each developer, another to the agent — and nobody learns they diverged until integration, or until a later change silently breaks old behaviour with no test to catch it. The team has no single, durable definition of what the software must do.
The pattern The team captures behaviour as executable specifications — think Specification by Example or BDD: concrete examples written as acceptance tests the code must pass. They emerge during implementation, not as big-design-up-front, and accrue into the team’s living regression suite. Don’t mandate a notation — Gherkin earns its place sometimes but writing the specs in the app language is also ok; mandate that the agreed behaviour is runnable. Interpreted into plain language, those same specs become the artifact you walk business stakeholders through — a palatable view, not the raw tests.
Why it works with AI A runnable spec is the one form of “what we meant” an agent can check itself against: it turns intent into a target the agent must turn green, catching the plausible-but-wrong code agents produce at volume. And because agents make tests cheap to write, the regression net the team always wanted is finally affordable to keep.
Watch-outs Executable isn’t exhaustive — spec the behaviour that matters, not every getter. Keep the stakeholder view interpreted and readable; raw Gherkin is rarely the thing to show the business. And don’t impose one syntax on the team — mandate runnable, agreed examples, not a format.
Related Plan together, work alone · Gap analysis: prototype vs. product · Agent-written shared docs