Inline code that reproduces what a named function in the codebase already does — a boolean check `candidate >= low && candidate <= high` when `between(value, low, high)` exists.
The agent finds inline code that reproduces the body of a named function elsewhere in the codebase; consistency depends on both implementations staying in sync.
When inline code reproduces what a named function already does, the inline copy is replaced by a call.
One canonical implementation the agent loads once and references everywhere; the name labels the intent at every call site.
Before the refactoring
const inRange = candidate >= low && candidate <= high;
After the refactoring
const inRange = between(candidate, low, high);
Two implementations of the same thing drift over time; bug fixes don't propagate; future readers wonder if the inline version is intentionally different.
Two implementations drift over time; the agent verifying changes must update both or risk inconsistency the type checker doesn't catch.
If the existing function's name doesn't quite match the local intent, the call site reads as a near-miss; consider Change Function Declaration first.
If the existing function's name doesn't quite match the local intent, the agent reads the call site as a near-miss and must verify the semantic match at every replacement.
One canonical implementation; the name labels the intent; future improvements to the function reach every site that used to inline.
The agent reasons about one definition; future improvements reach every site that used to inline; consistency is enforced by reference.
Replacing inline code with a call to an existing function whose name doesn't quite match — the call site reads as a near-miss instead of as exactly what's happening.
Replacing inline code with a call to a poorly-named function smears semantic mismatch across the codebase — the agent must constantly verify that the function's name still describes the local use.