DEV Community: Arsene Muyen Lee

I encoded a 1000-year-old divination system in Go. Every bug was a distinction my types had collapsed.

Arsene Muyen Lee — Thu, 20 Aug 2026 16:41:16 +0000

I spend my day job on cloud platform work — pipelines, idempotent state machines, the usual distributed-systems apparatus. For the last year I've spent evenings on something with no obvious overlap: an engine that computes and reads Zi Wei Dou Shu (紫微斗數), a Chinese astrology system that's been accreting rules since roughly the Song dynasty.

It turned out to overlap completely. Not because divination is secretly distributed systems, but because Zi Wei is a formal system someone else specified, a thousand years ago, without writing types. My job was to encode it. And every serious bug I hit had the same shape:

The tradition drew a distinction. My data structure didn't. Some code path downstream then confidently stated the opposite of the truth.

That's a domain-modeling failure mode, and it's a nastier one than it sounds, because the output was always grammatical. There was no crash, no nil deref, no failing assertion. Just a fluent sentence that a knowledgeable reader would recognize as nonsense.

Here are the ones worth showing.

The system, in one paragraph

A Zi Wei chart is twelve palaces (宮) arranged in a ring, each holding some of ~66 stars. Each palace also carries its own heavenly stem (天干), and each stem produces four transformations (四化 — 祿/權/科/忌, roughly: flourishing, authority, reputation, obstruction). A transformation "flies" from the palace that produced it into some other palace. So a chart isn't twelve independent readings — it's a directed graph with twelve nodes and up to 48 edges, and the interesting claims live on the edges.

That's the whole domain for this post. The engine computes the graph client-side, sends a summary to a Go backend, and the backend composes a reading from an authored corpus.

Bug 1: the struct that knew less than the tradition

A transformation flies from one palace to another. Except sometimes it lands on the palace that produced it. The tradition calls that 自化 (self-transformation), and it means something opposite to a normal flight: an outgoing 化 is that palace acting on another area of your life; a 自化 is that energy running on its own and — per the sources — not being retained.

My wire format didn't care:

// PalaceSlot is one of the 12 palaces.
type PalaceSlot struct {
    Name   string
    Stem   string        // this palace's own 天干 — the input to Flying
    Flying []FlyingSihua // where each of its 祿/權/科/忌 lands
    // ...
}

type FlyingSihua struct {
    Mutagen  string // 祿/權/科/忌
    ToPalace string
}

One list. Self-landing edges sat in it alongside everything else, because structurally they are the same thing: a mutagen and a destination.

Downstream, a composer walked that list and wrote each entry as "your 祿 flies out to your X." Which meant a palace whose 祿 self-transformed got told its 祿 flew out to itself. In the paid reading. And in the chat context, which reads the same structure — so the LLM answering follow-up questions was grounded in a fact that contradicted the tradition it was supposedly grounded in.

The tempting fix is a guard in the composer: if f.ToPalace == p.Name { continue }. I did that first. It's wrong, because it makes correctness a thing every future consumer has to remember, and there were already three consumers.

The fix that holds is splitting it in the data:

// SplitSelfSihua separates a palace's 自化 from its outbound flights.
func SplitSelfSihua(p PalaceSlot) (outgoing, self []FlyingSihua) {
    for _, f := range p.Flying {
        if f.ToPalace == p.Name {
            self = append(self, f)
        } else {
            outgoing = append(outgoing, f)
        }
    }
    return outgoing, self
}

and then making the only structure composers can reach carry both fields:

type DomainPalaceFacts struct {
    Palace string
    // Outbound is only the transformations that REACH ANOTHER PALACE. A 化
    // landing back on its own palace (自化) is split into Self instead, because
    // the two make opposite statements and every consumer here renders Outbound
    // with "flies out to your X" phrasing.
    Outbound []FlyingSihua
    Self     []FlyingSihua
    Inbound  []InboundFlying
}

Now a composer that ignores Self omits something. It can no longer assert something false. That's the whole difference, and it's the "make illegal states unrepresentable" idea applied to a domain where the illegal state isn't a nil pointer — it's a sentence.

I also wrote the spec rule to say why, because the next person to touch this will otherwise re-merge the fields for convenience:

This is not a style preference. A structure that carried both under one name was consumed by a composer that wrote every entry as "flies out to your <palace>", so a palace whose own 祿 self-transformed was told its 祿 flew out to itself.

Bug 2: matching on the wrong key told a two-year-old about his forties

Life is divided into twelve ten-year decades (大限), each sitting on a palace. To find which decade you're currently in, the obvious move is: ask the chart engine which palace is the current decadal palace, then find the age band sitting on that palace.

Palace names are the join key. Palace names are also not unique across time — the ring has twelve positions and twelve bands, and matching by name finds a band on that palace, not your band.

Worse: the engine reports a decadal palace even for someone who hasn't reached their first decade at all (六歲起運 — decades start around age six, so a five-year-old has none). So the lookup happily returned a match seventy years out. A two-year-old's chart said "this year sits inside your 76–85 decade."

The fix isn't cleverer matching, it's a validity check on the result:

The system SHALL treat a 大限 age band as the active decade only if the band's calendar years can contain the year the reading is about.

With one deliberate exception, which I think is the more interesting half:

Where the birth year cannot be resolved the palace match SHALL be used as-is: suppression requires proof the band is wrong, not absence of evidence that it is right.

That asymmetry comes up constantly once you look for it. "I can't verify this" and "I have verified this is wrong" should not produce the same behavior, and a naive if !ok { return } collapses them.

Bug 3: the pigeonhole that only bites two birth years in ten

The 來因宮 (origin palace) is defined as: the palace whose own stem equals your birth year's stem. Exactly one palace, reported as a lifelong placement.

Straightforward scan, right? Find the palace whose Stem matches YearStem. That's a one-liner, it passes tests, and it's broken for 20% of humanity.

Palace stems are assigned by a rule called 五虎遁, which walks 10 stems across 12 branches. Pigeonhole: two palaces always repeat the opening stem. For two of the ten birth-year stems, that repeat is the year stem — 辛 years put 辛 on both 卯 and 丑; 壬 years put 壬 on both 寅 and 子. A naive scan returns two answers for one in five charts, and whichever one it returns first wins.

The tradition already knew. The 來因宮 never falls in 子 or 丑, precisely because those are the duplicated positions:

// THE TRAP: 五虎遁 walks 10 stems across 12 branches, so two palaces always
// repeat the opening stem, and for two of the ten birth years that repeat IS
// the year stem. 辛年 puts 辛 on both 卯 and 丑; 壬年 puts 壬 on both 寅 and 子.
// A naive scan returns two palaces for one in five charts. The 來因宮 never
// falls in 子 or 丑 precisely because those are the duplicated positions, so
// excluding them leaves exactly one answer for all ten stems.
func DeriveLaiYinGong(z Summary) (palace, branch string, ok bool) {
    branches := palaceBranches(z)
    if branches == nil || z.Natal.YearStem == "" {
        return "", "", false
    }
    for i, p := range z.Palaces {
        if p.Stem != z.Natal.YearStem || branches[i] == "子" || branches[i] == "丑" {
            continue
        }
        return p.Name, branches[i], true
    }
    return "", "", false
}

Two lines of exclusion. The value is entirely in the comment, and I'd argue the comment is the deliverable — the code without it looks like an arbitrary special case that a future cleanup deletes.

The general lesson: when you're implementing someone else's formal system, an apparently arbitrary restriction is usually load-bearing. Find out what it's carrying before you optimize it away.

Trusting the client exactly as far as you can re-derive it

The chart is computed in the browser (the engine is a TypeScript library) and the summary is POSTed to Go. Which makes every field on it untrusted input — not in the security sense here so much as the correctness sense: a version skew, a library change, a reordering, and the backend composes a confident reading from wrong facts.

PalaceSlot.Stem is the sole input to PalaceSlot.Flying, and Flying is what reaches the paid reading. Validation checked that Stem was... a string.

So the backend re-derives all twelve independently and compares:

// crossCheckPalaceStems re-derives all 12 palace 天干 via 五虎遁 and compares
// them to what the client sent.
//
// This is not busywork: PalaceSlot.Stem is the sole input to PalaceSlot.Flying,
// Flying is what reaches the paid reading, and nothing checked either of them
// until now. It also underwrites palaceBranches: if Summary.Palaces ever stops
// arriving in 地支 order, the offsets go wrong and this fires, instead of
// 來因宮 quietly naming the wrong palace.
func crossCheckPalaceStems(z Summary) []Mismatch {
    branches := palaceBranches(z)
    if branches == nil {
        return nil
    }
    var out []Mismatch
    for i, p := range z.Palaces {
        if p.Stem == "" {
            continue
        }
        want, ok := palaceStem(z.Natal.YearStem, branches[i])
        if !ok || want == p.Stem {
            continue
        }
        out = append(out, Mismatch{"palaces[" + p.Name + "].stem", p.Stem, want})
    }
    return out
}

Duplicated logic across two languages, deliberately. It's the cheap version of a parity oracle: the two implementations are independent enough that agreement is evidence, and disagreement surfaces as a named mismatch instead of as a plausible paragraph.

The rule I nearly shipped that didn't grade anything

One feature counts how many 化忌 (the obstruction transformation) converge on each palace, and grades the heavy ones. Before shipping it I measured the tier distribution across the reference charts.

The severe tier — the one whose vocabulary is 凶/破 — covered 11% of individual palaces. Fine. But I was also grading axes (a palace plus its opposite), and across axes the same tier covered 32%.

A verdict of that severity applied to a third of the board isn't a verdict. It's a mood. So the rule ships grading single palaces only:

The system SHALL grade a single palace by its own count, and SHALL NOT grade the sum across an axis.

The habit that came out of this and that I'd defend generally: before you ship a rule that classifies things, measure its firing rate on real data. A rule that fires on a third of inputs conveys almost nothing, no matter how correct each individual firing is. That's true of lint rules, alert thresholds, fraud heuristics, and — apparently — thousand-year-old divination texts.

The same feature also ships behind a flag that defaults to off, with "absence of the setting means off," because the reason to disable it is the text reads badly on a real chart — which you only find out in production.

The through-line: decline instead of guessing

Written out, the rules I kept adding were all one rule:

Missing per-palace stems, birth-year stem, or 命宮 branch → no 來因宮 named, rather than one guessed.
Chart carries no 生年四化, or client sent no flying data → neither paragraph written, rather than half a contrast.
No palace on the chart reached by two or more 忌 → no verdict text at all, rather than an empty or hedged section.
No self-transformation anywhere → no self-transformation section, rather than one saying there isn't one.

The failure mode this guards against is specific to generated text, and I think it's underrated: an LLM-adjacent pipeline given a section header and no facts will fill the section anyway. It will hedge beautifully. The output is indistinguishable from a real reading until someone who knows the domain reads it.

Empty sections aren't neutral. They're an invitation to fabricate.

What actually generalized

None of this is about astrology, and I'd have learned the same things porting an insurance rating manual or a tax code — any formal system that predates the software and that you don't get to redesign:

A distinction the domain makes must exist in the type, not in each consumer's discipline. Guards in consumers scale linearly with consumers; a split field scales with zero.
Join on something unique, and validate the result independently of the join. Name-matching found a real band, just not the right one.
Arbitrary-looking restrictions in an old system are usually load-bearing. The exclusion you're about to delete is someone's pigeonhole fix from 400 years ago.
Re-derive untrusted input you can re-derive. Two independent implementations turn silent wrongness into a named mismatch.
Measure a classifier's firing rate before shipping it. A severe verdict on a third of cases grades nothing.
"Can't verify" and "verified wrong" are different states. Don't collapse them into one return.

The engine is part of iYarrow, where the natal chart and reading are free. The casting algorithm it grew out of is open source and separate: meihua-yishu, a 梅花易數 implementation that stays the parity oracle for the divination arithmetic.

If you've hit the same shape of bug in a domain nobody would call exotic, I'd like to hear it — my strong suspicion is that "fluent and wrong" is much more common than "crashed," and much less reported.

What 963 Commits Taught Me About the 'Vibe to Prod' Gap

Arsene Muyen Lee — Sun, 04 Jan 2026 05:53:28 +0000

Why AI-assisted coding is 10% of shipping software

I built the core of a media authenticity app in a weekend.

Firebase Auth. Cryptographic signing. Camera integration. Claude helped me write Go handlers. Cursor generated React components. The demo was chef's kiss.

I felt like a god.

Then I tried to deploy it. That's when I discovered what 963 commits of pain looks like.

The 90% Nobody Talks About

Here's what tutorials show you:

Idea → Code → "It works!"

Here's what production actually requires:

Idea → Code → Tests → Security → CI/CD → Infrastructure → Deploy → Monitor → Iterate

That arrow between "Code" and "Tests"? It took me 963 commits and nearly a year to cross.

I'm not exaggerating. Here's my actual git history.

The Real Journey (From My Git Log)

Commit #1: The Euphoria

fb5f2ea Initial project structure
8750a5c Implement core backend with cryptographic proof system

Two commits. Core functionality done. I felt invincible.

Commits #3-12: The Reality Check

f7d4886 Add Docker build and Cloud Build configuration
a965146 Add Docker build and Cloud Build configuration

Wait, why are there two commits for the same thing? Because the first one didn't work.

Then came the GitHub Actions saga:

8d21a90 Fix GitHub Actions: Add CLOUDSDK_CORE_PROJECT env var
383e76a Fix GitHub Actions: Use google-github-actions/auth@v2
8159c3f Fix GitHub Actions: Add export_default_credentials

Three separate commits just to get authentication working in CI. Each one felt like victory. Each one revealed another problem.

The Milestone That Mattered

23be044 ✅ Complete CI/CD pipeline working!

See that emoji? That's not decoration. That's relief. That commit represented weeks of wrestling with:

Service account permissions
Docker layer caching
Environment variable injection
Secrets management

The code itself? Maybe 200 lines. The debugging? Countless hours.

The Gaps AI Won't Vibe Through

Gap #1: CI/CD Is a Special Hell

AI can write your GitHub Actions workflow. It cannot debug why your workflow passes locally but fails in CI with a cryptic PERMISSION_DENIED error at 11pm when you just want to ship.

My repo has 30+ commits with "fix" and "CI" in the message. Each one taught me something documentation didn't.

Gap #2: Infrastructure Is Not Code

"Just use Terraform" they say. "Pulumi is easy" they say.

Sure. But first you need to:

Set up GCP/AWS accounts and billing
Configure service accounts with correct IAM roles (not too few, not too many)
Create Artifact Registry for Docker images
Maintain separate dev/prod environments that don't accidentally cross
Wire up secrets management without committing .env files
Configure custom domains and SSL certificates

Each bullet is a rabbit hole. None of them ship features.

Gap #3: Security Is Invisible Until It Isn't

c8b4a6d feat: Complete integration test infrastructure with production-ready authentication

That single commit message hides:

JWT validation that actually validates
Firebase Auth token verification
Rate limiting (because someone will try to hammer your API)
Security headers: CORS, CSP, HSTS
Dependency vulnerability scanning

None of this was "vibed." All of it was required before I could sleep at night.

Gap #4: Cross-Platform Is Cross-Painful

5841cdb fix iPad create proof crash issue
e2b3ec8 android and universal link fixes
c7ff253 android fix like and bookmark

The app worked on my iPhone. And my Android test device.

iPads? Different aspect ratios broke the UI. Different memory constraints caused crashes. Different logs to hunt through.

"Works on my device" is the new "works on my machine."

What I Actually Extracted

After 963 commits, I did something I should have done earlier: I separated my business logic from everything else.

The "everything else" turned out to be around 15,000 lines of infrastructure code. A year of debugging distilled into config files and workflows.

Here's what's in there:

GitHub Actions pipelines with security scanning (gosec, Trivy, govulncheck) — because I got tired of finding vulnerabilities in prod
Pulumi infrastructure for Cloud Run, Firebase, and networking — because clicking through GCP console doesn't scale
Environment separation that actually separates dev from prod — learned this one the expensive way
Firebase Auth integration that handles edge cases — the "happy path" documentation doesn't mention
Structured logging with Zap — because fmt.Println stops being funny in production
Health checks and graceful shutdown — for when Cloud Run decides to kill your container mid-request
Docker builds with layer caching — because 15-minute builds break your flow
Pre-commit hooks — to catch the problems I kept committing

The GitHub Actions workflows have comments explaining why certain approaches don't work. Those comments are my debugging sessions, preserved in code.

The Math

Phase	What I Expected	What It Actually Took
Core features	1 weekend	1 weekend
CI/CD pipeline	2 hours	3 weeks
Infrastructure	A few days	2 weeks
Security hardening	Add it later	2 weeks
Testing	Manual is fine	1 week
Monitoring	Console.log	1 week

Weekend project → 2+ months to ship properly.

Unless you start with production infrastructure.

The Repo

I open-sourced the whole thing: vibe-to-prod

It's the production infrastructure from my actual app with the business logic stripped out. Go backend, Next.js frontend, Pulumi IaC, GitHub Actions CI/CD, Firebase auth.

Will it save you 963 commits? No. You'll have your own debugging sessions, your own 2am "why doesn't this work" moments. That's how you actually learn this stuff.

But maybe it saves you the first 200.

The commit that started this: fb5f2ea Initial project structure. The commit count when I wrote this article: 963. The number of times I Googled "GitHub Actions PERMISSION_DENIED": countless.