Ty Barho
←Blog

Contract-Driven Development: An Armchair Manifesto

5 min readJan 30, 2026

I. The Problem

We've been staring at the wrong thing.

For decades, software development has been about code. Write it. Review it. Test it. Refactor it. Debate it in pull requests. Argue about tabs vs spaces.

Meanwhile, the actual question—does this thing deliver value?—gets answered months later. Maybe never.

We trust code. We should trust outcomes.

II. The Inversion

Imagine Maslow's hierarchy, but upside down.

At the top: Value. Does it make money? Does it scale? Does it matter?

At the bottom: Resources. Servers. Databases. Pods. The metal.

In between: layers of abstraction. Each layer depends on the one below it. Each layer makes promises to the one above it.

These promises are contracts.

III. The Hierarchy

Layer 5: Value

  • Is it profitable?
  • Is it scalable?
  • Is it sustainable?
  • Does it matter?

Layer 4: Capability

  • Can users do the thing?
  • Can they pay?
  • Can they leave with their data?

Layer 3: Behavior

  • When X happens, does Y follow?
  • Is it fast enough?
  • Does it break?

Layer 2: Components

  • Are the services alive?
  • Do they talk to each other?
  • Do they keep their promises?

Layer 1: Resources

  • Is the server running?
  • Is the database reachable?
  • Is DNS resolving?

IV. The Contract

A contract is not a test.

A test asks: "Does this code work?"

A contract asks: "What does 'work' mean at this level of abstraction?"

Tests verify implementation. Contracts define reality.

V. The Cascade

Trust flows upward.

If Layer 1 contracts pass → trust the infrastructure. If Layer 2 contracts pass → trust the components. If Layer 3 contracts pass → trust the behavior. If Layer 4 contracts pass → trust the capabilities. If Layer 5 contracts pass → trust the value.

If all layers pass, you've proven the system delivers value.

Without reading a single line of implementation code.

VI. The Two Kinds of Truth

Some contracts are facts. Code can check them.

  • revenue > costs
  • latency.p99 < 200ms
  • healthCheck(endpoint) === true

Some contracts are vibes. Only humans can judge them.

  • "Is this intuitive?"
  • "Does this feel trustworthy?"
  • "Is this copy compelling?"

For decades, vibes couldn't be contracted. They stayed in the realm of opinions, design reviews, gut feelings.

Not anymore.

VII. LLM-as-Judge

An LLM can judge vibes. And return a boolean.

"Is this UI intuitive?" → yes/no "Does this copy build trust?" → yes/no "Is this experience delightful?" → yes/no

The judge is probabilistic, not deterministic. It has confidence, not certainty.

But it can be calibrated.

50 labeled examples. Run the judge. Measure accuracy. Tweak until 90%+.

A calibrated judge is good enough to ship on.

VIII. The Expanded Contract Space

Before LLMs: contracts could only encode what computers could measure.

After LLMs: contracts can encode what humans can judge.

Brand consistency. Emotional resonance. Ethical compliance. Accessibility. Tone.

All contractable now.

The space of "things you can formally verify" just exploded.

IX. The Implication

If contracts define reality, and all contracts pass, then reality is correct.

By definition.

Implementation becomes irrelevant.

  • Ralph writes it? Fine.
  • A human writes it? Fine.
  • GPT-7 writes it? Fine.

Same contracts. Different shadows on the cave wall.

You don't review implementation. You validate contracts.

X. The Development Loop

Old way:

Idea → Code → Test → Deploy → Hope

CDD:

Value Contract → Capability Contract → Behavior Contract → Component Contract → Resource Contract
                                                                                        ↓
                                                                              Implementation
                                                                                   (whatever)
                                                                                        ↓
                                                                              Validate Cascade
                                                                                        ↓
                                                                                All pass? Ship.

You iterate on contracts, not code.

If value isn't being delivered, you don't debug implementation. You ask: which layer's contract is failing? Fix that contract. Regenerate implementation.

XI. The Axioms

At the foundation, you need things you trust without proof.

  • Network reachability implies existence.
  • Arithmetic is valid.
  • Money in the bank is real.
  • Retention correlates with value.

CDD doesn't eliminate trust. It makes trust explicit.

Name your axioms. Derive everything else.

XII. The Promise

If you adopt CDD:

  1. No more code review. Contracts are the review.
  2. No more implementation debates. If it passes, it's correct.
  3. No more "does it work?" anxiety. The cascade answers that.
  4. No more hoping value gets delivered. Value is contracted.

The implementation becomes disposable. Generate it. Throw it away. Generate again.

The contracts are the product.

XIII. The Risk

LLM judges can be wrong.

Deterministic checks can have bugs.

Contracts can be poorly specified.

CDD doesn't guarantee correctness. It guarantees explicitness.

When something fails, you know exactly where. Which layer. Which contract. Which field.

That's worth everything.

XIV. The Bet

We bet that:

  1. Outcomes can be contracted.
  2. Contracts can be validated.
  3. Validation can be trusted.
  4. Implementation can be ignored.

If true, we've just made 90% of software development—the implementation part—a commodity.

The remaining 10%? Defining what "value" means.

That's the hard part.

That's the human part.

That's the only part that matters.

Contracts are the product. Implementation is a shadow.