Semantic Transpilation
Intent → LLM → Artifact
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.
From a sufficiently specific set of documentation (pages), data (tables), and intent (issues/todos), you can construct a complete program. The LLM reads the specification and implements it. The code is just a compiled 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:
- Write pages — Describe what you want in prose. Include context, goals, constraints, examples of what "good" looks like.
- Create tables — Structure any data that matters. Routes, fields, user types, pricing tiers — anything with rows and columns.
- List issues — Break down into discrete tasks with dependencies. What must happen first? What blocks what?
- 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.
| Input Quality | Output Quality | Example |
|---|---|---|
| Vague | Random | "Make me a website" → generic template |
| Moderate | Reasonable | "Make a landing page for a medical practice with blue theme" → decent but generic |
| Specific | Deterministic | "Create a landing page with two visual pathways: Upper Extremity ATX in blue, Regen ATX in green. Hero section, about, services grid, contact form. Deploy to Cloudflare Pages." → exactly what you described |
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 180,000 lines of Go with 3-5 second response times.
TD is the same concept transpiled into something better: under 1,000 lines of Bash + SQLite, instant response. Same abstraction. 200x smaller.
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.
An incantation is a sufficiently specific utterance that reliably produces an artifact. The specificity constrains the LLM's non-determinism. The output becomes effectively deterministic. A bad incantation — "make me a website" — is too vague; the probability distribution doesn't collapse. A good incantation describes exactly what should exist.