An AI coding agent will build whatever plan it is handed, including the one nobody actually approved. On a solo project that is fine — the person writing the prompt is the person who signs off. Add a team, and "who approved this?" becomes a question with no recorded answer, usually asked after the feature is already in production.
A spec approval workflow for AI coding is the sequence that decides who reviews a plan, who signs off, and what gets recorded — before an agent writes any code. It moves the decision from the pull request to the spec, names an accountable approver for scope and approach, and keeps that sign-off as traceable evidence rather than a lost thread.
Key Takeaways
- A spec approval workflow puts the sign-off before the build — at the plan, where a wrong decision is an edit instead of a rebuild.
- "Who signs off on what" is three separate questions: scope (product), approach (engineering), and risk (security or compliance) — each needs a named owner, not a shared shrug.
- A gate is only real when the approver has authority to say no, enough context to say it for the right reason, and the decision is recorded as evidence.
- Pull-request review is the wrong place to catch the expensive mistakes — it reviews syntax after the agent has already committed to an architecture.
- For regulated teams, the approval record — who approved what, when, against which version — is the artifact an auditor asks for, and git metadata alone does not supply it.
What is a spec approval workflow for AI coding agents?
A spec approval workflow for AI coding agents is a defined process in which a human reviews and formally signs off on an agent's plan — its scope, approach, and affected components — before the agent is allowed to write code. It replaces the implicit approval that used to happen while a developer typed, with an explicit gate: a named person says yes, and that yes is recorded.
The workflow matters because agents invert where decisions get made. When a person writes code, a hundred small choices are made and remembered by the author. When an agent writes it from a ticket, those choices are made in seconds and recorded nowhere unless the process forces them to be. The approval workflow is what forces them to be — it turns a stream of silent agent decisions into a small number of reviewable ones.
This is a governance layer, not a speed bump. The agent still drafts the plan and still does the building. What changes is that one checkpoint exists between "the agent has a plan" and "the agent is changing your codebase," and that checkpoint produces a record. Everything below is about where to put that checkpoint, who stands at it, and what it has to capture.
Why approval moves from the pull request to the spec
Approving at the pull request is approving too late. By the time a diff exists, the agent has already committed to a scope and an architecture, and the reviewer is left either waving through decisions they can no longer cheaply change or forcing a rebuild. Moving the gate to the spec catches the expensive mistakes while they are still an edit to a plan, not a rewrite of working code.
There is a volume problem too. An agent produces more code in an afternoon than a team can read line by line in a week, so diff review stops scaling almost immediately — and it reviews the wrong thing anyway. The costly errors are decisions: the wrong scope, a duplicated service, an architecture that ignores a system the reviewer did not know existed. None of those are visible in a syntax-clean diff. This is the same shift described in the agentic SDLC, where review moves from the code to the decision.
CodeRabbit's Issue Planner makes a version of this argument — its own materials describe letting engineers and product owners review, challenge, and edit a plan in a web app, preserving each plan version before the prompts go to a coding agent. That is plan review, and it is the right instinct. The gap the governance angle has to close is the step after review: a recorded sign-off naming an accountable approver, which plan versioning on its own does not establish.
Who signs off on what
"Who signs off" is not one question. A spec carries at least three decisions that belong to different owners: is this the right scope (product), is this the right approach (engineering), and does this introduce unacceptable risk (security or compliance). Collapsing them into a single approval means one person rubber-stamps two decisions they are not equipped to make.
Not every change needs all three. A copy tweak needs a product yes and nothing else; a change to how authentication tokens are issued needs all three and probably a second engineering reviewer. The workflow should route by blast radius, not apply one ceremony to everything — the fastest way to kill an approval process is to make a one-line fix wait on three sign-offs it never needed.
The division of labor also decides what each approver is actually certifying. Product certifies that the spec solves the right problem for the user. Engineering certifies that the approach fits the system as it exists — which means the approver needs to see the system as it exists, not the three repos they happen to remember. Security certifies that the change does not open a path the team cannot defend. Each sign-off is a claim someone's name is attached to, which is the entire point of recording it.
What makes an approval gate real
A gate is only real when three conditions hold at once: the approver has the authority to say no, they have enough context to say no for the right reason, and the decision is recorded as evidence rather than lost in a Slack thread. Miss any one and the gate is theater — the agent moves forward regardless, and you have fast vibe coding wearing a governance label.
Authority is the easy one to state and the easy one to fake. An approver who cannot in practice block a merge — because the deadline, the org chart, or the tooling makes "no" expensive — is not a gate. Context is where most approvals quietly fail: a product owner signs off on scope without knowing a service already handles the case, or an engineer approves an architecture for the repos they know and waves through the ones they do not. The approval was genuine and still under-informed. A spec approval workflow is only as good as the context it puts in front of the person signing — which is why the spec the agent receives and the reviewer's view of the codebase have to be grounded in the same reality.
Recording is the condition teams skip because it feels like overhead until the moment someone asks about a decision months later. An approval that exists only as a reaction emoji is not evidence. The record has to survive the thread it was made in, and it has to say enough — who, what, when, against which version — to reconstruct the decision without the people who made it.
Designing the sign-off workflow, step by step
A workable spec approval workflow has five stages: draft, route, review-in-context, record, and release to the agent. The agent drafts; the change is routed to the right approvers by its blast radius; each approver reviews with live system context; the sign-off is recorded against the exact spec version; and only then is the agent cleared to build against that approved version.
The load-bearing detail is the link between the recorded approval and the exact version the agent builds. If the spec can change after sign-off — a human edits it, or the agent re-plans — the approval has to either travel with that specific version or be invalidated. This is the same failure mode GitHub documents for pull requests: unless you enable the setting to dismiss stale approvals when the diff changes, an approval can persist after the content under it has moved. A spec approval that outlives the spec it approved is worse than no approval, because it looks like governance and certifies nothing.
Keep the loop tight. An approver who rejects should be able to send the spec back with a reason the agent can act on, not open a side conversation. The faster the review-and-revise cycle, the more approvals the team can afford to take seriously — and the less temptation there is to route around the gate under deadline. This is where a planning layer grounded in your codebase earns its place: it carries the context the agent has into the decision the human has to make, and keeps the approval attached as work moves into Jira, Linear, and each coding agent.
Making the sign-off audit-ready
For regulated teams, the approval record is not internal hygiene — it is the artifact an auditor asks to see. Change-management controls read a "review" as requiring that an accountable person understood the change and authorized it, not merely that a second account clicked approve. When an agent wrote most of the code, the sign-off on the plan becomes the clearest evidence that a human was in the loop at all.
That raises the bar on what the record contains. Standard git history and pull-request metadata were built to answer "what changed and who merged it," not "who decided this should be built, on what basis, and against which version of the plan." An audit-ready trail for agent-built work needs to connect the approved spec to the commits that implemented it, name the approver, and timestamp the decision — so that during an incident, an audit, or an onboarding months later, the reasoning behind a system is recoverable instead of guessed at. Enact's enterprise AI SDLC playbook walks through the evidence a governed workflow should keep.
None of this argues against moving fast with agents. It argues that the faster agents execute, the more each approval carries, and the more deliberately the record has to be built. A spec approval workflow is the difference between a team that can answer "who signed off on what" with a document and a team that answers it with a shrug. Put the gate at the plan, give the approver real context and real authority, record the decision against the version it approved, and the speed of the agents becomes something you can stand behind rather than something you hope holds.