The AI Coherence Problem — and Why We Built a Compiler Instead of a Generator

The Coherence Problem Nobody Is Naming

Every team building with AI agents in 2026 has met the same failure, usually without naming it. Ask an AI system to build software and it produces something plausible. Ask it again and it produces something different. Chain multiple agents together and each one holds a slightly different picture of what the system is building — different assumptions about the domain, the entities, the architecture. The output isn't wrong in any single place. It's incoherent as a whole.

We call this the AI coherence problem: large language models are locally fluent and globally inconsistent. They generate each fragment convincingly, but nothing forces the fragments to agree — with each other, with the design, or with the output of the previous run.

This is not a prompt-quality problem, and it doesn't go away with better models. It's structural. A probabilistic system with no shared source of truth will drift, because there is nothing for it to cohere *to*.

Where Incoherence Actually Comes From

We know this failure mode intimately because we spent months instrumenting it in our own pipeline. Three patterns account for most of it:

Parallel interpretations. Any non-trivial AI system has multiple components that each need to understand the task — a prompt normalizer, a template matcher, a domain classifier, a code emitter. If each component derives its own interpretation from the raw input, you don't have one understanding of the project; you have five, and they disagree in ways that only surface downstream as bugs. We traced one misclassification through five separate components, each holding its own private notion of what "domain" meant. The bug wasn't in any of them. The bug was that there were five.

Phantom structure. Language models are reification machines: show them a noun and they'll build infrastructure for it. We watched grammatical filler in a narrative prompt get promoted into database entities with full CRUD routes — syntactically perfect code for things that don't exist. Fluency without an existence check.

Run-to-run drift. The same input producing different output isn't creativity; in an engineering tool it's a defect. If you can't diff two runs, you can't review, can't cache, can't trust regeneration on a codebase you've already shipped.

How We Solved It: Coherence by Construction

Our position from day one has been that CodeFlow Lab is a compiler, not a generator — and the coherence problem is precisely why that distinction is load-bearing. A compiler doesn't ask its passes to independently guess what the program means. It builds one intermediate representation and forces every stage to consume it. Correct architecture makes entire classes of failure structurally impossible; we apply that standard to AI systems, not just the code they emit.

Concretely, four mechanisms:

One source of truth, zero private copies. Every component in our 17-agent orchestration reads from a single shared representation of the project — its domain, entities, design tokens, components. Components don't classify; they emit *evidence*, and one deterministic resolver produces the single interpretation everything downstream consumes. Drift between components is not detected and corrected. It has nowhere to live.

An existence gate before structure. Nothing becomes an entity in our intermediate representation without passing identity criteria: does it have properties, a lifecycle, a way to tell two instances apart? A noun phrase is evidence of an entity, not an entity. Phantom structure fails at the gate, deterministically, before a single line of code is generated.

Declared operations, not improvised ones. The system maintains a registry of legal operations on each entity, and code emission is constrained to that registry — a route or handler that doesn't trace to a declared operation is a build error, caught by static analysis, not a runtime surprise. The LLM can propose; only the deterministic layer can authorize.

Determinism as a test suite, not a slogan. LLM calls are bounded to specific pipeline stages. IR construction, hashing, structural deduplication, and validation are deterministic — same input, byte-identical output, enforced by tests that run on every change. Regeneration is diffable. Coherence across runs is a property we assert in CI, not a behavior we hope for.

What This Looks Like in Practice

Our reference build: a Dynamics 365-scale interface compiled to 76 files and 51 components — zero hand-edits, zero TypeScript errors. Not because a model was prompted carefully, but because incoherent output is unrepresentable in the pipeline that produced it. Every component traces to the same IR; every route traces to a declared operation; running it again produces the same artifact.

That is the practical answer to the coherence problem. Automation in software development doesn't fail because models can't write code — they demonstrably can. It fails because nothing holds a thousand locally-plausible decisions together. The fix isn't a smarter generator. It's an architecture where agreement is enforced by construction: shared representation, gated structure, declared operations, deterministic assembly.

Fluency is what LLMs give you. Coherence is what engineering has to add.

*CodeFlow Lab compiles Figma designs and natural-language specifications into production React, Vue, and Flutter code through a deterministic, IR-first pipeline. See the full D365 build at [Video Demos - CodeFlow](https://code-flow-lab.com/demos)*