"I use AI" doesn't mean much anymore. Everyone uses AI. The interesting question — the one I've been living in for the past few weeks — is whether you can run an AI agent through a real delivery process: clear roles, clean handoffs, and an audit trail you could hand to a regulator without flinching.
One of those is a party trick. The other is a discipline. I'm chasing the discipline, and I'm going to show my work the whole way through — including the parts that are still rough.
This is the first post in that series. By the end of it you'll be able to read the three documents I wrote before the AI was allowed to touch a single line of code. They're attached, in full, further down. But first, why they exist.
The gap nobody talks about
When a developer prompts an AI to "build me a thing," they usually get a thing. It compiles, it demos, everyone claps. Then someone asks the questions that actually matter on a real project: Which requirement does this satisfy? Who approved that change? Where's the test that proves it works? Can you reconstruct, six months from now, why it was built this way?
That's the gap. Producing output is easy. Proving it was built to spec, reviewed at the right gate, and traceable from requirement to test — that's what earns trust in fintech, supply chain, and defense. It's also, conveniently, exactly the job a project manager already does for human teams. So I started treating the agent like a new team member who's brilliant, fast, and completely without judgment unless I give it some.
What I mapped before writing anything
I'm not interested in vibes-based AI coding. So I spent the first stretch just understanding the landscape, the way I'd scope any unfamiliar program before committing a plan:
- Spec-Driven Development (SDD). The core idea is a clean inversion: the spec is the source of truth, and the code serves the spec — not the other way around. The written intent is the artifact you protect; the code is a downstream output of it.
- Greenfield vs. brownfield. Building something brand new is the easy demo. Safely changing a system that already exists — with users, history, and consequences — is the real skill. I want to be credible at both, so I'm deliberately practicing the greenfield version first to get the discipline clean, then taking it into brownfield.
- Three tools I'm going deep on: GitHub Spec Kit, OpenSpec, and BMAD. Different philosophies, same underlying bet — that structure up front beats cleverness later.
The project: a PMO RAID Register
I needed a real thing to build, not a toy. So I picked a problem I've actually lived: the RAID log. Every project has four things a manager watches constantly — Risks (what could go wrong), Assumptions (what we're taking for granted), Issues (what's already gone wrong), and Dependencies (what we're waiting on from someone else).
Most teams keep this in a spreadsheet that rots within a month. No record of who changed what. Ownership goes fuzzy. And pulling a clean update for leadership means rebuilding the whole thing by hand every week. I've done that rebuild more times than I'd like to admit.
So the tool is simple on purpose: one place to log RAID items, keep them current, see the full history behind every one of them, and print a tidy status summary on demand. The interesting part isn't the app. It's how I made the agent build it.
Three documents, in order
Before any code, I wrote three things. Each has a different job, a different reader, and a strict rule about what's allowed inside it. Here they are — open them, they're the real deliverables:
The Constitution
The non-negotiable rules the AI must follow before it writes anything. Governance baked in, not bolted on.
The Spec
The plain what & why. Written so any stakeholder can read it and approve it — zero technical detail.
The Plan
The how. The deliberate technical approach an AI agent actually builds from, checked against the constitution.
Prefer one file? Here's — the spec, the plan, and the constitution in one document.
1. The Constitution — rules before code
This is the part most people skip, and it's the part I think matters most. Before a single requirement, I wrote down the principles the agent is never allowed to break. Not suggestions — articles. When an article and a feature request conflict, the article wins until I formally amend it.
A few of them, in plain terms:
Article I — Spec-First & Traceability. No code is written without a corresponding requirement. Every requirement carries a stable ID; every task and test references the ID it satisfies. The result is a continuous trace from intent → spec → task → test, reconstructable at any time.
Article II — Auditability. Every create, update, or delete is recorded in an append-only log — timestamp, who, what changed, old value, new value. Audit records are never editable through the app. Absence of an audit trail is a defect, not a missing feature.
Article IV — Simplicity. Start with the simplest design that satisfies the spec. No microservices, no caching layer, no dependency unless a requirement demonstrably needs it.
There are nine articles in total — covering test-first development, data privacy, a security baseline, accessibility (RAID status never shown by color alone), observability, and plain-language readability. The closing line is the one I keep coming back to: "Compliance is not a final checklist; it is the condition under which the agent is permitted to work."
2. The Spec — the what, for humans
The spec has one hard rule: a non-technical stakeholder has to be able to read it and approve it. No implementation detail is allowed to leak in. It describes the problem, who uses the tool, every action walked through in plain English, and then a numbered list of testable requirements — because that numbering is the thread that later lets me prove the finished tool does exactly what was agreed.
It also does something I wish more specs did: it writes down the questions I answered before building (one user or many? one export format or several?), and an explicit list of what this version deliberately leaves out. Every omission is a decision on the record, not an oversight someone discovers later.
3. The Plan — the how, for the agent
The plan is where the technical decisions live, and it's written for two readers: the AI agent that builds from it, and the human reviewing my work. Every choice is justified against the constitution — and where I kept things boring (a single local file, SQLite, plain pages, a locked history backed up at the database level), I said why boring was the right call.
My angle: traceability is the product
Here's the thing the demo videos miss. The RAID app is fine. What I actually built is a repeatable, governed way to direct an AI agent — one where I can stand in front of a reviewer and draw the line from "here's what we agreed to build" to "here's the code, and here's the test that proves it."
That's the same instinct I bring to a $600K program with zero room for slippage: decide deliberately up front, leave a trail, and never let "it works" stand in for "it's right." The agent just made that instinct portable to code.
I'm sharing every step of this — the documents above are the real start. Next up: turning the plan into a task list, writing the tests first, and letting the agent build against them. If you run delivery and you're trying to make agents trustworthy rather than just fast, I'd genuinely like to compare notes.