The Missing Gate in the Software Factory

The factory moved upstream

A new wave of AI platforms has converged on an old industrial name: the software factory. Across their landing pages, the pattern is remarkably consistent. Business intent in. Governed, production-ready software out.

What's new is how far upstream they've moved. These platforms no longer accept a prompt and start writing code. They interview your stakeholders. They ingest your policies, read your architecture, and map your dependencies. They generate specifications and ask for approval before anything gets built. Then they enforce production-readiness gates: threat models, audit trails, dozens of checks mapped to real regulation.

This is real progress, and I want to be precise about the credit. The governance gap is real; regulated industries genuinely cannot ship what a coding agent emits on a Tuesday afternoon. Threat models and data-protection assessments prevent real harm; they are necessary downstream artifacts, not bureaucratic theater. And the factories have correctly identified that input quality is now the limiting factor. The more careful vendors even say so themselves. Read their shared-responsibility pages and you'll find it in writing: governance does not make the output correct, and judgment remains with the customer.

But moving upstream introduces a new temptation, for their customers more than for them: confusing a well-documented instruction with a well-founded product decision.

Grounded in which reality?

Watch what the factory grounds itself in, step by step.

The stakeholder interviews capture organizational reality: what your company believes it needs, expressed by the people the intake process could reach. The system ingestion captures technical reality: how your software actually works, which constraints a new build must respect. The specifications make those inputs executable, and the governance gates verify that what ships conforms to them.

Each step is genuinely grounded. None of the grounding touches user reality: whether the problem matters enough to solve, and whether this is the intervention that solves it.

You've supplied that organizational reality yourself. Someone asked what the users need, and you answered clearly, because clarity is what gets a project funded. Months later the feature shipped: governed, conformant, auditable, and unused. Every check verified the build against the approved intent. No check independently tested that intent against the people it was for.

That's not a flaw the factories are hiding; as noted, the honest ones state it outright. It's a boundary of the method. And it means the factory does not create product risk. It industrializes whatever product judgment it is given. Which makes an unexamined assumption more consequential, not less: the better the factory, the more efficiently one confident answer propagates into production. When the judgment is wrong, a governed factory ships the wrong product on schedule.

Extraction isn't judgment

Let me put the boundary more precisely. The intake model treats intent as a substance: it sits in stakeholders' heads and in existing systems, and with good enough extraction you can capture it, document it, and compile it. Extraction may even run continuously, but repetition does not turn extraction into judgment.

Stakeholder belief is still a hypothesis, however confidently documented. So is the roadmap it came from. Evidence doesn't rescue this by itself, either: twelve support tickets can establish that a problem is real without proving that the proposed feature is the right intervention. What separates a hypothesis from a judgment isn't the confidence of the person stating it or the thickness of the document capturing it. It's whether the claim has been put in a position where evidence could contradict it, and whether anyone would notice if it did.

A stakeholder intake interview cannot produce that on its own. It extracts answers; it doesn't test them. Judgment is the ongoing operation: a position formed against evidence and revised when the evidence moves, which it keeps doing long after intake ends.

The missing gate

The factories got one thing exactly right: readiness should be a gate, not a feeling. Before code ships, it must pass explicit, inspectable checks. Nobody argues the build should proceed on vibes.

The same standard should apply one step earlier. Before an idea earns the right to enter the factory, it should pass an intent-readiness gate: explicit checks on the product judgment itself, run before a specification is treated as buildable. Not checks for correctness; no gate can certify that you're right, and a gate that claims to is making the same promise it exists to question.

An intent-readiness system needs two layers. The first is a deterministic contract: is the objective specific, are the outcomes observable, is there a violable constraint, a defined failure mode, and a verification check someone could actually run? Pathmode applies that contract to every spec. We calibrated its semantic checks against 14 real specs and a labeled benchmark that now contains 98 valid and deliberately vague field examples, and I'll admit the work was humbling: it taught us how easily such a gate ends up measuring the format of a sentence instead of the quality of a judgment. That difficulty is precisely why it deserves its own discipline.

The second layer is judgment. Evidence anchors make the support behind individual claims inspectable, and the Spec Reviewer can surface claims that appear unsupported or contradicted. But neither a rule nor a model gets the final word. A machine can detect that evidence is absent; it cannot decide whether the available evidence deserves to carry the decision.

What the two layers deliver together is narrower than certainty and more valuable: assumptions stop traveling invisibly. Every claim in the spec is either backed, or marked. When it reaches the factory, the intake interview has something to check answers against.

Upstream, not against it

The honest tradeoff: judgment doesn't compile. Pathmode will not turn your intent into deployed infrastructure, and anchoring a spec to evidence is slower than sitting through an intake interview. What you get for the slowness is a case: a product decision that is inspectable, evidence-backed, and easier to falsify, which is everything a decision can honestly be before it meets users.

So this isn't an argument against the factories. If they win, and I suspect the pattern does, the pressure on the input only grows, and the input is where product risk increasingly concentrates. The factories built gates that protect production from a bad build. Someone has to build the gate that protects the factory from an unexamined decision.

Extraction isn't judgment. The factory can prompt you. Pathmode makes it harder for an unsupported answer to reach the factory.