Should we still budget time for refactoring manually, or is "regenerate it" now cheaper than maintaining it?

The shift

Producing a plausible full rewrite of a module — given the existing code, its tests, and its history as context — goes from scarce (weeks of senior engineer time) to abundant (minutes, near-zero marginal cost, and cheap to generate several competing versions). What stays scarce is confirming the rewrite preserves every behavior the old code actually had, including the undocumented edge cases nobody wrote a test for.

The axioms

• Refactoring requires deep understanding of the existing code before touching it — scarce expert comprehension time.
• Old code encodes institutional knowledge (bug fixes, edge cases, workarounds) that isn't written down anywhere else — scarce tacit specification.
• Incremental refactoring is safer than rewriting because each step is small enough to review — scarce human review bandwidth, spent in small batches.
• Technical debt compounds, so paying it down earlier is cheaper than later — a claim about scarce engineering time being allocated against a growing liability.
• Test coverage is the ground truth for "did we break anything" — and coverage is usually incomplete, so passing tests is necessary but not sufficient.
• Someone is accountable when a change breaks production — scarce liability that has to sit with a specific person or team.

Invalid axioms

1. Refactoring must be incremental because rewrites are too expensive to attempt. The cost asymmetry that made "small, reviewable diffs" the only safe path is gone — a model can produce a full rewrite of a bounded module in minutes, cheaply enough to throw away and retry. The habit-trap: teams still default to ticket-sized refactors and multi-sprint migration plans sized for a world where a rewrite cost a person-month, when for many modules regenerate-and-diff is now the faster, cheaper first move.
2. Understanding the existing code before touching it is the expensive, gating step. Reading and summarizing a large, messy module — what it does, where the landmines are — used to require a senior engineer's sustained attention. A model can now produce that map in minutes, including cross-references across a whole repo. The habit-trap: assigning "ramp-up time" to refactor a legacy module as if comprehension were still the bottleneck, instead of treating comprehension as a cheap first pass and spending the saved time on verification.
3. Technical debt should be paid down opportunistically, in small increments, because a full fix is too costly to schedule. When rewriting a module is cheap, "small increments now" stops being the economical path for a lot of debt — regenerating the module wholesale against its current tests and specs can be faster than years of incremental patching. The habit-trap: roadmaps still ring-fence "20% time for tech debt" sized for manual refactor-by-hand, rather than sizing for a regenerate-and-verify cycle.

Unchanged axioms

1. Old code encodes tacit specification that isn't written down anywhere else. The scarce thing was never the code's structure — it was the accumulated knowledge of what actually happens in production: the currency-rounding edge case fixed three years ago, the retry logic added after an outage, the input a specific customer sends that nothing documents. A model regenerating the module from a prompt or even from the old source has no way to know these unless they're captured in tests, comments, or someone's memory. Regeneration is only as safe as the specification feeding it, and for most legacy code that specification is incomplete by definition — verification against real-world behavior stays scarce.
2. Someone is accountable when the regenerated version breaks something the old version handled. A model can produce ten plausible rewrites; it cannot be the one who gets paged, who explains the incident, or who owns the decision to ship. That accountability doesn't get cheaper just because generation did — if anything the bar rises, because "the AI wrote it" is not an acceptable answer to "why did this break," which keeps a human in the loop sized to actually understand and sign off on the diff, not just skim it.
3. Judgment about which module is safe to regenerate wholesale versus which one is too load-bearing to risk is still a human call. Novel, high-stakes ambiguity — a payments core, an auth flow, a scheduler with subtle race conditions — is exactly where a confidently wrong rewrite does the most damage and where there's no clean pattern to match against. Deciding where regeneration is appropriate and where it isn't remains a scarce, judgment-heavy call, not a default.

New axioms

1. Verifying a regenerated module at the speed it can now be produced. When a rewrite takes ten minutes but confirming behavioral parity takes a week of manual testing, the bottleneck just moved from writing to checking, and most teams don't have a verification pipeline (property tests, shadow traffic, diffing against production behavior) fast enough to keep up. Building that pipeline is now the actual constraint, and it doesn't yet have an obvious owner or standard practice.
2. Deciding whether "cheaper to regenerate" is actually cheaper once verification, migration, and rollback risk are priced in. Generation cost dropping to near-zero makes the total cost equation look completely different than it did when generation was the dominant cost — but nobody has good intuition yet for where the new breakeven sits, and it's easy to under-price the verification tail because the generation step feels so fast and free.
3. Preventing regenerate-it from becoming a way to avoid understanding the system at all. If regeneration is cheap enough to attempt repeatedly, there's a temptation to skip comprehension entirely and just keep re-rolling until tests pass — which produces code nobody, human or model, actually understands, and quietly re-creates the same tacit-knowledge problem one layer down.

Where it breaks

"Rewrite the module, it's cheap now" (invalid) collides with "the tacit specification lives only in the old code and nobody wrote it down" (still holds): teams that regenerate a legacy module because the generation step got cheap, without first extracting or testing for the undocumented behavior the old code silently handled, ship a plausible-looking replacement that quietly drops edge cases — and won't find out until the specific customer or condition that depended on them hits production.

"Comprehension is now cheap, so skip the ramp-up" (invalid) collides with "verification speed hasn't caught up to generation speed" (new): teams that skip slow-and-careful manual understanding because a model can summarize the code instantly are also the teams most likely to lack the test harness needed to catch what the summary missed — the two shortcuts compound instead of cancel.

ai-axioms.vercel.app/axioms/engineering/swe-refactoring-vs-regenerate-ai-axioms