I never expected my career as a software architect to collide with writing a xianxia novel. But 847 days and 2,000+ commits later, I've discovered that building software systems and building narrative worlds share more DNA than anyone admits.
This is the story of how Compiling the Dao became a laboratory for exploring what happens when you apply software engineering principles to creative writing—and the unexpected insights that emerged.
The Origin: A Bug Report on Traditional Xianxia
Xianxia (修仙) novels follow cultivators seeking immortality through spiritual power. It's a genre obsessed with progression systems, power hierarchies, and metaphysical rules that feel suspiciously like... software specifications.
The problem? Most xianxia stories suffer from what I'd call "architectural debt":
- Inconsistent power systems (like a codebase with three different logging frameworks)
- Deus ex machina plot holes (runtime exceptions that break narrative logic)
- Character inconsistencies (mutable state that shouldn't be mutable)
- World-building drift (schema migrations without backward compatibility)
Reading yet another novel where the protagonist's power level conveniently spiked for dramatic effect, I thought: What if I applied the same rigor to storytelling that I apply to system design?
Thus, Compiling the Dao was born—a novel where cultivation metaphors explicitly map to programming concepts, and narrative consistency is enforced like type safety.
The Architecture: Domain-Driven Design for Fiction
1. The Cultivation Type System
In traditional xianxia, a cultivator's "realm" (cultivation level) is vaguely defined. Is someone at "Golden Core" stage stronger than "Nascent Soul"? The answer changes based on plot needs.
I approached this differently. Every cultivation realm has a formal specification:
Realm: Foundation Establishment
Requirements:
- Spiritual energy capacity: 10,000+ units
- Elemental affinity: at least 1 primary element
- Mental stability: 90%+ (no demonic corruption)
Abilities Unlocked:
- Energy projection (100m range)
- Flying (requires tool assistance)
- Basic pill refinement (success rate: 60%)
Constraints:
- Cannot survive soul extraction
- Vulnerable to karma backlash (3x multiplier)
- Lifespan: 300-500 years
This reads like an API contract. And that's intentional. When a character advances to a new realm, readers can predict what they can and cannot do—no surprises, no power creep without cost.
What I learned: Constraints liberate creativity. By defining hard limits upfront, plot challenges become engineering puzzles rather than arbitrary obstacles.
2. Event Sourcing for Plot Threads
Traditional novels often have plot holes because authors forget what happened 50 chapters ago. I borrowed event sourcing from distributed systems.
Every significant event is logged in a canonical format:
Event: "Sect Tournament Finals"
Timestamp: Year 47, Month 3, Day 15
Participants: [Protagonist, Antagonist_A, Elder_Judge]
Outcome: Protagonist wins, but exposes forbidden technique
Consequences:
- Antagonist_A loses face → swears revenge (debuted in Chapter 89)
- Elder_Judge suspects demonic influence → triggers investigation arc
- Forbidden technique attracts rival sect attention → setup for Volume 3
When I write Chapter 89, I query this event store: What unresolved plot threads exist? What promises must I keep? It's like having a CI/CD pipeline for narrative consistency.
What I learned: Events are immutable. Once a character makes a promise or suffers a wound, it becomes part of the permanent record. This forces me to write consequences, not just plot twists.
3. Microservices for Character Arcs
Large monolithic applications become unmaintainable. So do novels with 100+ characters.
I treat each major character as a microservice with its own state, API (how they interact with others), and event log. When two characters meet, it's an API call between services:
Character: Li Wei (Protagonist)
Current State:
- Realm: Foundation Establishment
- Mental state: Stable (80%)
- Active quests: [Rescue_Mentor, Investigate_Sect_Conspiracy]
- Relationships: {Mentor: 95, Love_Interest: 72, Rival: -40}
API Call: interact(Character: Elder_Zhang, type="negotiation")
Response:
- Relationship delta: +5 (Elder appreciates Li Wei's sincerity)
- New quest unlocked: "Elder's Secret Request"
- Foreshadowing: Elder glances at forbidden library (setup for Chapter 92)
This modular approach lets me track character development without getting lost in the sprawl.
What I learned: Characters should have bounded contexts. A character who knows everything becomes a narrative god object—avoid at all costs.
The Failures: Where Software Thinking Backfired
Not every engineering practice translates cleanly to creative work.
Failure 1: Premature Optimization
I spent 47 hours building a custom wiki system to track world-building details before writing Chapter 1. The result? I burned out before the story began.
Lesson: Start with the simplest narrative structure that works. You can't refactor a story that doesn't exist.
Failure 2: Over-Abstracting Magic Systems
I designed a 12-layer elemental combination system with formal algebra. Readers found it incomprehensible. The magic became a spec sheet, not a source of wonder.
Lesson: Abstraction should serve the story, not impress other engineers. Mystery matters.
Failure 3: Git-Driven Plot Branching
I tried using Git branches for alternate plot versions, merging the "best" timeline. It created narrative schizophrenia—characters lacked coherent arcs because they were Frankensteined from multiple drafts.
Lesson: Version control is for code, not choices. Commit to a story direction and see it through.
The Unexpected Insights: What Writing Taught Me About Software
This cross-pollination worked both ways.
1. Documentation Debt is Real
Just as novels need recaps for readers who join late, codebases need onboarding narratives for new developers. A README isn't documentation—it's a plot summary.
2. Refactoring Has Emotional Cost
Rewriting a novel chapter feels like refactoring legacy code: necessary but painful. Each rewrite loses some "soul" (original intent) even as it gains clarity. Technical debt isn't just technical—it's emotional.
3. Tests Are Like Beta Readers
Unit tests catch regressions; beta readers catch plot holes. Both are feedback loops that hurt in the short term but save you from disaster.
The Numbers: 847 Days in Retrospect
- Commits: 2,147 (including 400+ world-building updates)
- Chapters: 78 published, 23 in draft
- Word count: ~280,000
- Rewrites: 3 major architectural overhauls
- Readers: 1,200+ GitHub stars, 5,000+ monthly visits
- Time invested: ~1,500 hours (including world-building tooling)
The most surprising metric? Readers don't care about the type system. They care about characters, stakes, and emotional payoffs. My elaborate cultivation specs are invisible infrastructure—essential for consistency, but not what makes the story compelling.
The Meta-Lesson: Systems Thinking ≠ Soulless Writing
There's a fear among creatives that structure kills magic. My experience suggests the opposite: structure protects magic.
When you don't have to worry about "Wait, didn't this character die in Chapter 12?", you free mental bandwidth for what matters—dialogue, emotion, and those transcendent moments when a reader forgets they're reading.
Software architecture taught me that consistency is a form of respect. Respect for the reader's time, respect for the world I've built, and respect for the craft itself.
What's Next?
I'm now building open-source tooling for other writer-developers:
- Plot Event Store: A Git-backed event sourcing system for novels
- Character State Machine: Finite state machines for character arcs
- Consistency Linter: A tool that flags narrative contradictions
Because if there's one thing this experiment proved, it's that creative and technical disciplines are not opposites—they're dialects of the same language.
🔗 Project Links:
- Read the novel: https://kevinten-ai.github.io/Compiling-the-Dao/
- GitHub repo: https://github.com/kevinten-ai/Compiling-the-Dao
- World-building wiki: (in development)
Discussion Questions
For the developers here:
- What software principles have you applied to non-technical domains?
- Have you ever treated a creative project like a codebase? What worked? What didn't?
For the writers:
- Do you use any structured systems for world-building? Or do you prefer organic discovery?
- Where's the line between helpful structure and creativity-killing bureaucracy?
I'd love to hear your experiences in the comments. And if you're curious about cultivation novels, software architecture, or the strange intersection of both—let's talk.
This post is part of my journey documenting open-source creative projects. Follow along at GitHub for more experiments at the intersection of code and creativity.
Top comments (0)