Phase 1
Frame the domain
In prose — before any code.
-
01
Determine the domain
Name exactly what you are building, and its purpose and scope.
-
02
Analyze the domain
Map the core concepts, entities and invariants the system turns on.
-
03
Determine the architecture
Decide the system's shape and record each decision with its rationale.
-
04
Plan incremental stages
Break the build into stages that each run and are proven before the next.
A simple domain document
Your domain, framed in prose — in any format.
Phase 2
Scaffold the project
Turn the thinking into a book.
-
05
Scaffold the first chapters
With the Literate Programming discipline, write the opening chapters:
- · The project domain
- · General domain analysis
- · Architecture
- · Development stages
-
06
Generate the first document
Weave the sources into a real book — the single source of truth.
The first woven book
Your design, woven into one readable document.
Phase 3 · write the book
Chapter by chapter
Write it, review it, move on.
-
07
Write the chapter
Draft the stage as prose, then derive its code and tests — through every substage.
-
08
Review, then advance
Read it back for gaps and close them — no technical debt — then begin the next chapter.
The complete literate code
The full literate source — book and code, growing together.
An example of the above
A Sophisticated Audio Editor — a non-destructive, modular, verifiable audio engine, built with Literate Driven Development (LDD). Here is what each phase actually produced.
From Phase 1
The domain document
The audio editor's domain, framed in prose — a single Markdown file.
From Phase 2
The first woven book
The design chapters, woven into the first document — and the source at that commit.
From Phase 3
The complete literate code
The full book, and the repository as it grows stage by stage.
For the author
Notes for writing in LDD.
Practical advice to make the method your own — the mindset, the tool, and the habits that keep prose and code moving together.
Remember: you and the AI are co-authors
Writing in LDD is like writing a book: you and the AI write it together, as co-authors. Writing is a continuous dialog between you and the AI model.
Literate programming is a different way to code
It is its own paradigm — getting familiar with its basic concepts is worth it, and it will help you get the most out of LDD.
This LDD workflow is a proposal, simple but effective
This workflow is deliberately simple, and it is not the definitive one — it is a proposal. Adapt it to your own style, just as there are as many ways to write as there are authors.
Proven in practice
This is the workflow used to build the kcc compiler and the advanced audio editor shown here.
Try pure LDD
This is pure LDD — no spec-driven development, no harness engineering, no agentic loops. You may add them, but none are indispensable.
You understand the code from day one
At every moment the author knows and understands the code that is generated — from day one, and from the first line of code.
One simple command: weft
LDD runs on weft, a single, simple command that interprets the weft metalanguage — binding one formatting language (LaTeX, HTML or Markdown) with one or more programming languages at once.
Two outputs, one source
.weft files are organized around mental concepts, in a metalanguage designed to be at once explained to humans and understood by computers. Weave the .weft files and you get a PDF read and rendered as a book; tangle them and you get the source code the compilers build — both from the same file.
A concept crosses every layer and language
A single .weft concept can hold as many pieces of different programming languages as your project needs. A login, for instance, is transversal to many systems, subsystems and languages: login.weft can gather fragments of Go, Bash, SQL, TypeScript, JavaScript, HTML, Terraform and Python, external API calls in REST and GraphQL — with their tests — all in one file: login, expressed conceptually. Any improvement to login means reading a single file; it doesn't touch other concepts, or only tangentially, so things don't break elsewhere.
Software is evolutionary
Software evolves. LDD lets you build incrementally, to the needs of the day. Everything is built on what came before — which is what makes it fast, cheap and safe to ship.
Change the code, update the prose
Any change to a code fragment must update the prose. The prose says the why and the what; the code, the how. That pairing is what stays valuable — today and in the future — for the programmers and the AIs who inherit the project.
Every pass can enrich the prose
Each review is also a chance to improve the prose. With LaTeX you can enrich it with complex equations, tables, cross-references, diagrams and the full typographic richness of publishing — all to explain your code better.
Every step forward, you understand the code, you watch your project evolve on solid ground, and you turn it into a work of art. No friction, fast, and with great token savings. Enjoy.