Running Claude Code as a Production Engineering Practice

What is production agentic delivery?

Production agentic delivery means running Claude Code as the primary engineering surface for billable or production work, gated by deterministic validators rather than ad-hoc review. The model writes the change. A layer of code that runs on every change decides whether it ships.

That second sentence is the whole argument. Every team I've watched adopt an AI coding tool started the same way: treat the model as faster autocomplete, keep the old review habits, hope for the best. You get a productivity bump for the individual and a quality problem for the system. Closing that gap doesn't take a better prompt. It takes an enforcement layer that doesn't depend on anyone, human or model, remembering to be careful.

I draw a sharp line between this and unstructured prompting. In an earlier piece on the AI coding spectrum I argued that the diagnostic separating real agentic development from improvisation is a single question: who owns the verification loop? When a person eyeballs the diff, the loop is informal and it drifts. When deterministic gates own it, the loop holds at volume. Production agentic delivery is the version where the loop is owned by tooling, the work is billable, and the receipts are public.

Why isn't running Claude Code in production just a matter of better prompts?

Because the failure modes do not live in the prompt. They live in the gap between an individual feeling faster and a system getting worse.

The 2024 DORA State of DevOps report measured that gap directly. AI adoption raised individual productivity and job satisfaction, and at the same time it was associated with lower software delivery stability and slightly lower throughput at the organizational level. Developers feel the speedup. The instability shows up a layer out, in the delivery system. That's the paradox any serious adoption has to engineer around.

The trust data tells the same story from the practitioner's chair. In the 2024 Stack Overflow Developer Survey, a majority of professional developers were using AI tools, yet close to two in five reported little or no trust in AI-generated code, and source attribution ranked among the qualities they most wanted. People are shipping output they do not fully trust, which is a recipe for either silent risk or slow re-review that erases the gain.

None of this is an argument against the tools. It is an argument for the missing layer. I have written separately about where that layer belongs: a governing posture that standardizes outcomes rather than keystrokes, a decision tree for which rule goes where, and a hard look at what a severity label actually means in an AI review. The common thread: an instruction the model can reinterpret is advisory, and advisory controls fail at scale.

What does "gated by deterministic validators" actually mean?

It means the quality bar lives in code that runs every time, not in a document a model can read and quietly route around.

A deterministic gate is anything with a binary verdict that the workflow cannot skip: a pre-write hook that refuses a banned pattern before it touches disk, a build that has to pass, a test, a schema check, a script that compares a claim against a registry and exits non-zero on a mismatch. The model does not get a vote. This matters because the most common alternative, asking an AI to grade AI, is structurally shaky.

Unsuccessful products almost always share a common root cause: a failure to create robust evaluation systems. Hamel Husain, "Your AI Product Needs Evals"

The practitioner literature on evaluation is blunt about why model-graded checks can't carry the load alone. Hamel Husain's case for evals is that the missing evaluation system is the root cause behind most failed AI products. Eugene Yan's survey of using language models as evaluators documents bias that's systematic rather than random: judges favor whichever option comes first, favor longer answers, and favor their own outputs. Human agreement on the subjective calls falls well below where you'd want a quality gate to sit. Bias of that shape means an AI-graded pipeline can be confidently wrong in the same direction over and over. Code-based gates are the antidote precisely because they don't have opinions.

This is what I mean by the AI authoring trust chain: the end-to-end set of deny-by-default gates that make AI-authored output verifiable rather than merely plausible. The point is not that gates catch everything. The point is that the things that have to hold every time are enforced by something that runs every time.

How do you demonstrate the practice instead of claiming it?

By running your own delivery under the same gates you recommend, and publishing the result.

This site is the proof. Ready Solutions AI, its writing, and its tooling were built agentically with Claude Code: 3,182 commits over roughly 52 days, around 75 percent of them authored under Claude Code's default commit identity, the rest under the human identity. That is not a slide. It is a git history anyone can read.

Every post on the blog ships through an authoring pipeline I documented as a public case study and a companion white paper. It exists because AI-assisted writing has 7 recurring failure modes, from fabricated statistics to voice drift to claims a hook never enforces, and prose reminders catch none of them at volume. So the pipeline is built as 5 layers, each catching a distinct failure class: a long-lived knowledge base, a deterministic script layer, a synchronous pre-write hook, a set of read-only specialist subagents, and an orchestrating skill that owns every write. The judgment work is fanned out across 12 specialist subagents; the mechanical work is held by more than a dozen deterministic validators. The pattern is hub and spoke, with authority terminating at each node, the same subagent orchestration shape I've mapped for production Claude workloads.

The receipt that makes this auditable is provenance. Each artifact carries agentic pipeline provenance: a machine-readable record of the model version, the skill version, the knowledge-base state, and the validation passes that produced it. When something is wrong, provenance makes the failure traceable instead of mysterious. I hold personal projects to the same standard, from a full-stack app built without a keyboard to a compatibility scanner whose entire value is catching what advisory prose misses.

How is this different from credential-led Claude consulting?

The difference is what a buyer can inspect before they sign anything.

A large part of the Claude-consulting market sells trust on credentials: certification badges, partner-program membership, and outcome figures with no methodology attached. Some of it is more substantive and reports first-party results, which is better, but still asks you to take the delivery on faith because the artifacts stay private. Both rest on the same move: believe the claim because of who is making it.

A demonstrated practice inverts that. Instead of a badge, you get the commit history. Instead of a number on a landing page, you get the pipeline, the gates, and the provenance metadata, open for inspection before any contract.

Be skeptical of the obvious objection: a commit history on its own proves the tools were used, not that the work was good, and provenance you write yourself is still self-reported. That's the right pushback, and it's why the weight sits on the gates and their pass-or-fail records rather than on the commit count. A validator that blocks a fabricated statistic is checkable in a way a green dashboard number never is. None of this says demonstrated work is morally better than credentialed work. It's a category distinction a buyer can act on: published evidence can be checked, and a promise cannot. When I scope an implementation or advisory engagement, the deliverable includes the enforcement layer and the documentation to run it after handoff, because the same discipline that makes my own delivery auditable is the thing worth buying.

Doesn't the research say AI makes experienced engineers slower?

It says something narrower than the headline, and an honest version of this practice has to meet it head on. A randomized controlled trial from METR found that experienced open-source developers took roughly 19 percent longer to complete real tasks when allowed to use AI tools. More striking, they believed they'd been sped up, both before the study and after finishing it. The perception gap survived direct experience. If skilled engineers can be that wrong about their own productivity, anecdote isn't evidence, and a consultant waving a delivery-acceleration number should make you skeptical.

Two things keep the practice standing. First, the study's tooling was chat-and-autocomplete assistance inside the developer's own loop, not agentic orchestration with a gate layer that produces an objective verdict. The workflow this guide describes exists specifically to supply the ground truth those participants lacked: the gate either passes or it doesn't, independent of how fast anyone feels. This page is a small instance of it. It goes live only after the same deny-by-default validators that gate the rest of the spine return green, and that verdict is reproducible by anyone who runs them. Second, and this is the part a credible practice must not hide, deterministic does not mean comprehensive. A formal-verification study, "Broken by Default," found that more than half of AI-generated code artifacts carried a provable vulnerability and that conventional scanners missed the overwhelming majority of those formally-proven findings. Gates catch the failure classes they were built to catch and nothing else.

So the honest claim isn't "gates catch everything." It is narrower and more defensible: build the gate architecture, publish its specification, and stamp every artifact with provenance, so that failures are attributable and the practice improves under measurement instead of under marketing. That is the bar. The enterprise data suggests few organizations clear it; Deloitte's 2026 State of AI in the Enterprise found that only about one in five organizations pursuing agentic AI reported mature governance for it. The governance layer is the rare part, which is exactly why it is the part worth demonstrating.

How do teams adopt production agentic delivery?

In sequence, starting from wherever trust currently sits.

The usual entry point is advisory: a focused session that maps the current workflow, the failure modes already showing up, and the gates worth building first. From there the work moves into implementation, where the enforcement layer gets built into the actual codebase, and into workshops that put a team inside a working agentic session on their own code. I scope each of these as a consultation, workshop, or implementation engagement with concrete deliverables and handoff documentation.

Adoption is mostly a trust problem, not a tooling problem. The engineers hardest to convince are usually the ones who already tried an earlier tool and wrote it off; naming what's structurally different and putting them inside one good session flips them faster than persuading someone with no opinion. The payoff shows up where people don't expect it, like onboarding engineers to unfamiliar codebases in their first sprint instead of the usual months. I once walked more than 400 people through this in a single 90-minute session, and reach like that is the easy part. The part that holds is the same in every rollout: the teams that stick with it standardize the outcome and let the gate, not the human, enforce it.

If you want the deeper treatment of how the enforcement architecture is built, the white paper covers the full model, and the economics of running this at scale are in the piece on the true cost of an AI coding tool. The shortest version of the whole argument: demonstrated, gated, and provenanced beats credentialed and promised, and the way to prove that is to publish the receipts.