Generative AI

MCAF: the method we use to ship AI-generated code to production

MCAF is the framework we developed to make AI-generated code trustworthy enough to ship to production, and its foundation is a single rule: the agent may not guess. That rule sounds small and it is the whole thing. The characteristic failure of AI coding is confident invention, the model produces plausible code based on an assumption it never checked, a method it believes exists, an API shape it half-remembers, a requirement it interpreted rather than confirmed, and the output looks right and is wrong. MCAF removes the guessing by forcing verification: where the agent would infer, it must instead check against a real source or stop and say it does not know. Around that rule sit the supporting mechanics, explicit conventions the agent reads, layered deterministic checks, and quality gates that block rather than warn. This explains the method and why the one rule carries most of the weight.

To be clear about what this is: MCAF is our internal framework, not an industry standard or a product you can buy. We are describing how we work, and the principles generalize, but the name is ours.

The rule: the agent may not guess

Start with why guessing is the core problem. A language model, asked to write code, will always produce something, that is what it does, and when it lacks a fact it needs, it fills the gap with the most plausible completion rather than admitting the gap. That is the mechanism behind most AI coding failures: not that the model is stupid, but that it is built to continue plausibly, and plausible is not the same as correct. A guessed method name, a guessed config key, a guessed assumption about how a function behaves, each produces code that compiles and fails in a way nobody catches until later.

MCAF's answer is to make guessing structurally unavailable. When the agent needs a fact, does this method exist, what does this function return, what is the actual requirement, it must resolve it against a real source: read the code, run the test, check the documentation, or ask, rather than infer. If it cannot resolve it, it stops and surfaces the uncertainty instead of papering over it. This is the same principle we describe in how AI agents write production code: an agent that says "I need to check" or "I am not sure about X" is far more valuable than one that confidently produces wrong code, because the first is correctable and the second is a latent defect. Removing the guess is what makes everything downstream trustworthy.

The mechanics around the rule

A rule needs machinery to be enforceable, and MCAF's machinery is deliberately unglamorous. Three parts:

  • Explicit conventions the agent reads. The agent should not guess how this codebase does things, so the conventions are written down where it reads them, most concretely in an AGENTS.md that encodes build commands, architecture rules, patterns, and constraints. This turns "the agent assumed our conventions" into "the agent read our conventions," the instruction layer we cover in what goes in an agent harness.
  • Layered deterministic checks. Tests, linters, type checks, analyzers, and security scanners run on the agent's output, each catching a class of error objectively, without sharing the agent's assumptions. These are the checks the agent's work must survive, not the agent's own judgment of its work.
  • Quality gates that block. The checks decide what ships. Code that fails a gate does not merge, full stop. A gate that only warns is a gate the pressure of a deadline will push code past, so the gates are enforcing, not advisory.

Together these make the no-guessing rule real rather than aspirational. The conventions remove the need to guess about the codebase, the deterministic checks catch what slips through, and the blocking gates ensure the checks actually govern what ships. None of it depends on the model behaving well; it holds regardless.

Why this is mostly harness, not model

An important thing to understand about MCAF is where the reliability comes from, and it is not from a better model. Almost everything MCAF does is engineering around the model, the conventions, the checks, the gates, the verification, which is what the field now calls harness engineering, the discipline we cover in harness engineering vs loop engineering. MCAF is, in those terms, largely a harness with a strong verification discipline at its center.

That placement is deliberate and it is the differentiator. A team relying on the model to be careful is depending on a property the model does not reliably have. A team relying on a harness that forbids guessing and verifies everything is depending on deterministic engineering it controls, which holds across model versions and does not degrade under deadline pressure. This is why we treat MCAF as infrastructure rather than a prompt-engineering trick: the value is in the enforced structure, not in coaxing better behavior out of the model. It is also why the approach shows up in our open-source work, the same verification-first thinking runs through the libraries we publish.

What MCAF changes in practice

The practical effect is a different relationship with AI-generated code. Without a framework like this, AI coding produces output fast and shifts the cost to review: someone has to read everything carefully because any line might contain a confident error, which is the hidden expense behind the felt-fast-actually-slow pattern in the cost of over-automation. With MCAF, the output arrives already having survived verification, and the uncertainties are surfaced rather than buried, so review focuses on judgment (is this the right approach) rather than on hunting for invented facts.

That is what makes AI-generated code shippable at an agency standard: not that the model is trusted, but that its output has passed through a structure that does not trust it. The client gets code that was verified before it arrived, and the failure mode of confident invention, the one that makes teams wary of AI-generated code in production, is designed out rather than caught late. The method is the product, in the sense that it is why the AI-assisted work holds up.

The takeaway

MCAF is our framework for shipping AI-generated code to production, built on one rule, the agent may not guess, supported by explicit conventions the agent reads, layered deterministic checks, and quality gates that block rather than warn. The rule matters because confident invention is the characteristic AI coding failure, and forcing verification against real sources (or an honest stop) removes it. Almost all of MCAF is harness engineering, deterministic structure around the model rather than reliance on the model's good behavior, which is what makes it hold across model versions and under deadline pressure. It is our method, not a product, and it is why we are willing to put AI-assisted code in front of clients' users: the output arrives already verified, with uncertainty surfaced rather than buried.

If you want AI-generated code that ships through a verification discipline instead of into your technical debt, that is where our AI Dev Team work starts, and the same thinking runs through our open-source libraries.

FAQ

What is MCAF? It is our internal framework for making AI-generated code safe to ship to production, built on the rule that the agent may not guess, supported by explicit conventions the agent reads, layered deterministic checks, and blocking quality gates. It is a method and a way of working, not a product you can buy or an industry standard.

What does "the agent may not guess" mean? That when the agent needs a fact it is unsure of, does this method exist, what does this function return, what is the actual requirement, it must verify against a real source (the code, the tests, the docs) or stop and surface the uncertainty, rather than filling the gap with a plausible-looking assumption. It removes confident invention, the main AI coding failure.

How is MCAF different from just using an AI coding tool? A tool produces code fast and leaves you to catch its errors in review. MCAF puts enforced structure around the tool, conventions the agent reads, deterministic checks its output must survive, and gates that block failing code, so the output arrives already verified and uncertainties are surfaced rather than buried in plausible-looking code.

Is MCAF about a better AI model? No. Almost all of MCAF is engineering around the model (conventions, checks, gates, verification), which is what the field calls harness engineering. The reliability comes from deterministic structure the team controls, not from the model behaving well, which is why it holds across model versions and under deadline pressure.

Can I apply MCAF principles myself? The principles generalize even though the framework is ours: forbid guessing by forcing verification against real sources, write your conventions where the agent reads them, run layered deterministic checks on AI output, and make your quality gates block rather than warn. The name is ours; the discipline is available to any team willing to enforce it.

“You can’t monetize pain. You can only monetize value. The moment users feel cared for, they’ll see paying as an investment in themselves — not a cost.”

You know what you want to build. Let's go ship it.

Book a 15-min call
Book a 15-min call
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.