Coding Copilots: The Shredding Edge of Innovation

The spark: an unexplained 11.67

A team taking over code I had written more than a decade earlier asked why one calculation multiplied by 11.67. I expected to search my memory for some old business rule. Instead, the number stumped me.

The constant had appeared in a SQL rewrite of an older PowerShell script. It did not appear in the original codebase, and the developer reviewing the rewrite stopped rather than accepting it. That pause kept an unexplained number out of production logic.

We found a stale comment in the original script: “calculate an adjustment factor later.” I had done that work years ago, but never removed the note. The comment was a plausible clue, but we did not reconstruct the model’s exact internal path to 11.67. The observed facts were enough: the assistant proposed a new constant, the code did not justify it, and an old comment remained where a future reader could mistake it for current intent.

That is the risk worth naming. In a legacy repository, comments, TODOs, docstrings, and abandoned questions can become part of the context an AI assistant receives. They may be useful evidence, stale debris, or both. A team still has to decide which is which.

Why legacy context changes the task

Code assistants can make a repository easier to explore and change. They can also make unresolved context more consequential by bringing it forward into a proposed rewrite. The problem is not that every comment is dangerous or that assistants always follow comments literally. The problem is that a plausible-looking change can carry forward an assumption no one has recently checked.

NIST’s current guidance for AI-assisted development emphasizes requirements, traceability, testing, and human review. That is a useful frame here: AI-generated changes should be reviewable with the same seriousness as human changes, especially when the repository contains unknown history. NIST DevSecOps guidance

Two illustrative failure modes

These fragments are illustrative. They are not claims about a particular product’s guaranteed behavior.

An unanswered question becomes a feature

// Should finance normalize VAT? Decision still open.
function calculateTotal(amount) {
  return amount;
}

An assistant asked to “clean this up” might propose a VAT calculation. The code review question is not whether that calculation looks sensible. It is whether someone actually made the business decision.

A stale TODO changes security behavior

# TODO: remove the test-only auth bypass after integration tests pass.
def process_request(request):
    return handle(request, bypass_auth=True)

A rewrite can preserve the bypass as legacy behavior or remove it as if the TODO were a current requirement. Either choice needs a human decision and a test that makes the intended security behavior explicit.

Treat repository text as input

Before a broad AI-assisted refactor, do a short context pass:

• Resolve, archive, or explain stale TODOs and questions.
• Compare high-value comments and docstrings with current behavior and tests.
• Record decisions that a later maintainer should not have to infer.
• Ask for bounded changes, not “modernize everything.”
• Add invariants or regression tests before accepting a rewrite of business logic.

None of this requires a perfect repository. It requires enough honest context that a reviewer can tell a current rule from an archaeological artifact.

Scale the response to the risk

Individual engineers

Keep a compact review checklist for invented constants, changed error behavior, side effects, and hidden assumptions. When a copilot proposes a value or helper that the code does not explain, ask where it came from before improving its style.

Small teams

Use issue IDs or expiration dates for TODOs that matter. Do a quick debris scrub before large refactors, and keep a lightweight decision log for the rules people repeatedly need to rediscover.

Larger organizations

Make reliable context easier to find than unreliable context. Curated architecture notes, ownership information, test evidence, and clear requirements give reviewers and AI assistants a better starting point than a raw repository search alone.

Closing thought

The useful question is not whether to let copilots read legacy code. They already can help with it. The question is whether we leave behind signals that another person can verify.

Clean intent does not eliminate the need for judgment. It makes judgment faster, more visible, and less likely to be shredded by a comment nobody meant to keep.