Offense + Defense combined — How the two pair up (for self-taught developers)

A developer describes combining offensive and defensive trace-lock modes to govern AI-assisted code. Offensive audits find new cross-layer bugs, while defensive locks prevent known issues from recurring. The two modes together reduced system entropy for the first time in the project.

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