Chapter 41 - The AI Factory

Part: IX - The Production System

Thesis

The vibe coding session is the forge — chaotic, creative, fast. The AI factory is the refinery — typed, audited, reproducible, boring. The product only exists after both have run. The factory’s job is not merely to tidy up code a model wrote. It converts stochastic proposals — code, tests, documentation, and decisions produced by a probabilistic process — into typed, tested, traceable, shippable artifacts, and, when the shipped product itself runs a model in production, into the runtime controls that will govern that model’s proposals once it is live.

Key Line

The session can be messy. The factory must be clean.

The Distinction That Changes Everything

Most teams treat the vibe coding session as the product.

They finish the session. The feature works on the machine. The prototype does what it was supposed to do. They ship it.

This is the mistake.

The session is a raw build event. It is the forge. The forge’s job is to produce a workable shape from raw material. The forge is supposed to be hot, imprecise, and fast. A forge that is slow and careful is not a forge. It is a factory pretending to be a forge.

The AI factory is the system that takes the forge’s output and turns it into something shippable. The factory is the refinery. It is supposed to be typed, audited, reproducible, and boring. A factory that is creative and improvised is not a factory. It is a forge pretending to be a factory.

These two things have different jobs. Confusing them is how teams produce output that feels like product and fails like prototype.

What The Session Produces

A vibe coding session produces a raw artifact. The raw artifact includes:

Working code (on this machine, in this environment, with these dependencies)
Notes and decisions captured in chat (which will not survive the session)
Failed attempts that illuminated constraints
Prompts that established context (which the next session will not have)
Tests that cover the cases the session thought of
Rough documentation drafted from the code as it existed during generation
Implied architecture that exists in the developer’s head and nowhere else
Hidden assumptions about state, environment, and inputs
“It works” energy that is not the same as “it is correct”

The raw artifact is valuable. It proves the concept. It demonstrates the approach. It contains working logic.

It is not a product. It is the input to the factory.

The Seven Factory Stages

The factory transforms raw session output into a shippable product through seven sequential stages. Each stage is boring by design. Boring means reliable.

Everything entering this pipeline is a proposal, not a fact — code that looks correct, notes that sound right, a test that passes for a reason nobody checked. Introduction II calls this the weights reservoir: what the model produced unaided, from what it already knew. The seven stages are the mechanism that moves what survives out of the weights and into specification and verdict, where it can be trusted for reasons that do not depend on the session having gone well.

Stage 1 — Extract

Capture everything the session produced before it is lost.

The model’s context window closes when the session ends. Everything discussed, decided, and discarded in that session disappears. The extract stage captures what was built:

Commit the working code with a meaningful message (not “wip” or “progress”)
Save session notes as a handoff file (Ch 36)
List every decision made and why
Record what was tried and failed, and why it failed
Identify the assumptions that are baked into the current implementation

Extract before the session ends. Once the context closes, the reasoning behind the choices is gone. The code remains. The why does not.

Extraction does not validate anything. It preserves a proposal — code, decision, and failure alike — so that nothing the forge produced is lost before the refinery gets a chance to test it.

Stage 2 — Normalize

Turn the raw build history into structured artifacts that can be maintained.

The normalize stage converts:

Chat decisions into ADRs (Architecture Decision Records)
Working code into typed, linted, consistently structured modules
Rough notes into a coherent spec or README section
Implicit architecture into an explicit diagram or description
Hidden assumptions into documented constraints in CLAUDE.md

The normalize stage is where the forge’s imprecision is corrected. A variable named temp2 becomes parsedUserRecord. A function that does three things becomes three functions. An implicit dependency becomes an explicit import with a clear interface.

The model can assist with normalization. It can draft the ADR from the decision log. It can rename variables and restructure functions. Every normalized artifact must be verified by a human who understands what it is supposed to do.

Every item on that list is the same move: a rule that lived only in a person’s memory, or only in the model’s weights during the session, gets moved into specification — text and structure the next session, human or model, can read before it generates anything. Normalize is where implicit knowledge stops being implicit.

Stage 3 — Validate

Run every engineering control and confirm the output is correct.

The validate stage is where the reflexes fire (Ch 10):

Unit tests pass
Integration tests pass
Type check passes with no new errors
Schema validation passes at every boundary
Lint passes with no new violations
CI pipeline passes end-to-end

The validate stage also includes human review — not to check whether the code looks good, but to run the review patterns from Ch 39: the two-pass review, the failure-mode check, the version assumption check.

If observable markers were used during the session (Ch 38), the validate stage is where they serve their purpose. The reviewer watches the demo with markers visible. When the behavior passes, the markers are swept.

The validate stage produces a clean bill of health. Everything that was supposed to run has run. Everything that was supposed to pass has passed.

Every check in this stage is a verdict in the sense Introduction II uses the word: external to the model, indifferent to how confident the session felt, and no more trustworthy than the tests and reviewers behind it. A validate stage that only re-reads the model’s own summary of its work is not a validate stage.

Stage 4 — Harden

Add the infrastructure that makes the code production-ready, and close the capabilities the feature does not need.

The forge produces a feature. The harden stage adds:

Error handling for the inputs the session did not test
Configuration for environments the session did not run in
Logging that is useful when something goes wrong
Monitoring hooks for the metrics that matter
Deploy scripts and environment configuration
Rollback paths for every state change

The harden stage does not add features. It makes the existing feature survivable in the real world.

Hardening is also where capability gets closed, not merely wrapped. A session usually leaves behind more access than the shipped feature needs: a debug route with no auth check, a script that runs against production data, a tool the agent called once and never again. Removing or narrowing that access is the elimination and substitution work from Chapter 8 and Chapter 9, applied retroactively to what the session actually built rather than to a hypothetical design. What the factory cannot make provably safe, it must at least make defined: the harden stage is where failure behavior gets decided on purpose — what happens on malformed input, on a downstream outage, on a proposal the schema rejects — instead of being discovered the first time it happens in production.

The model can assist with hardening. It can propose error handling for the cases that were not tested. It can write the logging statements. It can generate the deploy configuration from a description of the environment. Each hardening artifact must be reviewed: does this handle the right error, or does it handle the error the model thought was most common?

Stage 5 — Package

Generate the artifacts that make the work presentable and usable.

The package stage produces:

README and setup instructions (verified against the current command set)
API documentation (verified against the current interface)
Demo scripts that can be followed without prior knowledge
Changelog entry for the release
Screenshots and visual documentation
Install instructions tested from a clean environment

The package stage makes the work legible to people who were not in the session — and to models that were not in the session either. A feature that cannot be understood from its documentation is not yet packaged. A library that cannot be installed from its README is not yet packaged.

Legibility for models is not a metaphor. A future agent session reads the same README before touching this code again. A runtime model retrieving documentation as context — Chapter 29 covers IndexFoundry’s role here — reads the same API reference as specification. Documentation that is wrong for a human is wrong for a model reading it as an ex ante constraint, and a model will follow the wrong version with exactly the same confidence as the right one.

The model can draft every artifact in the package stage. Every draft must be verified: run the install instructions from scratch, execute the demo script, check that the API examples match the current API.

Stage 6 — Publish

Commit the packaged artifact to production.

The publish stage is the development commit boundary in its final form: the point where a proposal that has survived extraction, normalization, validation, and hardening stops being a candidate and becomes deployed, user-facing reality. It is gated by the definition of done (Ch 40): built, tested, documented, understood, and recoverable.

The publish stage includes:

Tagging the release with a semantic version
Deploying to production through the CI/CD pipeline
Enabling the feature flag for the target audience
Posting the release notes
Generating portfolio material and content from the completed work

The publish stage is not creative. It is procedural. The procedure is designed to be repeatable. If the publish procedure requires judgment, the judgment belongs in an earlier stage.

Stage 7 — Observe

Watch what happens after publish and feed it back into the next session.

The observe stage converts production behavior into structured input for the next forge run:

Error rates and anomalies become bug reports with reproduction cases
User feedback becomes feature requests with acceptance criteria
Performance metrics become optimization targets with current baselines
Support questions become documentation gaps
Usage patterns become insights about which features matter
Validator rejections and escaped bad output become evidence about where a specification or a check is missing, not just tickets for the next prompt

The observe stage closes the loop. The session that produces the next feature is better because the observe stage from the last feature surfaced the right problems.

Observation is only doing its job if it strengthens a control, not merely a request. A rejection log that shows the same schema failure every week is not proof the model needs a friendlier prompt. It is proof the schema, the tool boundary, or the validator has a gap a prompt cannot close. The observe stage should feed the next specification and the next verifier as often as it feeds the next conversation — otherwise the factory is just producing better guesses instead of a stronger system.

Observable markers from Ch 38 have a place in the observe stage. When a feature is deployed with monitoring hooks, the logs from those hooks are the observe stage’s input. A console event named [VCB-MARKER] login-flow-rendered becomes a production metric that tells you how often the new flow runs. Remove the label once the metric is promoted to a proper event name.

The Division Of Labor

The session can be chaotic, creative, exploratory, half-verbal, messy, fast.

The factory must be typed, audited, reproducible, and boring.

This is the division of labor:

Session (Forge)	Factory (Refinery)
Creative	Procedural
Context-dependent	Reproducible
Fast	Thorough
Human + model	System + model + human
Produces raw artifact	Produces shipped product
Can be messy	Must be clean
Closes when context closes	Runs until done is done

Teams that try to run the factory inside the session produce output that is neither creative nor clean. Teams that try to run the session inside the factory produce output that is neither fast nor flexible.

Know which stage you are in. The session is over when you commit and start the factory. The factory is over when you publish and start observing.

The Pipeline

Every vibe-coding output passes through the same pipeline:

Human intent
    |
Vibe coding session (Forge)
    |
Raw artifact: code, notes, decisions, assumptions
    |
AI factory (Refinery)
    |
  1. Extract   -- capture before context closes
  2. Normalize -- structure the raw output
  3. Validate  -- engineering controls fire
  4. Harden    -- production infrastructure added
  5. Package   -- documentation and presentation
  6. Publish   -- gate by definition of done
  7. Observe   -- feed findings into next session
    |
Shipped product
    |
Telemetry + feedback
    |
Next session

The pipeline is not optional for teams that ship. It is the difference between a working prototype and a maintained product.

The Propose / Validate / Commit loop (Ch 13) operates inside the factory. The factory is the larger loop that contains it.

Two Loops: The Factory And The Runtime

The pipeline above is a build-time loop. It runs once per feature, once per release, started by a human decision to build something and finished when Publish fires. Extract through Observe is the shape of that loop, and Introduction I calls the whole thing the build loop: proposals flow toward the repository, and a human or a pipeline decides what merges.

If the product coming out of the factory is itself AI-native — a system where a model proposes actions, claims, moves, state patches, or narration on every live request — the factory has a second job. It does not just ship application code. It ships the deterministic machinery that will constrain the model once the product is running: tool schemas that bound what the model is allowed to propose, policy and authorization code that decides what a proposal may do, state reducers that apply accepted changes, validator suites that check every proposal against the rules, evaluation harnesses that measure a model version before it is routed real traffic, event contracts that define what a claim or a state patch looks like on the wire, and rejection dashboards that make escape rate visible instead of anecdotal.

Those are factory outputs. They pass through the same seven stages as application code — extracted from the session that designed them, normalized into typed schemas, validated by their own tests, hardened against malformed input, packaged as documentation a model or a developer can retrieve, and published under the same definition of done.

But the factory does not run the runtime loop. It builds the enclosure; it does not live inside it. Once the tool schemas and validators are published, a second loop takes over — the runtime loop from Introduction I, running Propose / Validate / Commit at the runtime commit boundary instead of the development one. That loop fires on every request, at machine speed, with the human review window the factory enjoyed already spent. Chapter 42 is that loop made visible: Stagehand is what the runtime loop looks like once the factory has finished building its cage.

Confusing the two loops is a specific, recurring failure. A team that runs a careful factory pipeline for its application code but ships the model’s live tool access without the same rigor has built a refinery next to an open pipe. The forge-versus-refinery discipline has to apply twice: once to the code that becomes the product, and once to the controls that will govern the model inside it.

Practical Artifact — Factory Stage Checklist

Use this to track where a work item is in the factory pipeline.

Stage	Done when	AI role
Extract	Handoff committed, decisions logged, assumptions documented	Draft handoff from session context
Normalize	Code typed, linted, consistently structured; architecture documented	Rename, restructure, draft ADRs
Validate	All controls pass; review lanes run; markers swept	Run validation, draft missing tests
Harden	Error handling, logging, configuration, rollback path	Propose error cases, draft config
Package	README verified, demo script runs, changelog written	Draft documentation artifacts
Publish	Tagged, deployed, feature flag set, released	Generate release notes and content
Observe	Metrics live, feedback captured, next session briefed	Categorize feedback into issue types

When the shipped product is itself AI-native, three rows carry extra weight. Normalize is not done until the tool schemas and event contracts are typed, not just the application code. Validate is not done until the validator suite and model evaluation harness have their own tests, not just the feature’s tests. Harden is not done until unsafe capability has been closed and every runtime failure path is defined on purpose. The checklist does not grow new rows for this. The existing rows get stricter.

Export

Copy this block into your CLAUDE.md, agent instructions, or project checklist.

The session can be messy. The factory must be clean.

vcb_chapter: 41
title: "The AI Factory"
key_line: "The session can be messy. The factory must be clean."
thesis: "The vibe coding session is the forge. The AI factory is the refinery. The product only exists after both have run."
checklist:
  - item: "Has the session's output been extracted before the context closed?"
    protects: "against losing decisions, assumptions, and reasoning with the session"
  - item: "Is the raw code normalized: typed, linted, structured, documented?"
    protects: "against prototype-grade code becoming production debt"
  - item: "Have all engineering controls run and passed?"
    protects: "against unvalidated output crossing the factory boundary"
  - item: "Has hardening been added: error handling, logging, rollback?"
    protects: "against features that work in demos and break in production"
  - item: "Is packaging complete: README verified, demo runs from scratch?"
    protects: "against features that cannot be used by anyone who was not in the session"
  - item: "Is the publish gate satisfied: built, tested, documented, understood, recoverable?"
    protects: "against shipping before the definition of done is met"
  - item: "Is observability in place to feed the next session?"
    protects: "against losing production feedback that should drive the next build"

Session output extracted before context closed — protects against lost decisions
Code normalized: typed, linted, structured — protects against prototype debt
All engineering controls passed — protects against unvalidated production code
Hardening added: errors, logs, config, rollback — protects against demo-only reliability
Packaging verified: README runs, demo executes — protects against unusable releases
Definition of done satisfied before publish — protects against premature shipping
Observability live: metrics, feedback loop active — protects against silent failures