AI Overwrites Custom Code: Why Regeneration Destroys What You Built
Regeneration fear is a systemic failure pattern in AI-generated codebases where every new AI prompt session becomes a threat to existing custom logic. The developer writes a prompt to add a new feature. The AI regenerates the file. The custom bug fix from last week is gone. The integration patch from the sprint before that is gone. The security hardening applied after the last incident is gone.
The loss is silent. The git diff shows the new feature. It does not show what was removed. The regression surfaces in production — sometimes immediately, sometimes weeks later when the affected code path is exercised.
This is not a problem with the AI tool. It is a structural failure mode that emerges when the codebase has no mechanism for distinguishing AI-generated scaffolding from human-authored custom logic. Without that distinction, every regeneration is a full replacement — and every full replacement is a potential loss.
This page explains the mechanism, how to detect whether your codebase is at risk, and what the remediation path looks like.
Who This Is For
Founders and developers who built their application with AI tools — Lovable, Bolt.new, Cursor, Replit, or v0 — and are now experiencing one or more of the following:
- A bug that was fixed last month has reappeared in production
- A developer added a feature via AI prompt and something unrelated stopped working
- The team has started keeping a manual log of "things AI must not touch"
- Code reviews regularly surface logic that was previously present but is now missing
- The team is afraid to use AI for new features because it might break existing custom work
- A security patch or compliance fix was silently removed during a regeneration session
If this matches your situation, the root cause is almost certainly structural — not a bad prompt, not a bad AI tool, not insufficient developer oversight.
What We Observe
Regeneration fear in AI-generated codebases does not produce a single visible failure. The observable signals are distributed and often delayed:
- Recurring bugs — the same issue is fixed multiple times because each AI regeneration session restores the broken state
- Missing logic in git history — a function or validation that was present in a previous commit is absent in the current version, with no explicit deletion in the diff
- "Phantom" regressions — production incidents that cannot be traced to a specific change because the loss happened inside a larger regeneration commit
- Manual "do not touch" lists — the team maintains informal documentation of files or sections that AI must not regenerate
- Divergence between spec and implementation — the AI generates code that matches the prompt but does not match the actual business requirements that were encoded in the previous custom logic
These are not symptoms of a single bug. They are symptoms of a class of structural problems that emerge when AI-generated scaffolding and human-authored custom logic coexist in the same files without any enforced separation.
The Structural Cause
Three root causes are typically present simultaneously in codebases where regeneration fear has set in.
RC01: Architecture Drift — No Separation Between Generated and Custom Code
The fundamental structural cause of regeneration fear is the absence of a boundary between AI-generated scaffolding and human-authored custom logic. In a codebase without this boundary:
- AI-generated boilerplate and custom business logic coexist in the same file
- There is no mechanism to tell the AI "this section is protected — do not regenerate it"
- Every prompt that touches a file risks replacing the entire file, including all custom modifications
Prompt-driven development optimizes locally without global structural enforcement. The AI does not know which parts of the file were generated by a previous AI session and which were written by a human. From the AI's perspective, the entire file is context — and the entire file is replaceable.
The structural solution is explicit separation: a boundary mechanism that marks which regions of a file are AI-generated (and therefore regenerable) and which are human-authored (and therefore protected). Without this mechanism, regeneration fear is structurally inevitable.
RC02: Dependency Graph Corruption — Regeneration Breaks Implicit Contracts
When modules have circular dependencies or undocumented implicit contracts, regeneration of one file can silently break another. The AI regenerates file A according to the prompt. File B was depending on a specific function signature, a specific exported constant, or a specific side effect of file A. The regenerated version of file A changes that signature, removes that constant, or eliminates that side effect. File B breaks — not because of a bug in the new code, but because an implicit contract was violated.
The structural cause is that implicit contracts are invisible to the AI. The AI sees the file being regenerated. It does not see the downstream dependencies that rely on specific behaviors of that file. Without explicit contracts — documented, machine-readable, and enforced — every regeneration is a potential contract violation.
RC05: No Deployment Safety Net — Losses Reach Production Undetected
Without CI/CD and automated tests, the losses from regeneration reach production without any automated check. The developer regenerates a file, the tests are not run (because there are no tests), the CI pipeline does not catch the regression (because there is no CI pipeline), and the change is deployed. The loss is discovered in production — by a user, by a monitoring alert, or not at all.
The structural cause is the absence of a feedback loop. A deployment safety net — CI/CD with lint, tests, and contract validation — would catch the regression before it reaches production. Without it, every regeneration is a gamble.
Detection: How to Confirm This in Your Codebase
The following checks identify whether your codebase is structurally at risk from regeneration.
FP005: Full-File Rewrites (primary regeneration risk signal)
# Files where a single commit changed >60% of lines (last 90 days)
git log --since="90 days ago" --pretty=format:"%H %s" | while read hash msg; do
git diff-tree --no-commit-id -r --stat "$hash" 2>/dev/null | \
grep -E "\.(py|ts|tsx)$" | \
awk -v hash="$hash" -v msg="$msg" '{
added=$2; deleted=$3; total=added+deleted
if (total > 30 && added/(total+0.001) > 0.6)
print hash, total"lines", msg, $1
}'
done | head -20
Simpler check — large single-commit file changes:
git log --since="90 days ago" --stat | \
grep -E "\.(py|ts|tsx)\s+\|" | \
awk '{if ($3 > 50) print $0}' | head -20
Interpretation:
- ≥5 full-file rewrites in 90 days: finding — regeneration is the primary development pattern
- Pattern: commits with messages like "add feature X" that change 80%+ of a file are regeneration events, not incremental changes
FP017: Missing CI/CD Configuration (no safety net)
# Check for CI/CD with active test steps
echo "=== CI/CD presence ==="
ls .github/workflows/ 2>/dev/null && echo "GitHub Actions: present" || echo "GitHub Actions: ABSENT"
ls .gitlab-ci.yml 2>/dev/null && echo "GitLab CI: present" || echo "GitLab CI: ABSENT"
echo "=== Test step in CI ==="
grep -r "pytest\|jest\|vitest\|npm test\|python -m pytest" \
.github/workflows/ .gitlab-ci.yml 2>/dev/null | head -5 || \
echo "No test step found in CI configuration"
Interpretation:
- No CI/CD: critical — regeneration losses reach production without any automated check
- CI/CD present but no test step: warning — the pipeline exists but provides no protection against regeneration losses
FP018: Missing Code Preservation Markers (no protected regions)
# Check for code preservation markers (ASA-style or custom)
echo "=== Preservation markers ==="
grep -r "BEGIN USER CODE\|END USER CODE\|PROTECTED\|DO NOT REGENERATE\|@preserve\|@custom" \
--include="*.py" --include="*.ts" --include="*.tsx" \
-l 2>/dev/null | head -10 || echo "No preservation markers found"
echo "=== .cursorrules or AI governance files ==="
ls .cursorrules .aider.conf.yml .continue/config.json 2>/dev/null || \
echo "No AI governance configuration found"
Interpretation:
- No preservation markers: critical — there is no mechanism to protect custom logic from regeneration
- No AI governance files: finding — the AI has no instructions about which code regions are off-limits
What preservation markers look like in practice:
# domains/billing/calculate_overage/service.py
class CalculateOverageService:
def __init__(self) -> None:
self.repo = CalculateOverageRepository()
# === BEGIN USER CODE ===
# PROTECTED REGION — do not regenerate
def execute(self, request: CalculateOverageRequest) -> CalculateOverageResponse:
credits = self.repo.get_credits(request.user_id)
# Custom business rule: credits are stored as strings in legacy DB
overage = max(0, int(credits) - 100) * 0.005
return CalculateOverageResponse(amount=round(overage, 2))
# === END USER CODE ===
Without markers like these, the entire file is regenerable — and the custom int(credits) conversion that prevents the billing bug is silently removed in the next regeneration session.
Why This Compounds Over Time
Regeneration fear follows a predictable trajectory:
Month 1: App ships. AI regeneration is fast and productive.
Month 2: First custom logic added. No separation from generated code.
Month 3: A regeneration session removes a bug fix. Team notices, re-applies the fix.
Month 4: The same fix is removed again. Team starts a "do not touch" list.
Month 5: The "do not touch" list has 12 files. AI is effectively blocked from 40% of the codebase.
Month 6: The team stops using AI for anything except greenfield files. Velocity collapses.
The compounding mechanism is behavioral as much as structural: as regeneration losses accumulate, the team progressively restricts AI usage to avoid the risk. The tool that was supposed to accelerate development becomes a liability. By Month 6, the team is maintaining a manual governance system — the "do not touch" list — that is fragile, undocumented, and invisible to new developers.
The structural solution is to replace the manual "do not touch" list with an enforced, machine-readable governance system: preservation markers in code, AI governance files (.cursorrules), and a CI/CD pipeline that catches contract violations before they reach production.
Why Regeneration Fear Is Distinct from Regression Fear
Regression fear (P2) is caused by structural fragility: changes propagate unpredictably because architectural boundaries have eroded. Regeneration fear is caused by a different mechanism: the absence of a boundary between AI-generated and human-authored code.
The behavioral consequence is similar — the team becomes afraid to make changes — but the root cause and the remediation path are different:
| Regression Fear | Regeneration Fear | |
|---|---|---|
| Trigger | Any code change | AI prompt / regeneration session |
| Loss mechanism | Blast radius through circular deps | Full-file replacement |
| Detectable in | Circular dependency graph | Git history (full-file rewrites) |
| Primary fix | Boundary enforcement + tests | Preservation markers + AI governance |
| Safety net | CI/CD with tests | CI/CD with contract validation |
Both patterns are often present simultaneously. A codebase with regeneration fear typically also has regression fear — the same absence of structural enforcement that allows regeneration losses also allows regression cascades.
Remediation Path
Addressing regeneration fear requires establishing the boundary between AI-generated and human-authored code — and enforcing it automatically.
Phase 1 — Diagnosis (Audit) A Production Readiness Audit confirms which failure patterns are present and at what severity. For regeneration fear specifically: how many full-file rewrites are in the git history, whether preservation markers exist, and whether the CI/CD pipeline has contract validation. This takes 24 hours and produces a prioritized remediation plan.
Phase 2 — Stabilization (Core) Establish the governance layer:
- Add preservation markers to all files with custom logic that must survive regeneration
- Create AI governance files (
.cursorrulesor equivalent) that instruct AI tools which regions are off-limits - Set up CI/CD with contract validation — automated checks that detect when a regeneration has violated an implicit contract
- Establish a test baseline for the highest-risk modules
After Phase 2, regeneration is safe again. The AI can generate new code in unprotected regions. Custom logic in protected regions is preserved. The CI/CD pipeline catches any violation before it reaches production.
Phase 3 — Controlled Growth (Cap & Grow) New features are developed in isolated, independently testable modules with explicit boundaries between generated scaffolding and custom logic. The legacy code is frozen — not rewritten — and new development happens in a clean architectural zone where regeneration is safe by design.