Last updated September 18, 2026
4 min read
A fictional six-engineer B2B team receives a request to export customer records. The first plan says add endpoint and tests. It omits authorization, volume, audit events, retention, rollback, and the person allowed to accept data risk. Coding would make those missing decisions harder to see. This is an explicitly fictional composite, not a customer result.
In this article
A plan exists to expose decisions
A useful plan is not a longer task list. It is a decision surface. Each step states what changes, why it is needed, which acceptance criterion it serves, and what could invalidate it. The sharpest plan is often the one that removes an unnecessary step before code appears.
NIST AI RMF Core bounds this claim. Voluntary risk guidance, not certification or product proof.
| Evidence point | Interpretation |
|---|---|
| 1 | Task list: edit files |
| 2 | Reviewable plan: explain decisions |
| 3 | Hidden risk: discovered after code |
| 4 | Visible risk: owned before code |
Treat the table as a working diagnostic. Replace illustrative labels with repository evidence before making a budget, staffing, or release decision.
Ownership and module attribution come first
Name the product owner, module owner, reviewer, and final risk authority. Record every affected module and data boundary. This prevents a cross-module change from inheriting the rules of whichever file the agent opened first.
Order matters because later checks inherit the intent and scope established earlier. A skipped step does not remove uncertainty. It hands that uncertainty to a reviewer under time pressure.
Proof and rollback belong beside implementation
Attach a proof method and rollback note to every risky step. If the proof depends on a test, name the behavior the test must challenge. If rollback is impossible after a migration, say so and route the feature accordingly.
Google DORA 2025 adds a second evidence boundary. Observational associations, not universal causation.
A procedural fix can be inspected, rehearsed, and improved. A warning without an owner or artifact usually disappears during the next busy sprint.
Compile a machine-readable planning contract
Represent the approved plan in a structured file with stable IDs. That lets checks, reviews, and documentation refer to the same step without paraphrasing it. Keep unresolved decisions explicit; an empty field must not silently become approval.
paqad-ai v1.67.0 was the current public release when this article was checked on July 21, 2026. Its repository describes risk routing, specialist roles, structured state, deterministic checks, documentation sync, and local audit records. These are product mechanisms, not independent outcome proof.
Use the AI workflow audit guide to map current practice, compare the bar with production-ready AI code, and use the AI coding consultant guide when the team needs outside ownership.
Decision rule: If a reviewer cannot identify ownership, risk, proof, and rollback from the plan, do not start implementation.
Run the reviewable feature-plan schema in a 45-minute working review with the product owner, module owner, and final reviewer. Do not turn it into a score. Read the decision rule aloud: If a reviewer cannot identify ownership, risk, proof, and rollback from the plan, do not start implementation. Record disagreements, missing evidence, and the person responsible for the next action. Repeat the review after one real feature so the team can compare whether the artifact reduced ambiguity or only added paperwork.
Frequently Asked Questions
How detailed should an AI feature plan be?
Detailed enough that a reviewer can challenge scope, risk, reuse, proof, and rollback without reading implementation code. Keep obvious low-risk work short and expand only where uncertainty or consequence rises.
Should the agent approve its own plan?
No. The worker can draft and revise it, but the accountable product or technical owner should approve risk-bearing decisions. Deterministic checks can validate completeness without owning judgment.
What if the plan changes during development?
Create an explicit approved revision, record why evidence from the prior version no longer applies, and update affected steps. Do not rewrite history as if the first plan never existed.
What next?
Apply the reviewable feature-plan schema to one current feature. If the repository cannot answer the questions it exposes, install paqad-ai and test a governed workflow with local evidence and explicit human authority.