Skip to content
Skip to content
Johannes Rabauer LogoJohannes RabauerAgentic Methods
All methods
WorkflowMaturity: Emerging

Eichhorst Principle

Treat the LLM as a noisy channel inside a Software Factory with hard quality gates.

2 min read

What it is

The Eichhorst Principle applies Claude Shannon's noisy-channel idea to AI coding and extends it into Software Factory thinking. The large language model is the noisy channel. It can guess right, drift, or fail. Reliability comes from the factory around that channel: explicit intent, clear constraints, and hard quality gates.

In practice, the loop is not just generate, compile, and test. It starts one step earlier: specify what success means. Then generate code, run compile and test checks, evaluate failures, and iterate. Each gate catches a different error class. The compiler catches syntax and wiring errors. Tests and acceptance checks catch logic and behavior errors.

Why it matters

The key rule is blunt: the loop can only fix what it can detect. That means better specifications, acceptance criteria, and tests usually matter more than better prompts. A strong quality-gate stack turns an unreliable generator into a much more reliable coding partner.

This makes the Eichhorst Principle a useful lens for agentic development. If the agent keeps breaking the same kind of behavior, the first question is not "how do I rewrite the prompt?" It is "what specification or check is missing from the factory?"

Software Factory integration

The principle is best understood as a delivery-system concept, not just a debugging loop.

In Shannon terms, you improve reliability at three places:

  • Source: clarify feature intent and contracts.
  • Channel: reduce ambiguity in prompts and context.
  • Receiver: enforce compile, test, and policy gates.

That is exactly what a Software Factory does. It encodes quality in the system so weak output gets rejected automatically and only trustworthy changes survive.

If you want to see this applied in a real live session, see the blog recap: Stop Prompting. Start Building Software Factories for Java.

Visual model

Source note

The clearest public write-up comes from Ralf D. Muller's blog post and LinkedIn post, both of which attribute the principle to Ingo Eichhorst. The two podcast links above also discuss the idea, but the source-backed wording here stays anchored to the accessible text sources.

1

Specify

Define intent, constraints, and acceptance criteria first.

2

Generate

The LLM produces code through a noisy channel.

3

Evaluate

Compile, test, lint, and check contracts through quality gates.

4

Correct

Feed failures back into the next pass until all gates are green.

Iterate — feed learnings back into the next cycle
A Software Factory turns noisy generation into reliable delivery.

Pros

  • Gives a clear theory for why Software Factory loops beat one-shot prompting.
  • Shifts focus from prompt cleverness to measurable quality signals.
  • Makes acceptance criteria and tests first-class design artifacts.
  • Fits existing compile, unit-test, integration-test, and CI/CD pipelines.

Cons

  • Needs real specifications and tests; unmeasured behavior still slips through.
  • Adds token cost and time because generation and evaluation repeat.
  • Green gates do not automatically guarantee good architecture.
  • Weak gates create a false sense of reliability at scale.

Where to use

Best for

  • Agentic coding workflows with explicit specs and hard quality gates.
  • Teams debating why AI works well in one repo and fails in another.
  • Codebases where acceptance criteria and tests can improve over time.
  • Leadership conversations about why test investment matters in the AI era.

Avoid when

  • Fast prototypes where no automated feedback or spec baseline exists yet.
  • Tasks that cannot be checked by compilers, tests, or other hard signals.
  • Situations where token cost is the main constraint.

Sources