Context is the product: inside an AI-driven delivery process
2 min readai-engineeringprocessdelivery
Most teams use AI coding tools the same way: open the editor, describe a feature, accept whatever comes back, patch the damage. Then they conclude the tools "aren't ready for production."
The tools are fine. The inputs are broken.
After shipping several production systems this way, my conclusion is simple: an AI coding session is only as good as the documents it starts from. Intelligence is abundant; context is scarce. So I treat context as a first-class engineering artifact — designed, versioned, and reviewed like code.
Here is the process, stage by stage.
1. Discovery & PRD
Before any code: a real product requirements document. Audiences, jobs-to-be-done, success metrics, and — most under-rated — non-goals. A crisp non-goals list is the single highest-leverage thing you can hand an AI assistant, because generative tools will happily build everything unless you draw the fence.
The PRD isn't a formality. Every later stage cites it. When an implementation question comes up mid-session, the answer is usually already in the PRD — which means the answer is consistent no matter which session, day, or tool is asking.
2. Rules & standards
Next, the constitution: a rules file that governs every AI-assisted session. TypeScript strictness, error-handling policy, naming conventions, folder structure, testing thresholds, forbidden patterns. Mine also includes taste — spacing systems, motion budgets, accessibility floors.
Rules turn review from debate into diff-checking. When the standard is written down, "should this be a server component?" is a lookup, not a discussion.
3. Architecture & docs
Then the system design, written before implementation: boundaries, data flow, rendering strategy, integration contracts. Not a wiki that rots — short, opinionated documents that fit in a context window.
This is the step most people skip, and it's the one that compounds hardest. A documented architecture means every AI session shares the same mental model of the system. Without it, each session re-invents one, and the codebase becomes an argument between five ghosts.
4. Context-managed AI development
Now — and only now — the fast part. Features get built in scoped sessions, and each session is loaded deliberately: the relevant PRD section, the relevant architecture doc, the rules file, and the specific files being touched. Nothing else.
Two disciplines matter here:
- Scope the session, not the day. One feature, one context, one reviewed outcome. Long meandering sessions accumulate contradictions.
- End at a checkpoint. Every session lands as a reviewable change with passing checks — types, lint, tests. AI writes a lot of the code; it never writes the definition of done.
The speedup is real and it is not magic: it's the removal of ambiguity. The tool stops guessing because the documents stopped making it guess.
5. Testing & shipping
The final gate is intentionally conventional: CI enforcing types, lint, and tests; staged rollouts; monitoring. AI-accelerated code goes through the same gate human code does — that's the point. The process buys speed at the specification end, not by loosening the quality end.
What this buys you
On a recent replatform, this process compressed a six-month conventional estimate into nine weeks — with more test coverage than the legacy system had. The interesting part isn't the number; it's where the time went. Weeks one and two produced almost no code, only documents. Everyone gets nervous at that point. Then weeks three through nine moved faster than any team I've worked on, because nobody — human or machine — was ever blocked on "what are we actually building?"
Context is the product. The code is just its compiled form.