Dead Code Surgeon - Phased Codebase Audit & Cleanup Roadmap

a senior software architect specializing in codebase health and technical debt elimination.

Category	Development › Coding
Tags	AnalyzingReviewingDeveloperCodeChecklist

Prompt

You are a senior software architect specializing in codebase health and technical debt elimination.
Your task is to conduct a surgical dead-code audit — not just detect, but triage and prescribe.

────────────────────────────────────────
PHASE 1 — DISCOVERY  (scan everything)
────────────────────────────────────────
Hunt for the following waste categories across the ENTIRE codebase:

A) UNREACHABLE DECLARATIONS
   • Functions / methods never invoked (including indirect calls, callbacks, event handlers)
   • Variables & constants written but never read after assignment
   • Types, classes, structs, enums, interfaces defined but never instantiated or extended
   • Entire source files excluded from compilation or never imported

B) DEAD CONTROL FLOW
   • Branches that can never be reached (e.g. conditions that are always true/false,
     code after unconditional return / throw / exit)
   • Feature flags that have been hardcoded to one state

C) PHANTOM DEPENDENCIES
   • Import / require / use statements whose exported symbols go completely untouched in that file
   • Package-level dependencies (package.json, go.mod, Cargo.toml, etc.) with zero usage in source

────────────────────────────────────────
PHASE 2 — VERIFICATION  (don't shoot living code)
────────────────────────────────────────
Before marking anything dead, rule out these false-positive sources:

- Dynamic dispatch, reflection, runtime type resolution
- Dependency injection containers (wiring via string names or decorators)
- Serialization / deserialization targets (ORM models, JSON mappers, protobuf)
- Metaprogramming: macros, annotations, code generators, template engines
- Test fixtures and test-only utilities
- Public API surface of library targets — exported symbols may be consumed externally
- Framework lifecycle hooks (e.g. beforeEach, onMount, middleware chains)
- Configuration-driven behavior (symbol names in config files, env vars, feature registries)

If any of these exemptions applies, lower the confidence rating accordingly and state the reason.

────────────────────────────────────────
PHASE 3 — TRIAGE  (prioritize the cleanup)
────────────────────────────────────────
Assign each finding a Risk Level:

  🔴 HIGH    — safe to delete immediately; zero external callers, no framework magic
  🟡 MEDIUM  — likely dead but indirect usage is possible; verify before deleting
  🟢 LOW     — probably used via reflection / config / public API; flag for human review

────────────────────────────────────────
OUTPUT FORMAT
────────────────────────────────────────
Produce three sections:

### 1. Findings Table

| # | File | Line(s) | Symbol | Category | Risk | Confidence | Action |
|---|------|---------|--------|----------|------|------------|--------|

Categories: UNREACHABLE_DECL / DEAD_FLOW / PHANTOM_DEP
Actions   : DELETE / RENAME_TO_UNDERSCORE / MOVE_TO_ARCHIVE / MANUAL_VERIFY / SUPPRESS_WITH_COMMENT

### 2. Cleanup Roadmap

Group findings into three sequential batches based on Risk Level.
For each batch, list:
  - Estimated LOC removed
  - Potential bundle / binary size impact
  - Suggested refactoring order (which files to touch first to avoid cascading errors)

### 3. Executive Summary

| Metric | Count |
|--------|-------|
| Total findings | |
| High-confidence deletes | |
| Estimated LOC removed | |
| Estimated dead imports | |
| Files safe to delete entirely | |
| Estimated build time improvement | |

End with a one-paragraph assessment of overall codebase health
and the top-3 highest-impact actions the team should take first.

What this prompt does

Useful for classifying cleanup candidates before reducing technical debt. It asks the reviewer to rule out false positives such as reflection, DI, serialization, public APIs, and framework hooks.

Model comparison

ChatGPT is strongest because it states scope limits and handles false positives cautiously. Gemini is well structured but double-counts and overclaims, while [C] provides no answer.

ChatGPTTop overall

44/ 50

＋ Clearly scopes the audit and carefully handles public-API false positives.

－ Classifying calculateDiscount as an untouched import is somewhat inaccurate.

Gemini

38/ 50

＋ Presents all three required sections with a clear cleanup sequence.

－ It rules out side effects and external use, then overstates size savings.

Criterion	ChatGPT	Gemini	Leader
Instruction following	9	8	ChatGPT +13%
Accuracy	8	6	ChatGPT +33%
Specificity	9	8	ChatGPT +13%
Structure	9	9	Tie
Right length	9	7	ChatGPT +29%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-25). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used

[Pasted material]
// src/services/orderService.ts
import { sendSlackAlert } from '../utils/slackNotifier'; // 3개월째 미사용
import { calculateDiscount } from '../utils/discount';

const ENABLE_BETA_PRICING = false; // 작년부터 하드코딩

export function getFinalPrice(order: Order) {
  if (ENABLE_BETA_PRICING) {
    return calculateDiscount(order, 0.3);
  }
  return order.totalAmount;
}

export function legacyRecalculatePoints(userId: string) {
  // 2023 포인트 개편 이후 아무도 호출 안 함
  return userId.length * 10;
}

export function processOrder(order: Order) {
  if (!order.items.length) {
    throw new Error('empty order');
    console.log('unreachable'); // 도달 불가
  }
  return getFinalPrice(order);
}

gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

아래 결과는 제공된 src/services/orderService.ts 스니펫만 대상으로 한 감사입니다. 전체 저장소의 호출부, 설정 파일, 패키지 매니페스트를 확인할 수 없어 외부 소비 여부는 별도 검증이 필요합니다.

1. Findings Table

#	File	Line(s)	Symbol	Category	Risk	Confidence	Action
1	`src/services/orderService.ts`	1	`sendSlackAlert`	PHANTOM_DEP	🟡 MEDIUM	99%	DELETE
2	`src/services/orderService.ts`	4, 7–9	`ENABLE_BETA_PRICING` / beta branch	DEAD_FLOW	🔴 HIGH	100%	DELETE
3	`src/services/orderService.ts`	2	`calculateDiscount`	PHANTOM_DEP	🔴 HIGH	100%	DELETE
4	`src/services/orderService.ts`	21	`console.log('unreachable')`	DEAD_FLOW	🔴 HIGH	100%	DELETE
5	`src/services/orderService.ts`	13–15	`legacyRecalculatePoints`	UNREACHABLE_DECL	🟢 LOW	70%	MANUAL_VERIFY

판정 근거:

sendSlackAlert는 파일 내 참조가 없습니다. 단, 해당 모듈의 import 자체가 초기화 부작용을 제공한다면 제거 전 확인이 필요합니다.
ENABLE_BETA_PRICING은 리터럴 false이므로 beta 가격 계산 분기는 현재 실행될 수 없습니다.
위 분기를 제거하면 calculateDiscount import도 함께 제거할 수 있습니다.
throw 이후의 console.log는 도달 불가능합니다.
legacyRecalculatePoints는 파일 내부 호출이 없지만 export된 공개 API입니다. 동적 라우팅, 외부 패키지 소비, 문자열 기반 호출 가능성 때문에 즉시 삭제하면 안 됩니다.

2. Cleanup Roadmap

Batch 1 — 🔴 HIGH

대상: beta 분기, ENABLE_BETA_PRICING, calculateDiscount, unreachable 로그
예상 제거량: 약 5–6 LOC
번들/바이너리 영향: 매우 작음. 해당 모듈과 할인 유틸리티가 다른 곳에서도 사용되지 않는 경우에만 추가 절감 가능
순서:
1. beta 분기 제거
2. calculateDiscount import 제거
3. throw 이후 로그 제거
4. 타입스크립트 빌드 및 테스트 실행

Batch 2 — 🟡 MEDIUM

대상: sendSlackAlert import
예상 제거량: 약 1 LOC
번들/바이너리 영향: notifier 모듈이 이 파일에서만 로드된다면 소폭 감소
순서:
1. slackNotifier의 모듈 초기화 부작용 확인
2. 저장소 전체에서 sendSlackAlert 참조 검색
3. import 제거 후 빌드 검증

Batch 3 — 🟢 LOW

대상: legacyRecalculatePoints
예상 제거량: 약 4 LOC
번들/바이너리 영향: 외부 소비자가 없다면 소폭 감소
순서:
1. 전체 저장소 호출 검색
2. 라우터, DI 설정, 문자열 기반 레지스트리 확인
3. 공개 API/패키지 소비자 확인
4. 사용처가 없을 때 삭제

3. Executive Summary

Metric	Count
Total findings	5
High-confidence deletes	3
Estimated LOC removed	약 6–10 LOC
Estimated dead imports	2
Files safe to delete entirely	0
Estimated build time improvement	측정 불가할 정도로 미미함

전체 코드베이스 기준 건강도를 확정하려면 실제 저장소 전체의 import/call graph, 패키지 매니페스트, 라우팅·DI·설정 파일을 추가로 확인해야 합니다. 현재 스니펫에서는 오래된 beta 기능 플래그와 명백한 도달 불가 코드가 가장 확실한 기술 부채입니다.

우선순위는 다음 세 가지입니다: beta 가격 분기 제거, throw 이후 로그 제거, legacyRecalculatePoints의 외부 공개 API 사용 여부 확인.

More in this category

12-Month AI and Computer Vision Roadmap for Defense Applications
2046 Puzzle Game Challenge
21st.dev component prompt
3D FACTORY
3D FPS Game

Popular

Categories