Semantic Transpilation

The Concept

Traditional transpilation: Source code → Transpiler → Target code. TypeScript becomes JavaScript. Sass becomes CSS. One formal language translates to another.

Semantic transpilation: Structured intent → LLM → Working artifact.

The key insight: enough context collapses the probability distribution.

An LLM is non-deterministic. But as you add specificity — documentation, data, examples, constraints — the space of valid outputs shrinks. At sufficient specificity, the output becomes effectively deterministic. You don't need to write code. You need to write a sufficiently specific description of what you want. The LLM compiles your intent into the artifact.

The Primitives

Two fundamental shapes human intent takes when written down:

Page

Unstructured text. Docs. Markdown. Stream of thought. No schema. This is how humans naturally express ideas, goals, context, and reasoning.

Table

Structured data. Rows and columns. Explicit schema. This is how humans naturally express collections, comparisons, and categorized information.

Everything else is a projection of these two:

• Issues/Todos — Structured intent with dependencies (a specialized table)
• Decks — Pages restructured for temporal delivery (slides)
• Programs — Pages + tables transpiled into executable form

This is why Word/Excel, Docs/Sheets, Pages/Tables keep recurring as the fundamental duo throughout computing history. They are the primitives.

The Stack

Each layer increases structure. Voice is maximally fluid. Pages add permanence. Tables add schema. Issues add sequence and dependency. The LLM accepts all of this as input context and produces the artifact.

Practical Application

When you want an LLM to build something:

1. Write pages — Describe what you want in prose. Include context, goals, constraints, examples of what "good" looks like.
2. Create tables — Structure any data that matters. Routes, fields, user types, pricing tiers — anything with rows and columns.
3. List issues — Break down into discrete tasks with dependencies. What must happen first? What blocks what?
4. Transpile — Point the LLM at the docs: "Read this and implement." The more specific your input, the more deterministic the output.

The Quality Bound

The quality of the artifact is bounded by the quality of the input.

The constraint isn't technology. It's clarity of intent. If you can describe what you want precisely, you can have it.

Beads → TD: Transpilation Applied to Itself

Beads was the conceptual unlock: issues as linked beads, dependencies matter, order matters. It was a great project — 180,000 lines of Go with real architectural ambition. But it grew far heavier than the specific value I needed from it.

So I just made what I actually wanted. TD is the same concept transpiled into something better: under 1,000 lines of Bash + SQLite, instant response. Same abstraction. 200x smaller. Try it at tdtask.pages.dev.

The abstraction survived. The implementation was transpiled into something better. This is semantic transpilation applied to itself — the concept is the durable thing, the code is just the current rendering. And the act of making TD is itself an example of the ephemeral software pattern: I wanted it, so I caused it to get written, and it was easy.