Spec-Driven Development With AI: Resolving Policy Conflicts Before Code

“Spec-first” or “spec-driven” development is already a recognized practice — write a specification, generate code from it, keep the two in sync. That solves a real problem: code drifting away from its stated intent. It does not solve a different, earlier problem, which matters more for a regulated or enterprise engineering org: whether the specification itself is safe to build, before anyone starts generating anything from it.

The conventional pattern treats requirements and design as serial steps — requirements get written, then handed off, then designed against separately, often by different people or teams. That gap is exactly where security, accessibility, data-retention, and brand conflicts hide until someone finds them in review, by which point a plan and possibly working code already exist, and the conversation becomes about how much rework is acceptable rather than what the right answer is.

The fix is to draft requirements and design in one working pass, with an AI agent reading the accepted intent record alongside your live policy sources — security standards, accessibility requirements, data classification rules, brand guidelines — while the specification is being written. Contradictions get flagged as open questions with a named policy owner, not buried in prose or discovered three weeks later when someone finally reads the whole document end to end.

This only works if the policy sources are current and the agent is explicitly told to name conflicts rather than resolve them silently. A spec that quietly picks a side on a security-versus-usability trade-off without surfacing it is worse than no spec at all — it looks resolved when it isn't, and the person reading it has no reason to question a decision that was never presented as a decision.

An intent record asks for a way to let support staff temporarily impersonate a customer account to debug an issue. Drafted as a spec without policy in the loop, the natural implementation is a “login as user” button — fast to build, and a serious audit-and-privacy problem the moment it exists. Drafted with access-control and audit policy loaded, the spec surfaces the conflict explicitly: impersonation must be time-boxed, logged as a distinct audit event visible to the customer, and require a reason code — and names the security policy owner who needs to sign off on the exact boundary. The feature still ships. It ships as something that survives an audit instead of becoming an incident.

If the feature being specified is itself an AI-powered capability — a new agent, a new use of Codex or the platform APIs, a new automated workflow — the specification needs additional fields a purely deterministic feature doesn't: which model or provider it routes to, what context and memory it can access, what tools or actions it is authorized to take, what gets logged for audit, what the safety gate looks like, and who can see its output at each visibility tier (end user, admin, super-admin). Skipping these fields is how an AI feature ships with broader access than anyone intended, discovered only when someone asks why the assistant could see data it had no reason to see.

At a ten-person engineering org, one-pass drafting often works with a single well-briefed reviewer who personally knows most of the policy landscape — security, privacy, and brand fit in one person's head, and conflicts get resolved in a five-minute conversation. That doesn't survive past a certain size. At two hundred engineers across multiple product lines, no single reviewer holds the whole policy picture, and the same one-pass drafting step needs the AI agent to read from explicitly named, current policy sources rather than someone's institutional memory — which is precisely why the policy sources need a named owner and a version history, not just a shared drive folder someone updates when they remember to.

The practical implication for a rollout: don't design the process around the org you have today if you expect to grow past it. A spec-drafting workflow that depends on one person's tacit knowledge of every policy is a bottleneck waiting to happen, and it's cheaper to name policy owners and write down the sources now than to reconstruct that knowledge under pressure later.

Track the time between an accepted intent and a committed spec — this is where AI assistance compresses the calendar most visibly, often from days of back-and-forth to a single working session. Separately, track requirements rework after the first implementation plan exists; a rising number there means policy conflicts are still being found too late, not that specs are being written too fast.

Loading policy as a checklist to tick, not a source to reason against. A shallow implementation asks “does this violate rule 4.2” and stops there. A useful one reads the policy's intent well enough to catch a novel situation the rule's author never anticipated — the checklist framing misses exactly the conflicts that matter most, because those are the ones nobody wrote a rule for yet.

Naming a policy owner who doesn't actually have authority to decide. Routing a conflict to someone who will just forward it to their manager adds a step without adding a decision. The named owner in a spec should be whoever can actually say yes or no, not whoever is easiest to tag.

Writing the AI-capability fields as an afterthought. Model routing, tool access, and audit requirements get bolted onto the end of a spec that was really designed for a conventional feature. When the AI path is central to what's being built, it deserves the same up-front design attention as the data model or the API contract — not a paragraph added during review because someone asked what model it uses.