Production-Ready AI Software Engineering

What production-ready means

Production-ready is a property you can check, not a feeling of confidence. A change is production-ready when the code has been reviewed against an explicit standard, the behavior it claims is covered by tests that ran, its security-relevant surfaces have been examined, the documentation that describes it still tells the truth, and there is a record connecting all of that to the exact content being shipped.

Few teams would argue with that list. The gap is enforcement: each item lives in a different tool, none of them binds to the others, and the release decision is a human looking at green dots. A green dot says a job finished. It does not say what the job examined, whether the standard was the right one for this change, or whether anything checked the parts that matter.

What AI generation changes

AI assistants raise output volume and lower the cost of producing plausible code. They also shift the bottleneck: review capacity stays flat while the volume needing review grows, and plausibility makes weak code harder to spot, not easier.

An assistant optimizes for code that looks right and satisfies the prompt. It has no stake in your test coverage, your threat model, or whether the README still matches the behavior. Those concerns belong to the engineering layer around the assistant, and if that layer is a human skimming a large diff, volume wins.

The failure mode is rarely dramatic. It is a login flow with no rate limiting, a migration nobody classified as risky, a doc that describes last month's API. Each is catchable by a check that runs every time. None is reliably catchable by attention that has to stretch across everything.

The six practices

1. Executable review standards

A review standard that lives in a wiki is advice. A review standard that runs is a control. Encode the checks you care about (architecture, security surfaces, test gaps, dependency state) as executable review steps that run against the actual diff, in the IDE while the change is cheap to fix and again in CI where the result is recorded.

This is what the skills catalog is: review steps as runnable units, versioned and installed per project rather than remembered per person. →

2. Risk classification from the diff

Not every change deserves the same scrutiny, and asking authors to self-declare risk is unreliable. Classify the diff itself: auth-touching, schema-migrating, API-contract-changing, dependency-moving. Let the classification decide which evidence the release requires. →

3. Evidence binding

Record what each check examined, what it found, and bind the record to a digest of the exact content reviewed. The binding is the point: evidence that floats free of content can be re-used, go stale, or describe a different change entirely. Evidence bound to a content digest can be replayed and audited later, including by someone who does not trust you.

Two of our own incidents that make the case: a merge gate refused its own repository because a required domain had no evidence, and a digest probe caught a repository whose fresh clones were modified before anyone touched them. Both are written up in the engineering notes, with the fixes. →

4. Gates that fail closed

A gate that passes when evidence is missing is a formality. The release decision should be computed from the evidence by a deterministic function of a versioned policy: same inputs, replayable. Missing evidence fails. Stale evidence fails. No model, and no tired human at the end of a sprint, can talk it into passing.

Overrides still exist, because judgment still exists. The requirement is that an override is recorded like everything else: who, why, what scope, what expiry.

5. Post-deploy verification

Merge-time checks examine what will ship. They cannot tell you the deploy worked, the login flow functions in production, or the vendor API your adapter calls still behaves as it did in March. Post-deploy verification runs the journeys that matter against the deployed system and records the results as evidence in the same chain. A weekly read-only smoke against real vendor credentials catches drift your mocks won't. →

6. Institutional learning from failures

When a check catches something real, the catch should change the system: a recorded lesson with a named cause, a new probe. The alternative is the senior engineer who remembers why, and that knowledge leaves when they do.

For teams and organizations

Everything above compounds at team scale, because the alternative fragments: each developer-assistant pair drifts toward its own definition of done. One encoded standard, applied to every change regardless of author or assistant, with decisions recorded in an append-only ledger, is what makes AI-assisted development governable rather than merely fast.

The organizational layer adds identity and accountability: deny-by-default roles, recorded overrides, compliance mapping that starts from proof of controls. The enterprise page covers what ships there. →

Where to start

Start smaller than you think: one repository, review-as-execution plus a fail-closed gate on one risky change class. The free tier covers it and the guided path does the setup. Expand by what the evidence tells you, not by roadmap.

And if you want to evaluate the claims before adopting anything, the machinery is public: every release decision this platform makes about itself is countersigned and verifiable against a published key, and the failures are written up alongside the passes.