Design is Code (DisC)
A methodology where design generates tests, and tests constrain AI-generated code.
In software, the real work is design. Code is the consequence.
DisC applies London-school TDD (Freeman & Pryce, 2009) to AI code generation. Mockist tests specify exact call structure, order, and arguments — leaving no room for AI interpretation. There is only one implementation that passes.
What you design is what you get.
The Problem
AI code generation has two root causes of failure:
- Natural language is ambiguous. Natural language is built for human communication, where ambiguity is tolerable. As a code specification, it's a liability. The AI interprets rather than executes — same prompt, different code, every time. There's no contract. There's no determinism.
- Cost is asymmetric. AI has no cost to generate, and no cost to be wrong. You have high cost to review, and high cost if you miss an error. That's not collaboration — that's exploitation.
Design is the Contract
Every generation of software engineering raised the abstraction level while preserving formal notation — machine code → assembly → structured programming → OOP. Each step made intent more expressible without sacrificing precision. Natural language breaks that contract. It's expressive, but not formal.
This is not a tooling problem. It's a specification problem.
If the specification is ambiguous, everything downstream inherits that ambiguity — the tests, the implementation, the architecture. You can't review your way out of a bad contract. You can only fix it at the source.
Design is the source.
A precise design artifact eliminates interpretation before code is written. This changes where human effort belongs. Peer collaboration, architectural debate, edge case reasoning — all of it should happen at design time, not in code review. Reviewing code that AI generated from an agreed design is spot-checking. Reviewing code that AI generated from a natural language prompt is archaeology.
DisC works with any design representation that meets this precision bar. UML sequence diagrams are the current supported format.
How It Works
The key mechanism:
- Tests are generated from the design
- The implementation is driven by tests alone
- You get what you design, no code review needed
Design Artifact (UML Sequence Diagram, etc.)
|
v
Phase 1: Design → Tests
|
v
Phase 2: Tests → Implementation (Implementation is driven by tests not the design)
|
v
Working Code (Reviewed designs don't need code review)
Participants
Every participant in a design is either an orchestrator or a leaf.
An orchestrator has dependencies and coordinates them. Orchestrators are verified by mockist tests — every call becomes a test, every argument is pinned, every order is fixed. AI generation risk is low because the tests fully constrain the structure.
A leaf has no outgoing calls. Because leaves cannot be verified by interaction tests, DisC classifies each one by what kind of work it does, and tests it accordingly:
- Pure function — output depends only on inputs. Tested by decision table: humans design the test cases (input → expected output), AI implements only. AI must not invent both cases and implementation — that creates false positives where tests pass but logic is wrong. When a decision table is authored ahead of time as
design/<Participant>.decision.md, DisC consumes it directly and generates filled tests; otherwise DisC emits a skeleton for humans to fill in.
- Side effect — touches external systems (DB, network, clock, queue). Mocked in consumer tests; correctness verified via integration tests, not DisC.
- Factory — name ends in
Factory. Assumed to be pass-through packaging into a constructor. No standalone test; correctness is transitive through the consumer.
Scope and Limitations
DisC constrains interaction structure — how components collaborate. It does not constrain non-functional properties: performance, readability, or error handling style.
Algorithmic code — ML pipelines, trading algorithms, game engines — falls outside the methodology entirely.
Who Does the Design?
| What | Who | Why |
|---|
| Component interactions (UML arrows) | Developers | Architecture decisions require engineering judgment |
| Pure function test cases (decision tables) | Product team | Business rules require domain knowledge |
| Implementation | AI | Mechanical — forced by the tests |
Supported Languages
Currently supports Java with UML sequence diagrams (PlantUML format). Support for additional languages and design formats is planned.
Quick Start
- Clone this repo: https://github.com/mossgreen/design-is-code-demo, it's a Java Spring Boot project with simple UML sequence diagram examples.
- Run
/disc 01_hello-world.puml in Claude Code session
- it requires Java 17.