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

> Source: <https://dev.to/dexterlung/i-built-a-vertically-integrated-commerce-system-with-ai-and-accidentally-discovered-4-governance-hdk>
> Published: 2026-07-30 14:05:11+00:00

**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**.