I built a vertically-integrated commerce system with AI — and accidentally discovered 4 governance patterns

A barista who built a vertically-integrated commerce system by pair-programming with AI discovered four governance patterns after repeatedly fixing the same class of data-sync bugs over six months. The patterns—outside-in vs inside-out debugging, decision pinning, and trace lock—emerged during a seven-hour session with Claude, the AI pair-programming tool, that fixed four blocker issues at once.

May 2026 · Series "Trace Lock — Governance notes from pairing with AI to write code" · Post 1 of 9 meta In May 2026, Claude my AI pair-programming tool and I did something I genuinely didn't expect: We slowly extracted 4 methodology patterns working names — I'll explain why in a moment from a 6-month loop of "fix a bug → another one appears → fix that one → another one appears." I'm a barista. I maintain a self-built, vertically-integrated commerce system by pair-programming with AI. I'm writing this 9-post series for 3 reasons: This post is the series' meta entry — context, why these patterns surfaced, what the 4 patterns are. The "how to actually do it" goes into the next 8 posts. For 6 months I kept hitting the same class of bug: "Data flows from a write-side to a render-side, and somewhere in the middle a layer forgot to sync. Then something breaks." Concrete examples: Each fix took 3-5 hours. Over 6 months that's 5-6 fixes for the same class. The painful part isn't the fix itself. It's that a month after fixing it, a sibling bug appears, because the root cause wasn't addressed. A team has QA / SRE / PM / code review to catch these. I don't. On May 25th I hit another one of these. Customer screenshot: "The 'complete roasting' button is frozen, showing 'roast level mismatch'." I was about to fix it the usual way: comment out one RAISE statement and call it done. But I asked Claude one question: "I've fixed 5 of these in 6 months. Should I stop and look for all leaks of this same shape, fix them all at once?" Claude proposed: Spend 1 hour auditing the whole business flow first. List which chain nodes are unprotected. Then decide what to fix first. I spent 1 hour with Claude mapping it out. We found: Those 4 BLOCKERs included: "order cancel / refund flow," "roasting completion stage," "FIFO ingredient consumption," "packaging station task state." Each one was a "next customer to trip on this costs me 3-5 hours" landmine. Then Claude and I spent 7 hours fixing all 4 BLOCKERs at once. Plus building a mechanism that auto-reminds me when I edit related code in the future. These 4 patterns came to me gradually during those 7 hours . They weren't known in advance. They crystallized in retrospect: Fix a bug = start from the specific symptom the customer reported, trace outward, fix the root cause. Audit a chain = walk from the business flow's entry to its exit, listing whether each node is protected. For 6 months I'd only been doing the first kind. The problem with the first kind: it only fixes reported bugs. The unreported ones keep lurking. The second kind looks like more work 1 hour of audit , but the ROI is much higher, because it surfaces problems that haven't shown up yet . I gave this pair of mental modes a working name: " outside-in looking at the whole chain from outside vs inside-out tracing from a specific bug outward debugging. " But this is just my own naming. Formal software engineering probably has more precise terms already, I'm not sure. These 4 BLOCKER fixes all involved a business decision: These decisions feel obvious to me in the moment, but in 3 months me or another engineer or AI reading the code might think "this logic is weird, let me clean it up." Claude's suggestion: write those decisions as test cases with incident-pinning comments tests that include a "why" comment . Six months later, when anyone edits the code, the test fails red, forcing them to see the original decision context. I gave this practice a working name: " Decision Pinning. " Same thing, just my working name. I don't know if there's a more standard industry term. Software systems are full of "if I change A, I must also change B" cross-layer dependencies. For example: Historically these relationships only existed in my head . Three months later, forgetting means "I changed A but forgot B." Claude and I designed a thing we call "Trace Lock" working name again : This setup is working well so far. Claude and I extended it during this audit with a new sub-category called sql-only-trace a testing approach for pure DB logic . Combining Pattern 1 and Pattern 3 surfaces a larger pattern: Neither alone is enough: In physics, entropy you can think of it as "disorder" increasing monotonically is "natural". To decrease entropy you need to continuously inject energy. Software bug count follows the same logic, I think this is just how I personally make sense of it. I'm not claiming it's a rigorous analogy . I plan to write: If you only read one, I'd recommend A1 defensive . That's where this whole thing started. This post is an organized record of conversations I had with Claude an AI pair-programming tool during May 2026. I noticed some patterns worth keeping for my own future reference, so I asked Claude to help structure them into writing. A few things I'm not claiming: If a professional engineer spots misuse, or there's already a more standard name for any of these concepts, I genuinely welcome corrections .