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:
- I'll forget why I designed things this way in 3 months
- Every new AI session starts from zero — writing patterns as markdown that lives in the project means the next conversation auto-onboards (the AI reads them before we start)
- There should be more and more of us — non-CS-background, pair-with-AI, solo-maintaining a medium-complexity system. If this series saves one person a year of wall-banging, it was worth writing
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.
What my system is
- For the past 7 years I cobbled together a bunch of off-the-shelf SaaS to run my business (a POS, a member system, a pile of spreadsheets)
- In 2024 I decided to build a vertically-integrated system myself — products / orders / inventory / members / roasting station / packaging station / shipping all wired together
- Stack: Vue 3 frontend, Supabase backend, Claude Code for pair-programming
- Scale: 14,000+ files, 40,000+ code relationships (numbers from the indexing tool)
The pattern I kept noticing
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:
- Order payment status didn't sync with order status. Customer thinks they paid, backend shows unpaid.
- Stored-value top-up plans got accidentally pushed into the packaging worksheet. The roaster was confused: "How do I package store credit?"
- 13 coffee products showed "out of stock" to consumers on the storefront, but the admin backend showed them fine (admin / anon view discrepancy).
- A VVIP customer topped up $5,000 and got the wrong bonus amount.
- After adding a "medium-dark" roast tier, the UI showed the English enum code (no translation).
- A customer ordered a "drip-bag variant of a half-pound product" and could only order 1 pack (the system calculated it as half-pound grams).
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.
The conversation that changed things
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:
- 11 chain nodes in the business flow
- 5 already well-protected
- 2 partially protected
- 4 completely unprotected BLOCKERs
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.
The 4 patterns that surfaced during the process
These 4 patterns came to me gradually during those 7 hours. They weren't known in advance. They crystallized in retrospect:
Pattern 1: "Fix a bug" vs "audit a chain" are fundamentally different mental modes
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.
Pattern 2: Decisions made with a customer present are forgotten 3 months later
These 4 BLOCKER fixes all involved a business decision:
- Should a refund go back to cash first or bonus first? (I chose cash-first. The original logic deducted bonus first, so a cash-first reversal keeps things balanced.)
- Should "roast level mismatch" block the operator or write a warning and let them continue? (I chose the latter, to avoid the operator station freezing.)
- Should packaging tasks support a "skipped" state? (I chose no, to avoid state-machine explosion.)
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.
Pattern 3: Cross-layer dependencies should be managed as assets
Software systems are full of "if I change A, I must also change B" cross-layer dependencies. For example:
- Change an RPC return shape → must sync the normalize function's whitelist → must sync the UI render side
- Change an SSOT field → must sync every caller
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):
- Register each cross-layer relationship in a markdown table
- Pair it with a "fuse test" that pins down the currently-correct behavior
- Pair it with two "auto-inspectors" (governance rules) that block regression
- Pair it with an "AI reminder" (Claude Code auto-reminds me when I'm about to edit an affected file)
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).
Pattern 4: Offense + Defense as a dual mode
Combining Pattern 1 and Pattern 3 surfaces a larger pattern:
- Offense mode (audit + fix N items at once) = proactively attacking, building new protection
- Defense mode (trace lock + auto trigger) = passively defending, blocking regression
Neither alone is enough:
- No offense → protection coverage doesn't expand, bugs keep accumulating
- No defense → existing protection rots
- Both together → the system's "entropy" moves toward decreasing
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).
What this series will cover
I plan to write:
- A1 Defensive Trace Lock: How to lock down a single cross-layer relationship (for future me; readable without a CS degree)
- B1 Offensive audit: How to periodically audit a whole business flow (for future me; readable without a CS degree)
- C1 Offense + Defense combined: How the two pair up (for future me)
- D sql-only-trace: How to test pure DB logic (engineer-facing technical detail)
- A2 / B2 / C2 Engineer versions: Engineering-grade versions of the 3 above (for engineers who might be curious, with code samples + cross-project reuse matrix)
- Index post: A "which post should you read first" map for readers
If you only read one, I'd recommend A1 (defensive). That's where this whole thing started.
Related posts
- A1 · Defensive Trace Lock (next in series)
- Series index (reading map)
- 中文版
About this post
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:
- Terms used in this post (Decision Pinning / Trace Lock / outside-in vs inside-out / offense vs defense / sql-only-trace) are working names I gave them myself, not industry-standard terminology
- My system has a specific shape (solo-maintained, many cross-layer dependencies, ambiguous business contracts). These patterns may not apply to your context
- I'm not a software engineer, just a barista who pairs with AI to write code
If a professional engineer spots misuse, or there's already a more standard name for any
of these concepts, I genuinely welcome corrections.
Top comments (0)