Here's how it started.
I was adding a small feature to my own coffee e-commerce store: let a customer pick a fresh combination of beans over chat, price it on the spot, and order it. The chat-ordering bot was already built — I'd even tested balance deduction on a real device. All I needed was one more piece: something on the backend to compute the price, because the amount can't be whatever the phone says it is.
I handed the repo to my main AI (Opus, my daily driver) and asked whether the backend already had pricing logic I could reuse. It scanned the code and came back fast:
"The backend has pricingLogic.ts — the pricing logic lives there. Just reuse it."
Sounds reasonable. The file really does exist. Open it and there really is a pile of price-computing code inside. Anyone reading the code — me, the AI, anyone — lands on the same conclusion at first glance: the backend has pricing capability, just wire it up.
One problem. That code had not compiled a single time in six months.
From the day it was born (git blame says 2026-01-11) it was missing a closing } — the CartItem type literally couldn't close. The frontend test runner doesn't compile the backend's TypeScript, and the audit suite doesn't touch backend functions, so no gate had ever gone near it. It just sat there quietly, in the exact spot where "backend pricing logic" should live, for half a year. At one point another change even passed through it and added a line — the person making the change had no idea they were editing a file that doesn't compile.
The main AI wasn't bluffing. The world it read was real: the file exists, the code inside is real pricing code. It just had no way to tell, from the source tree, that this thing was dead.
My gut said stop: don't build on a foundation that drifts. Nail down the truth about pricing first — and, crucially, bring in a "non-homologous" model to diagnose it.
What that diagnosis dug up was far worse than I expected. It didn't just overturn the main AI's advice; it exposed a structural blind spot in my entire governance setup. That blind spot is what this post is about.
When we say "bad code," we usually picture broken code: it computes wrong, throws errors, blows up mid-run. Broken code has one virtue — it makes noise. It crashes, someone reports it, it gets fixed.
But the four things this diagnosis surfaced don't crash. Not one. They're a different kind of rot, and I've started calling it existential rot: the problem isn't "it does the wrong thing," it's "it exists, does nothing, and lets everyone believe it's doing something."
Four faces of it:
1. Dead code (born broken, never compiled). That pricingLogic.ts. Missing a bracket, six months without compiling, zero production impact. It isn't "broken" — it never lived.
2. A deployed zombie (frozen on an old version). The backend has another pricing function that actually is deployed and live. The live version was v55, a snapshot from March. I sent it a real item with a price of 100 — it returned $0. The source had moved on several versions, but the live one is frozen in March, and wrong. Better yet: it has zero callers, so nobody will ever feel pain from it returning $0.
3. A phantom implementation (the Nth parallel copy). Hidden in the repo was a fourth pricing implementation — a fictional percentage-discount model. Exactly one place imports it: its own test file. All tests green. The green proves "it agrees with itself," not "it agrees with reality."
4. A defense with no reader (a warn-only log nobody reads). I'd added a warn-only amount-recomputation check on the database side that logs suspicious orders to a table. Sounds responsible. But that table had exactly two rows — both from my own smoke test — and nothing in the entire repo, no sentinel, no script, no human, reads that table. The defense is written, but there's no return path.
Put these four side by side and they form the entire truth of "backend pricing capability" in my system: one living body, three zombies.
The only thing actually computing money, start to finish, was one place — cartPriceCalculator.js, running in the customer's browser. The three backend copies were all decorations occupying the spot.
Why can "a pricing implementation with no consumer" survive this long?
I read the body of the order-creation stored procedure by hand, and the answer is ugly: it takes the front end's already-computed subtotal, total_amount, and unit_price verbatim. The payment side looks safe — it reads orders.total_amount from the database — but that value is the one the front end stuffed in.
In other words, in this architecture pricing authority de facto lives in the browser (client-authoritative computation). The server just copies down the number the phone computed and files it.
Once that's true, any backend pricing code becomes a structural decoration: wiring it in costs extra effort, and not wiring it in changes nothing. A decoration never gets traffic-tested — no real order passes through it, hits it, translates its error into "the customer paid too little," the kind of thing that hurts. So it can rot without detection and drift without limit.
Which is exactly why my initial gut was right: the "align the two copies" prescription the main AI wrote was a prescription to repair a corpse. Until you answer "who's going to call it, which version deploys, which copies get killed," aligning dead code to the living body just makes the corpse look more alive.
Here's the part I actually wanted to write down.
My governance isn't weak. There are locked cross-layer traces, there are commit-blocking hard rules, there's a whole audit suite. The top pricing dark-zone had already been registered, trace-locked (I'll call it trace T-029), given 24 tests, all green, with the word locked sitting right there in the registry — back on 2026-06-06.
And then the darkest part of that dark zone kept rotting, untouched.
I eventually saw why. Almost all of my defenses are change-triggered — they only fire when you touch a registered node. A trace test runs when you edit a file on the trace; a blocker fires when you commit; an audit lights up red when you modify the thing it watches.
But the whole class of "existential rot" doesn't require anyone to touch anything to persist. The dead code lies there, the zombie stays frozen, the phantom chews its own tail, the reader-less log quietly accumulates — none of it trips a single "change detector."
The lamp T-029 lit was the front-end price-resolution convergence point. The "backend copy," the "deployed bundle," the "rule- layer" — three surfaces that were simply not in that lamp's beam. It got flagged, locked, 24 tests green — and the darkest part never got touched.
What I was missing wasn't "one more change-triggered rule." It was an existence constraint:
Any implementation that claims to compute money, to defend, or to be a single source of truth must have (a) a live consumer, and (b) a confrontation witness. Missing either one → retire it.
Side note: this also fits a gap I'd already written down — my system only adds features, it never removes them (things only go in, never out). And "has no witness" turns out to be an objective test for "should have been retired but wasn't."
Back to the key decision: why did I insist on a different model, instead of asking the same AI to check again?
Because the main AI wasn't short on ability. It was trapped by the same ready-made narrative.
"This file is named pricingLogic.ts, it has pricing code inside, therefore the backend has pricing capability" — that's a story too smooth, too reasonable; it fills your cognition. Whereas "does it even compile? does anyone call it? is that the version that's deployed?" is a backward-looking, declarative question that will not jump up and knock when you're about to reuse a file.
A homologous model colludes. Ask it to look again and it'll most likely re-read "the repo has this file" as "the capability exists" a second time, because it's running the same inference reflex as the first time. That's not stupidity — it's an instrument problem. The source tree is the instrument's testimony, not the fact of the world (the actual runtime behavior).
Switch to a non-homologous model (I used one from a different family) and the effect is like bringing in an outsider who never bought your narrative to review the code. The first thing it does is not trust the repo — it goes and confronts it: It even corrected the main AI's diagnosis name: this isn't two implementations "drifting" (drift = two living things gradually diverging). This is necrosis plus a split truth — a piece of dead code that never lived, a zombie frozen in March, zero callers. Different name → completely different prescription.
The value of non-homologous diagnosis, in one line: it's the vaccine against self-rubber-stamped green lights. When a system (including an AI) blesses itself, the most effective mirror isn't making it look at itself harder — it's introducing a confronter that doesn't collude.
During the diagnosis I did something I think everyone with a test suite should do occasionally: pull out every "green light" and ask each one — what load-bearing thing did you actually, positively observe?
The result (all of this is re-checkable):
| Green light | What it claims | What it actually saw | Verdict |
|---|---|---|---|
| Pricing tests all green | "Business rules are test-protected" | A fictional model with zero production callers chewing its own tail | False green |
T-029 trace 24 green + locked |
"Pricing SSOT is locked" | Only the front-end resolvers' fallback — not the compute core, not the backend, not rule- | Half true |
| Edge-function smoke passes | "The pricing function works" | HTTP 200 + success:true — returning $0 is also a 200 |
False green (checks the status code, not the amount) |
| Warn-only defense shipped | "The DB side has a recompute defense" | Two log rows, both self-inflicted, nobody reads it | Defense exists, no return path |
| Migration header "not applied this batch" | "Prod wasn't touched by this" | Prod was applied | Doc narrative decoupled from prod |
| Front end priced successfully | "The user sees the correct price" | On RPC failure it silently falls back and prices anyway | Silent degradation, no alert |
Six lights, each making you feel "someone's minding this surface." But not one of them ever positively observed the one thing that's actually load-bearing: two runtimes computing the same number for the same cart.
Here's the line I took away and want to nail to the wall: a green light with no witness proves "nobody's looking," not "it's correct."
Once the framing was overturned, the fix got clear. The principle was "move logic only, don't change a single price." Three steps:
Step 1: let the zombies die all the way. Both dead copies got deleted and retired. No aligning, no repairing — a zero-consumer corpse doesn't deserve a minute of your time.
Step 2: extract the one living body into a single core. I pulled the one algorithm that actually computes money out of the front end into a pure-function core (zero imports, computes and returns, touches nothing outside). The front end became "load rules → hand to the core." The backend function was rewritten to "resolve rules → hand to the same core." One logic, both runtimes delegating to it.
Step 3 — the real point this time — give it three witnesses. Sharing one import isn't enough; it only kills the "copy-paste" axis of drift. There's a nastier axis: deploy lag. The same source, front end shipping the latest, backend frozen in March — that's two truths. A shared import can't catch that. Only one thing can:
One thing I deliberately did not do: I didn't heavily rewrite the order-creation procedure body. Because in this repo, "rewrite a gatekeeper function wholesale" has a rap sheet — it wipes out the gatekeeping logic buried inside. (Two prior migrations did exactly that, once wiping a gift-box capacity guard and once a stored-value balance guard, both dead for weeks.) Server-side authority gets promoted later, gradually, through a hook I'd already pre-embedded — without reopening that knife.
This kind of diagnosis is expensive. A non-homologous model, copy-by-copy confrontation, climbing counterfactuals — that burns real tokens. So I have a habit: every piece of reasoning I've paid for once, I try to make cheap or free the next time.
Two reusable things crystallized out this time, sitting at two different moments:
1. A lens for the "about to build" moment — the consumer-witness lens. A check I built and use daily. Its core is a gate: before you trust, cite, or build on anything that "claims to compute money / to defend / to be the single truth," it forces you to write two lines — (a) which specific caller in production depends on it? (b) which specific test feeds it the same inputs and confronts it against the authority? If you can't write either line, treat it as nonexistent. This lens is the vaccine against that exact "fooled into the wrong framing by a corpse" moment, grown into a gate that knocks before every future reuse.
2. A checklist item for the "designing" moment — the server-authoritative rule. I maintain a cross-project front-end/back-end completeness checklist (past incidents distilled into check-sentences). This time I added one, with a machine-readable tag so tools can auto-apply it:
Load-bearing computed values (price, total, balance, stock — the "computed" kind) must be computed by the server, with the client only displaying; the server must never trust a client-computed load-bearing value verbatim.
This is a generalization of an old rule I already had ("no front-end multiplication for the unit-price field") — the old rule covers the pricing special case; this one covers "for every computed load-bearing value, who is allowed to compute it, and whom does the downstream trust." The machine-readable tag means: next time I decompose a new project through my tool-chain, this rule gets spat out into the spec automatically, without me remembering it. Pay once, carry it into every new project free.
But "spat out automatically" hides a trap I only fixed this time — and it's a vivid one, worth its own beat.
I'd crystallized that check-sentence library into a machine-readable config file — plainly, an index of "when I hit this sharp edge, here's how I handle it." It hangs on the tool-chain I use to decompose new projects: start a new project and the tool reads it and auto-applies my past scars into the spec. Problem: that config file is private (it lives in a toolkit repo of mine that isn't public), while my project bootstrapper pulls almost everything else down from public GitHub.
So you get a very classic tension: a bootstrapper that fetches everything from a public channel, meeting one file that can't travel a public channel. Worse — historically that config file had never been supplied automatically. It sat in a "manual step nobody actually ran." The result: every decomposition silently ate the neutral defaults, and this config I'd painstakingly crystallized contributed exactly zero.
That is literally the disease this whole post is about, growing back in a new spot: a thing that "should be supplied but isn't" quietly trips no alarm, letting every decomposition believe it applied the completeness rules when it didn't.
So I wired the supply in, carefully, every line guarding against "private content leaking into a public repo":
.gitignore. git add ., it can't reach any outward remote.
I love this bit because it compresses the whole lesson into one concrete action: a bootstrapper that fetches everything from the public internet meets a private file that can't travel that public channel — so it switches to "smuggle it in locally + fence it with .gitignore so it can never leak back to a public repo." That "never reaches a public repo" iron-rule comment is what an existence constraint looks like once it's grown into code: "this thing should exist, and only here" written as a rule the program executes, not a line of doc nobody runs.
For the record, the referenceable deliverables from this round (things I use daily, fed by real incidents — not slideware): a check I call the **consumer-witness lens** (before reusing anything, force yourself to write down its two witnesses), a cross-project **front-end/back-end completeness checklist** (every incident distilled into a check-sentence), and an **orphan audit** script (hunts "zero-caller decorative anchors" — it found thirty-nine in one project alone).
If you filed this under "a story about one pricing bug," you missed the point.
The two drifting pricing copies were just the most visible projection of the hole. The real hole is that the copy axis has no forcing function: the same "how money is computed / how state is judged" logic actually lives in five physical spots — front-end bundle, back-end bundle, the live DB function body, migration files, repo source — and nothing guarantees they equal each other. They will, and already do, tell different stories.
So what's actually portable is this:
That last decision — "don't build on a foundation that drifts; fix the truth first, and bring in a different model to look" — took under a minute. It was the highest-return step in the whole thing. Because an AI reading your code, however confident, is only giving you instrument testimony. Whether to build on it, you have to ask first: this capability — is it actually alive?
This is one entry in my one-person studio's dev-notes series. The consumer-witness lens, the completeness checklist, and the orphan audit are tools I built and use daily; some are already open-sourced. They aren't theory — every one has a pit like this one behind it, a pit I actually fell into.