What if we stopped trusting code and started trusting outcomes? A practical framework for software development where contracts define reality and implementation becomes irrelevant.

Contract Driven Development


### 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.*


What if we stopped trusting code and started trusting outcomes? A philosophical framework for software development where contracts define reality and implementation becomes irrelevant.

testing.