murphy-complexity-invoice

name

murphy-complexity-invoice

description

The slow-accruing debts that look free on day one and send a bill later — comprehension debt (shipping code nobody read or can defend), architectural entropy across sessions, the day-one mirage, the collector's fallacy (capture mistaken for progress), maintenance tax outrunning capture, the tool becoming the project, and skill atrophy. Use when vibe coding, building fast prototypes, merging high-volume AI-generated code, standing up second-brain/note systems, working under "ship it now" pressure, or letting a throwaway quietly become production. A failure-domain lens in the murphy-jutsu pre-mortem family.

Murphy: Complexity Invoice

A failure-domain lens in the murphy-jutsu pre-mortem family — the pessimistic twin of brainstorming. Mined from ec1-dev videos.

When this lens applies

• Vibe coding or AI-assisted builds where the agent emits more code than a human reads.
• Fast prototypes and demos that may quietly graduate into production.
• Second-brain / note / bookmark systems where capturing is cheap and revisiting is not.
• "Ship it now" pressure that defers reading, refactoring, and cleanup to a later that never comes.
• Multi-session work where each session adds a little redundant structure.
• Any workflow where the win is felt today and the cost is invisible until much later.

Failure modes

Comprehension debt — shipping code nobody read or can defend

• How it happens: The agent produces code faster than anyone can review it; reviewing it back would cost the time the typing "saved," so the human scrolls to the bottom and approves thousands of unread lines. Because no one built a mental model, no one can defend the architecture or fix it under pressure. "You don't write it, you don't read it" — and prod does not grade you on vibes.
• Warning signs: Thousand-line diffs approved in seconds with no line-level comments; no one can explain a given function or say where a behavior lives; "it demoed clean" is the only validation; during an incident the only thing that understands the code is the agent that wrote it.
• Mitigations: Cap the size of a single agent-generated change and require a human to explain what merged before it lands; treat "I didn't read this" as blocking, not a style nit. Comprehension is the gate to production — never ship something you can't read. Keep the riskiest paths in human hands and rehearse incident response without the agent.

Architectural entropy — sprawl that compounds across sessions

• How it happens: Each session the agent adds something slightly redundant — a second function doing the first's job, an unrequested folder, a config overriding another config. None is individually wrong; they compound until the codebase is unmappable and one small edit breaks seven unseen things. The same operation ends up implemented in nine places.
• Warning signs: Duplicated logic and 14 copies of a function; mystery folders and configs no one requested; small changes that rewrite unrelated parts; growing surprise breakage; nobody holds a mental map of the system.
• Mitigations: Schedule consolidation passes to kill duplicate functions and stray configs — not just behavior review, structural review. Constrain where the agent may create new files/configs. Keep an up-to-date module index / CONTEXT doc so canonical implementations are discoverable and the agent doesn't add a third.

Day-one mirage — "there is no day two"

• How it happens: The build feels flawless early, so the smoothness is trusted to persist. The properties that made day one magic (tiny, fully in view, nothing to maintain yet) are exactly what fail at scale — "complexity always sends an invoice." The crime is letting day-one code quietly become the company.
• Warning signs: Velocity that was effortless on day one starts dropping; fixes that spawn fresh bugs; "we'll clean it up later" with no later scheduled; a prototype accruing real users while still carrying prototype assumptions.
• Mitigations: Decide up front whether code is throwaway or a keeper, and gate keepers on review the moment they cross into production. Plan for the day-two bill before it arrives — don't extrapolate day-one ease. Separate "explore/throwaway" use from "ship" use explicitly.

Collector's fallacy — capture mistaken for progress

• How it happens: Capturing a thought delivers a hit of "I'm learning" with none of the learning. Highlighting isn't understanding; saving an article isn't reading it. Volume captured gets mistaken for volume of usable ideas (4,000 notes, 11 ever read). Somebody, eventually, has to go back and read the thing — and no one does.
• Warning signs: Note/bookmark count climbing fast while the read/used count stays tiny; satisfaction coming from capturing rather than revisiting; never returning to anything saved.
• Mitigations: Track a consumption metric for any knowledge base, not just a capture count. Build a deliberate review/processing loop so saved items get used. Be honest that saving is not learning, and that an append-only pile is a graveyard, not a brain.

Maintenance tax exceeds capture tax

• How it happens: A growing store accrues dead links, orphan notes, and stale tags. Tending the structure becomes more expensive than adding to it, and the tending masquerades as productive work — weekends spent reorganizing a vault that produces nothing.
• Warning signs: Recurring "reorganize the vault" sessions; tags that "meant something in March"; orphan/dead-link cleanup that never ends; reorganizing that feels productive but ships nothing.
• Mitigations: Budget for maintenance up front and count it as cost, not progress. Prefer minimal structure that degrades gracefully over a schema that drifts. Prune orphans and stale tags on a schedule, and don't confuse reorganizing with thinking.

The tool becomes the project — complexity creep

• How it happens: Installing one more plugin, configuring the perfect setup, optimizing the system — effort shifts from using the tool to tuning it. "You are no longer thinking with your notes, you are optimizing the tool you use to hold the notes you don't read." The setup quietly becomes the deliverable.
• Warning signs: Plugin/config count climbing; time spent on the system far exceeding time producing with it; the rig, not the output, is what you're proud of.
• Mitigations: Cap plugins/config to what the actual workflow needs. Ask of each addition: does this serve output, or just the system? Keep incidental complexity low — every addition sends an invoice.

Skill atrophy — the off-bill cost

• How it happens: Code you didn't write, you never learned; the underlying skill weakens and your capability degrades beyond this one project. The dependence is invisible until the day the agent can't help and you can't either.
• Warning signs: Declining ability to write or debug without the agent; reliance on it for fundamentals; an incident where no human can reason about the failing system.
• Mitigations: Watch for skill atrophy — keep humans able to debug without the agent. Deliberately hand-write and own a share of the work to stay sharp; treat agent output as something to learn from, not only to ship.

Pre-mortem questions

1. If the agent generates thousands of lines, what stops them merging unread — is there a diff cap and a "can a human explain this?" gate?
2. When prod breaks at 2 a.m., who actually understands the failing code — a human, or only the agent that wrote it?
3. Over many sessions, who watches for duplicate functions, stray configs, and structural drift, and when do we run a consolidation pass?
4. Is this genuinely throwaway, or are we quietly letting day-one code become the company — and have we decided keeper-vs-throwaway up front?
5. What's our consumption metric? If captures climb but nothing is ever revisited, are we building a knowledge base or a graveyard?
6. Who pays the maintenance tax — dead links, orphans, stale tags — and is it budgeted, or will "reorganizing" quietly become the work?
7. Is the tool becoming the project — is more time going into tuning the system than producing with it?
8. Which skills are we losing by delegating, and could we still operate the system if the agent were unavailable?

Mitigations checklist

• Cap the size of a single agent-generated change and require a human to explain what merged before it lands.
• Treat "I didn't read this" as a blocking condition; comprehension is the gate to production.
• Decide up front whether code is throwaway or a keeper, and gate keepers on review.
• Schedule consolidation passes to kill duplicate functions and stray configs; constrain where the agent creates new files.
• Keep an up-to-date module index / CONTEXT doc so canonical implementations are discoverable.
• Track a consumption metric for any knowledge base, not just a capture count.
• Build a deliberate review/processing loop so captured items actually get used.
• Budget maintenance as cost up front; prune orphans and stale tags on a schedule.
• Cap plugins/config to what the workflow needs; ask whether each addition serves output or just the system.
• Keep humans able to debug without the agent — hand-write and own a share of the work to fight skill atrophy.

Recurring motifs

• "Complexity always sends an invoice." — the through-line: every shortcut accrues interest.
• "You didn't skip the work, you financed it. Vibe coding is a payday loan... and the collector always knocks on the worst possible day." — comprehension debt comes due during the incident.
• "Vibecoding works on day one. There is no day two." / "the crime is letting day-one code quietly become the company." — the day-one mirage.
• "Capture is not progress." — "Your second brain isn't a wiser you, it's past you with a search index." — the collector's fallacy and its maintenance tax.
• "You are no longer thinking with your notes, you are optimizing the tool you use to hold the notes you don't read." — the tool becoming the project.

Source videos

• Vibe Coding Has 5 Silent Taxes. Most People Miss Them. — transcripts/01_vibe-coding-5-silent-taxes/
• my Obsidian second brain has 4000 notes and none of them are useful — transcripts/07_obsidian-4000-useless-notes/
• vibecoding works on day one. there is no day two — transcripts/12_vibecoding-no-day-two/