May 2026 · Series "Trace Lock — Governance notes from pairing with AI to write code" · Post 4 of 9
The previous two posts covered the two trace-lock modes separately:
This post covers "how the two pair up." It's also what I saw when I looked back after the offensive sprint Claude and I finished over the past 2 weeks.
This is still the plain-language version for self-taught developers. Engineering details (cross-project reuse matrix, what counts as transferable helper patterns, governance rule templates) go into C2 (engineer-facing).
After writing the A1 post and re-reading it, I noticed a gap:
The defensive mode sounds complete on its own. Five artifacts, registry, fuse test, two governance rules, AI reminder skill. Locking one cross-layer relationship takes 30-45 minutes. By the 7th lock, the total time invested breaks even.
But there's an unanswered question: How do I know which relationships still need locking but haven't been locked yet?
The defensive mode answers "how to lock a known relationship." It assumes you already know which one will break. But most of the time I have no idea how many cross-layer relationships my codebase actually contains, let alone which ones are most dangerous.
It took the 5th cross-layer bug on May 25th for me to stop and ask Claude "should I go looking for other leaks of the same shape." That question opened the offensive sprint, expanding from 13 known traces to 17 plus fixing 4 BLOCKERs.
In other words: without offensive, defensive only reacts to bugs already hit. Without defensive, the BLOCKERs offensive finds get re-fixed next month. The two are one set; neither is complete alone.
Claude and I summarized the two roles in this table:
| Dimension | Offensive (B1) | Defensive (A1) |
|---|---|---|
| Trigger | I say "audit the whole X chain" | I (or AI) touch any node listed in trace nodes |
| Frequency | Once a month or quarter (planned, low frequency) | Every code change auto-triggers (high frequency) |
| Output | N new traces locked (range expansion) | Existing traces don't rot (range maintenance) |
| Target | A whole business flow (containing N chain nodes) | A single trace (one node in one chain) |
| Cost per use | 7-15 hours (audit + fix + summary) | 30-45 minutes (5-step checklist) |
| Cost of not having it | Trace count stays flat, always chasing known bugs | Existing traces rot, fixing one breaks another |
The division is clean. Offensive handles "advancing into new territory." Defensive handles "holding territory already taken."
When Claude and I discussed ROI, I sketched another mental model. System entropy (total bugs + hidden debt) over time:
I only saw this picture after the sprint was done. While writing the code I was just thinking "fix these 4 BLOCKERs," not realizing system entropy had actually started trending down for the first time.
Pulling the past 2 weeks onto a timeline:
Day 1 (defensive emerges):
Day 2-3 (defensive expands to 13 traces):
Day 4 (offensive emerges):
Day 4-5 (offensive sprint):
Day 6 (the dual-blade insight):
Total 17 days, including 4 blog posts of writing, around 50-60 hours of pure governance investment.
After locking my first 13 traces, I had a brief "OK that's probably enough" illusion.
The reality: those 13 were all "known bugs hit in the past 6 months." A bug I lock is one a customer already tripped on. Bugs not yet hit are completely outside the defensive perimeter.
Stopping there, 6 months later I'd hit bug #14, #15, each taking 3-5 hours to fix, then backfilled into the registry. Defense scope always trails the bugs. At best, you break even.
Suppose I run an offensive audit every quarter, find 5 BLOCKERs, fix them all. But I have no defensive registry, no tests, no governance rules.
3 months later, I (or an AI) change some internal logic of a helper. No fuse test fails. No governance rule warns. The change ships to prod, no one notices. The next audit re-discovers this as a new BLOCKER.
The offensive sprint becomes "perpetually re-fixing the same set of bugs." Marginal cost never goes down.
Offensive audit
↓
Find N BLOCKERs
↓
Decision Pinning
↓
6-piece fix + add to defensive registry
↓
Defensive maintains daily (fuse test + governance + skill)
↓
Next quarter's offensive doesn't re-find these N, only finds new candidates
↓
Coverage expands continuously, marginal cost drops
Run this loop for 6-12 months, codebase shifts from "decays as I change it" to "stabilizes as I change it."
The next context I'd try this in is a different project (if I take on consulting work). Predicting in advance:
Directly copyable (framework layer):
Not copyable (content layer):
In short: 80% framework transfers, 20% content must be re-invented.
Time estimate for moving to a new project: ~4-6 hours to set up framework + first trace. Each subsequent trace takes about the same as in the original project (30-45 minutes).
There's a risk in writing this far. Readers might think "every project should use trace lock." That's not what I'm claiming.
Scenarios I can think of where it doesn't fit:
If your project matches any of those, you don't need this. Trace lock works best for "many cross-layer dependencies + ambiguous business contracts + AI pair programming." It's not a universal solution.
If you decide to try the dual-blade approach, the order I'd recommend:
Not sure if it's worth the investment? My own heuristic: have you had ≥ 3 "cross-layer contract drift" bugs in the past 6 months? Yes → worth it. No → maybe not yet.
I'm not sure if this threshold generalizes. But under 3, fixing one at a time might be cheaper than building governance.
Both ends of the dual-blade are AI-friendly:
business-flow-audit-fix
skill that auto-runs the 11-node × 3-question audit + 6-piece fixtrace-lock-modify
skill auto-triggers, reminds it to run the fuse test firstI don't have to re-explain governance rules each time. Skill written once, AI inherits it next session.
Compared to "please AI be more careful" (which is not executable), "write the audit flow into a skill so AI auto-runs it" is an executable engineering intervention.
The next few posts rewrite the plain-language content from an engineering angle (for engineers who've written governance rules / pinning tests):
If you're an engineer who wants implementation details after reading this, those 4 posts are for you.
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.
本文原載於我的部落格： Offense + Defense combined — How the two pair up (for self-taught developers)