The failure mode

The framework lives on Process. E1 This essay tells the story of how it emerged, with the specific failures that forged it.

Most writing about AI-assisted development stays abstract. Prompting tips, model comparisons, productivity claims. This piece is different. I want to walk through the actual engineering workflow I use to build production software with AI coding agents, using this very website as the running example. The site you are reading was built entirely with this process. Every decision is logged in the repo. You can verify all of it.

The failure mode I kept hitting was straightforward. One long chat asked to be strategist, product manager, architect, implementer, reviewer, and release manager simultaneously. Context grew until constraints blurred. Scope widened. Quality dropped. Earlier assumptions were silently reinterpreted. The AI was not the problem. The process around it was.

Two-lane delivery

The fix was to separate orchestration from implementation. I split the workflow into two lanes. The control lane handles sequencing, review, and acceptance. It decides what to build, in what order, and whether the result meets the bar. The execution lane handles bounded implementation. It receives a tightly scoped specification, does one slice of work, and returns the result. These are separate chat sessions. The execution lane never decides what comes next. The control lane never writes code.

Slice specifications

Every piece of work starts as a slice specification. Before any execution chat touches code, the spec defines: what this slice delivers, what it must not do, what files are in scope, what is intentionally withheld to protect focus, the exact validation commands, and the precise definition of done. Writing the spec typically takes longer than the execution itself. That is the point. A well-scoped slice produces clean output. A vague one produces plausible-looking code that subtly misses the intent.

This website was built across roughly 15 execution slices. E2 The first slice bootstrapped the project: Next.js 15, TypeScript, Tailwind, CI pipeline. Each subsequent slice built one focused unit: design tokens, layout shell, project page schema, writing page schema, homepage sections, testing infrastructure, animations, SEO. No slice tried to do two things at once. Every slice had an explicit acceptance gate before the next one began.

Review and memory

After every slice, I review the returned work with a findings-first mindset: look for problems before confirming success. This is where the process earns its overhead. One execution chat reported that linting passed, but it had run the linter before the build output existed. When I re-ran it, hundreds of errors appeared from compiled files the ESLint config did not exclude. Another execution chat built a Contact component and a Footer with different email addresses and different LinkedIn URLs, because it had no memory of what the previous chat had used. A third chat introduced em-dashes throughout the copy, a pattern increasingly associated with AI-generated text. None of these would have been caught in a single-chat workflow where the same context that created the problem is also responsible for reviewing it.

The most important principle in this workflow is that durable state lives in repo artifacts, not in chat history. Every session starts from the same control state bundle: an operating model document, a living build plan, a decision log, and an architecture overview. E3 When a control lane session gets heavy, I restart it from these files. When an execution chat fails after two corrections, I terminate it and start fresh. No chat is precious. The files are the memory.

The workflow is not perfect. Execution chats still make inconsistent choices across slices because they have no shared memory. The control lane overhead is real: writing a detailed slice spec, carrying it to a separate chat, bringing back results, reviewing, logging. For a ten-line fix, this feels heavy. The temptation to skip the process for "small" changes is constant. The times I gave in and made a quick fix directly, it was always fine in the moment and occasionally created a consistency problem later.

What changes

The output of this process is qualitatively different from what I would produce working alone or in a single long chat session. Not because the code is better line by line. Sometimes it is, sometimes it is not. The difference is that velocity changes what is feasible. This website went from an empty directory to a deployed, tested, documented portfolio site in a single working session. The constraint is no longer implementation speed. It is the quality of the specifications and the rigor of the verification.

I think this workflow points toward something important about the future of building software. The scarce skill is not writing code. It is knowing what to build, how to decompose it, and how to verify that what was built is correct. That is a product and systems thinking skill, not a coding skill. The people who will build the most with AI agents are the ones who get very good at the control lane. The repo for this website is private, but the workflow is still built around durable repo artifacts. The operating model, build plan, decision log, and commit history are all there. If any of this is useful to you, take what works and make it yours.