Writing Specs an Agent Can Execute

I used to write requirements the way most BAs do: prose paragraphs, a table of acceptance criteria, and a quiet trust that whoever picked up the ticket would fill the gaps sensibly. That trust was well placed with a developer — they'd ask in standup, ping me on Slack, or just apply the same domain judgment I'd apply if I were coding it myself. An AI agent doesn't do that. It reads what's on the page, makes a confident decision about everything that isn't, and ships it. That single difference is rewriting what a good spec looks like. 

Requirements haven't changed. What's changed is who — or what — reads them first. When a developer picked up a ticket, the spec was a starting point for a conversation. When an agent picks up the same ticket, the spec is the conversation, and whatever it doesn't say gets decided by a model with no stake in getting it right and no instinct to ask. For a BA, that's not a tooling change. It's a change to the actual skill. 

The gap a developer used to fill silently, an agent fills with a guess 

Every requirements doc has gaps — not from carelessness, but because some things are genuinely easier to say in a hallway than in a ticket, and because a competent developer fills them in automatically from context you both share. "Handle the error case sensibly." "Match the existing pattern." "Obviously this should be idempotent." A developer reads those and reaches for the same domain knowledge you have. An agent reads them and reaches for whatever's statistically plausible, which is not the same thing, and it won't flag the difference before shipping it. 

This is the part that catches BAs off guard the first time: the failure mode isn't the agent refusing to proceed on an ambiguous requirement. It's the agent proceeding confidently, producing something that compiles, passes the tests it wrote for itself, and does the wrong thing — because the wrong thing was a perfectly reasonable reading of an underspecified sentence. A human reviewer used to be your safety net for that kind of gap. With agent-generated code shipping faster and in higher volume, you can't rely on review to catch every one of them. The spec has to close the gap before the agent gets there. 

From prose requirements to acceptance criteria that map to tests 

The most direct fix is also the most mechanical one: write acceptance criteria in a constrained syntax that maps one-to-one onto a test case, instead of a sentence that admits more than one reading. EARS (Easy Approach to Requirements Syntax) has become the practical standard for this, precisely because it's restrictive enough to force the ambiguity out during writing rather than during code review. Five patterns cover almost everything a BA needs: 

Ubiquitous:        The system shall [always-true behavior]. 

Event-driven:       When [trigger occurs], the system shall [response]. 

State-driven:        While [condition holds], the system shall [behavior]. 

Unwanted behavior:  If [error condition], then the system shall [consequence]. 

Optional feature:   Where [feature is enabled], the system shall [behavior]. 

  

Compare the two versions of the same requirement: 

Prose version: "The system should stop customers going over their daily transfer limit." 

EARS version: 

When a customer initiates a transfer that would cause their cumulative 

daily transfer total to exceed their configured daily limit, the system 

shall reject the transfer and return error code TRANSFER_LIMIT_EXCEEDED. 

 

If the customer's daily limit has not been configured, then the system 

shall apply the account-tier default limit before evaluating the 

transfer. 

 

While a transfer is pending manual review, the system shall exclude 

its amount from the cumulative daily total until the review resolves. 

  

The prose version reads fine to a person and hides three decisions: what happens at exactly the limit, what happens when no limit is configured, and how pending transfers count toward the total. An agent will resolve all three — just not necessarily the way you would have. The EARS version forces you, the BA, to make those calls at spec time, which is where they're cheap, instead of discovering them in QA or production, where they aren't. 

Scope has to be written as a boundary, not implied by omission 

Developers generally under-build relative to a vague spec — when in doubt, they ask rather than add. Agents skew the other way. An agent optimizing for "complete, working code" will often add validation, retry logic, extra endpoints, or configuration options you never asked for, because it read the ticket as a starting point for a plausible feature rather than a bounded unit of work. That's scope creep with no human in the loop to notice it's happening until the PR is already large. 

The fix is a section most human-facing specs skip entirely: explicit out of scope. Not "we'll figure that out later," but a direct list of what the agent should not touch, build, or infer — adjacent endpoints, related tables, configuration surfaces, anything that looks like natural extension work but wasn't asked for. It reads like unnecessary caution when you're writing it for a person. It's load-bearing when you're writing it for an agent that has no sense of "not my job." 

Edge cases can't live in the tester's head anymore 

QA has always caught things the spec didn't spell out, because a human tester brings the same tacit domain sense a developer does — they poke at boundary conditions, weird input, and unlikely sequences because experience tells them that's where bugs live. An agent implementing from a spec doesn't have that instinct working in your favor. It builds to what's written. If the null case, the zero case, the "customer closes the account mid-transaction" case aren't in the spec, there is no guarantee of a human catching that gap before it ships — and increasingly, no guarantee a human is even in that part of the loop. 

That means edge cases move from "things QA will probably find" to "things the BA has to enumerate," and enumerate specifically enough that each one reads as its own EARS statement rather than a bullet under "edge cases to consider." It's more writing up front. It's also precisely the kind of writing a BA is already trained to do — thinking through what happens at every boundary of a business rule — just aimed at a reader that won't do that thinking on your behalf. 

Traceability isn't a nice-to-have anymore — it's the acceptance test 

The teams getting real value from agent-driven delivery aren't the ones handing an agent a spec once and letting the code drift from it afterward (what the field's calling spec-first), and they're not going all the way to letting specs alone govern every change with no human anchor (spec-as-source — still mostly hype). The sweet spot in practice is spec-anchored: the spec and the code evolve together, and every acceptance criterion has a test that fails the moment the code drifts from what was specified. That only works if every requirement, acceptance criterion, and generated test can be traced back to each other — which is a BA deliverable, not an engineering afterthought. 

For anyone delivering into a regulated environment, this should sound familiar rather than novel: it's the same traceability discipline auditors already expect between a requirement and the evidence it was met. Agent-executed specs just make that discipline mandatory for the software to work correctly, not only to pass an audit. A spec that traces cleanly is one where an agent's output can be checked against intent automatically — and one where, six months later, someone can still answer "why does the system behave this way" by pointing at a document instead of reverse-engineering the code. 

The BA's new artifact set 

In practice, this is showing up as a structured workflow rather than a single document: a short constitution of non-negotiable rules for the domain, a specification of the feature in EARS-style acceptance criteria, a clarification pass where ambiguities get resolved before any code is written, a plan the agent proposes against that spec, and a task breakdown that cites the specific requirement each piece of work traces back to. Tooling is converging around this shape — GitHub's Spec Kit, Claude Code's spec-driven workflows, Cursor's plan mode, and several others all implement some version of specify-clarify-plan-implement — but the pattern matters more than any specific tool, and it's a workflow a BA is better positioned to own than anyone else on the team. 

None of this replaces the judgment a good BA already brings — understanding the business, negotiating trade-offs with stakeholders, knowing which ambiguity is safe to leave and which isn't. What's changed is that the artifact carrying that judgment now has to survive being read by something with none of its own. Writing it that precisely used to be optional, a nice-to-have for the BAs who liked structure. Now it's the difference between an agent building what the business actually needs and an agent building a confident, well-tested guess. 

We've built delivery practices around exactly this kind of precision for banking clients long before agents were part of the toolchain — audit trails, traceable requirements, and specs written to survive scrutiny from someone who wasn't in the room. That discipline turns out to be the same discipline agent-driven delivery now demands. It's just got a new reader.