DEV Community

Zac
Zac

Posted on • Originally published at builtbyzac.com

Working with legacy code in Claude Code (understanding before changing)

New greenfield projects are easy with Claude Code. The harder, more valuable use case is legacy codebases — no tests, inconsistent conventions, functions everyone is afraid to touch.

This is where Claude Code earns its keep.

Understanding code you didn't write

Read this code and explain:
1. What it does at a high level
2. What inputs it expects and what it returns
3. What assumptions it makes about the data
4. What would break if [specific change]

Don't suggest improvements yet — just understand it first.
Enter fullscreen mode Exit fullscreen mode

The "don't suggest improvements" instruction prevents Claude from jumping to "this should be refactored" before understanding what it does.

Finding the blast radius

If I change [function/variable/type], what else might break?
Look for:
- Direct callers
- Indirect dependencies
- Anything that assumes specific behavior

Don't change anything — just map what would need to change.
Enter fullscreen mode Exit fullscreen mode

This blast radius map is more valuable than any refactor.

Adding tests to untested code (characterization tests)

Write tests for this function that capture its current behavior —
including any behavior that might be wrong.

Do not fix bugs in the tests. If the function returns null in an
edge case that seems like a bug, write a test that expects null.

Then flag any behavior that looks like it might be a bug.
Enter fullscreen mode Exit fullscreen mode

This locks in current behavior before refactoring. If you change behavior unintentionally, the tests catch it.

Safe incremental refactoring

Refactor this function. Rules:
1. Make one change at a time
2. Each change should leave tests passing
3. No change should affect external behavior

Show me the first change and stop. We'll review before continuing.
Enter fullscreen mode Exit fullscreen mode

The "show me the first change and stop" is critical. Claude's instinct is to refactor everything in one pass.

When to leave it alone

Given the current behavior and blast radius of this code,
is there a good reason to refactor it now? What would we gain?
What's the minimum change to accomplish [goal] without touching anything else?
Enter fullscreen mode Exit fullscreen mode

Sometimes the right answer is "don't touch it." Claude is good at making that case.


Legacy code prompts — characterization testing, blast radius analysis, safe refactoring — are in the Agent Prompt Playbook. $29.

Top comments (0)