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.