What You Write Is What It Did: A Legible Pattern for Structuring Software

Write a reverent but whimsical response to What You See Is What It Does: A Structural Pattern for Legible Software
(by Eagon Meng and Daniel Jackson) that centers on data artifacts instead of Concepts.

ChatGPT Prompt

A reverent bow. A knowing grin. And now: a little gentle mischief.

Their work is bold, elegant, and beautifully idealistic—an attempt to reorder the very structure of software so that both humans and LLMs can finally understand what on earth is going on. This post is a friendly counter‑proposal: equally admiring, slightly cheeky, and aimed at something a bit more immediately buildable.


1. Why WYSIWID Matters (And Why We Love It)

Meng & Jackson begin with a simple but devastating observation:

Most software offers no faithful link between what’s written and what it actually does.

Systems evolve into patchworks, features sprawl across modules, and behavior emerges from a haze of implicit coupling. LLMs, which need clarity and boundaries even more than humans, are not amused.

Their proposed cure is the WYSIWID pattern
What You See Is What It Does.

And at the heart of WYSIWID is the structural quartet we call CAPS:


2. CAPS: Concepts, Actions, Synchronizations, Provenance

2.1 Concepts

Self-contained semantic “units of meaning.”
Each Concept wraps its own state, its own logic, and its own purpose. A Concept is a sovereign little kingdom with one responsibility and exactly the verbs it needs.

Beautiful. Clean. Slightly microservice‑y (more on that later).

2.2 Actions

Each Concept defines its own permitted verbs.
To interact with a Concept, you invoke one of its Actions. No peeking into its internal state, no side-door meddling, no secret backchannels.

This gives WYSIWID a satisfying crispness—behavior is explicit, finite, and visible.

2.3 Synchronizations

This is the magic.
A Synchronization is a declarative rule saying:

“When Action X happens in Concept A, perform Action Y in Concept B.”

They’re tidy, readable, and theoretically LLM‑generable.
They also allow concepts to remain blissfully ignorant of one another.

2.4 Provenance

Every Action, every Synchronization firing, every event is logged.
The system tells its own story.
Debugging becomes archaeology with excellent field notes.


3. Where WYSIWID Shines

WYSIWID is a triumph of semantic legibility:

  • Features gather into neat conceptual boxes.
  • Behavior is declared rather than implied.
  • Coupling becomes explicit and inspectable.
  • Provenance makes runtime behavior transparent.
  • LLMs get clean boundaries, clear verbs, and well-defined intentions.

It’s everything software architecture students dream about when they’re young and haven’t yet seen production.


4. The WYSIWID Reality Check

We adore the vision. Truly.
But when you try to build WYSIWID with today’s tools, the joints start creaking.

Here are the creaks:

4.1 Concepts Become Microservices

In practice, a Concept is a little state machine with bespoke verbs.
Do you deploy them separately?
Bundle them?
Run them as modules?

Whatever the choice, the system becomes microservice‑shaped—lots of boundaries, lots of coordination, lots of overhead.

4.2 Actions Accumulate Like Pokémon

Every Concept invents its own verbs.
These verbs multiply.
Naming becomes theology.
LLMs struggle to know which verb is correct.
Humans do too.

4.3 Synchronizations Grow Tentacles

One rule is fine.
Three rules are manageable.
Twenty interacting rules with conditions and error handling?
Suddenly you’re debugging distributed workflows with semantic causality, and the elegance begins to wobble.

4.4 Provenance Isn’t Free

Logging every semantic step is delightfully informative and annoyingly expensive.
High-throughput systems would drown in their own diaries.

4.5 No Concrete Runtime

The paper proposes a semantic ideal, not a production reference architecture.
Bridging that gap requires building a whole new runtime model.

So yes: WYSIWID is brilliant, but it is also aspirational.


5. WYWIWID: A Friendlier Pattern for the Present

Enter our modest counter‑proposal, with a grin:

WYWIWID — What You Write Is What It Did

Same dream of legibility.
Different path.
Less semantic ambition, more practical reproducibility.

WYWIWID rests on an architecture we affectionately call WASP:


6. WASP: Workers, Artifacts, Specifications, Provenance

6.1 Workers (Deterministic)

Stateless little engines of pure behavior.
A Worker takes input, produces output, and leaves no trace.
You can run it anywhere.
You can run it twice and get the same result (usually).
LLMs love generating code like this.

6.2 Artifacts (Versioned)

Every output becomes an Artifact—immutable, content-addressed, eternal.
Artifacts are the “did” in What It Did.

Unlike WYSIWID’s internal Concept state, Artifacts are visible and traceable.

6.3 Specifications (Declarative)

Where WYSIWID has Synchronizations, WYWIWID has Specs:

  • simple
  • declarative
  • ordered or DAG-shaped
  • easy to diff
  • easy for LLMs to generate

Specs tell the system what should run, not how to run it.

6.4 Provenance (Full and Boring)

Every Worker run logs:

  • inputs
  • outputs
  • code version
  • environment

This is provenance that speaks the language of data science and build systems.


7. WYWIWID’s Inversions of WYSIWID

7.1 Statelessness over Semantic State

WYSIWID uses semantic state machines.
WYWIWID uses immutable artifacts.
One is conceptually rich.
The other is operationally simple.

7.2 Ground Truth in What Happened

WYSIWID makes behavior inspectable via structure.
WYWIWID makes behavior inspectable via history.

You don’t infer truth—you log it.

7.3 Fewer Verbs, More Stability

WYSIWID: potentially dozens of domain-specific Actions.
WYWIWID: the system really only does three things:

  • write an artifact
  • run a worker
  • log the result

The AI surface area is tiny.

7.4 Friendly to Modern Infrastructure

WASP can be built with:

  • serverless workers
  • blob storage
  • workflow engines
  • append-only logs

No bespoke runtime required.

7.5 Deeply Compatible with LLM Programming

LLMs excel at:

  • writing pure functions
  • modifying declarative specs
  • analyzing provenance logs

WYWIWID turns the whole system into these three artifacts.


8. A Respectful Comparison

WYSIWID:

A visionary semantic blueprint for the future of legible codebases.
It’s inspiring, brave, and intellectually delightful.

WYWIWID:

A pattern you can build today using cloud primitives and existing tooling.
It gives you legibility through reproducibility instead of semantics.

Both are reaching for the same star:
software that humans and machines can truly understand.

WYSIWID reaches through meaning.
WYWIWID reaches through evidence.

And perhaps one day, the two shall meet.


9. Final Bow

To Meng & Jackson: thank you for the spark.
To the rest of us: may our software become ever more legible, whether by what we see or by what we write—and always by what it did.

Leave a comment

Blog at WordPress.com.

Up ↑