# Offense + Defense combined — How the two pair up (for self-taught developers) > Source: > Published: 2026-07-29 14:05:15+00:00 **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 fix`trace-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)*