AI Coding Agents
Code Maintenance
Dead code removal with coding agents
September 22, 2026 - 2 minute read
Dead code removal with coding agents can reduce maintenance cost, build work, and misleading search results. The risk sits in code that appears unused to static analysis but remains reachable through configuration, reflection, dynamic imports, framework conventions, plugins, or external consumers. Safe deletion needs several independent signals and a patch small enough to review.
Compiler diagnostics provide one useful signal. TypeScript’s noUnusedLocals option reports errors for unused local variables. That result is deliberately narrower than whole-program reachability, and exported symbols need additional evidence.
Establish that the code is unreachable
Start with the repository’s compiler, linter, dependency graph, and test coverage. Search direct references, string references, configuration keys, command registrations, routes, dependency injection bindings, and generated manifests. Check other repositories when the package exposes a public or internal API.
Version-control history explains why code exists. A feature flag may still support rollback. A migration utility may be needed only during disaster recovery. A handler with no direct caller may be discovered by a framework. Read ownership files and deployment configuration before classifying those paths as dead.
Ask the coding agent to record each signal and its limits. “No text matches” is weak evidence. A compiler warning, no package consumers, an expired flag, an absent runtime registration, and confirmation from the owning team form a stronger case.
Delete in reviewable slices
Remove one coherent path at a time. Delete its tests and documentation only when they exist solely for that path. Keep tests that protect shared behavior. Regenerate lockfiles, API clients, indexes, or snapshots with the repository’s documented commands rather than editing generated output by hand.
Avoid combining deletion with broad formatting or redesign. A focused diff lets reviewers see removed entry points, fallbacks, and side effects. It also makes a revert practical if production evidence contradicts the reachability analysis.
Factory’s local code review can inspect uncommitted changes, a commit, or a branch against its base. Custom review instructions can focus on surviving references, framework registration, public exports, initialization side effects, and tests that were weakened with the deletion.
Validate absence and behavior
Run type checking, linting, focused tests, and the relevant build after deletion. Exercise runtime discovery paths such as routes, plugins, scheduled jobs, command registries, and dependency injection. Search the built output when the goal includes reducing bundle or package contents.
Compare observable behavior before and after the change. For a removed endpoint, confirm it was already unreachable or explicitly retired. For a removed dependency, verify the lockfile and production bundle. For a deleted feature-flag branch, test the surviving state and remove stale configuration through the team’s normal process.
Factory’s automated code review can apply repository-specific checks on the pull request. Keep static analyzers and builds as deterministic gates, while the review explains gaps those tools cannot see.
The pull request should list the removed entry points, reachability evidence, generated updates, and validation commands. Mark uncertain consumers as blockers. Leaving a small amount of questionable code is safer than deleting a hidden contract on incomplete evidence.
