Quick answer: Rename the variable after the domain value it holds, not the ticket that prompted the change. A name such as JIRA4521Total makes sense while the ticket is open and loses all meaning a month later, when the code still has to be read. Keep the ticket reference in the commit message and branch, and give the identifier a name that describes the data.

Why agents reach for ticket-number names

The agent gets its context from the prompt, and that prompt usually leads with the ticket. "Implement refund cap for PD-4521" gives the model a strong anchor, so it names things after the anchor: PD4521Cap, ticket4521Eligible, jira4521Refund. The code is correct and the build passes, which is why the naming slips through; it is not a logic error, so a test will never catch it.

The name looks useful in the pull request because every reviewer has the ticket open. Six months later, the same identifier reads like a random string. Nobody remembers what 4521 was, and the name now hides the one thing a reader needs: what the variable actually represents.

Why these names decay

A ticket number is temporary metadata. It tracks a unit of work, then closes, and the code it produced keeps living. When the number is welded to an identifier, the costs show up over time. Searching the codebase for the business concept returns nothing, because the variable is named after a tracker id. The next change to the same feature, under a different ticket, produces a parallel name such as PD7890Cap, so one concept has two names. The tracker id also leaks internal workflow into code that may be shared or read by people without access to the ticketing system.

How the review flags temporary names

The code review's structure filters flag temporary-name candidates alongside the diff, so an identifier built from a ticket prefix, a date, or a short-lived branch term is called out instead of waiting for a human to notice. The review is built on local Git differences plus parsers that resolve definitions, callers, and imports, which means the flag comes with the evidence of where the name is declared and used. The inline review returns a priority, evidence, and a recommendation; it can raise a false suspicion or miss one, so confirm the finding against actual usage.

Ticket-style names versus domain names

Ticket-style name Domain name Why the rename helps
JIRA4521Total refundTotal Says the value is a refund amount, not a tracker item
PD4521Cap maxRefundAmount Describes the rule and its unit, stays valid after the ticket closes
ticket4521Eligible isEligibleForRefund Reads as a boolean predicate in any context
bug9012User lockedAccount Names the account state, not the incident that exposed it
hotfix33Result retryOutcome Captures the outcome instead of the urgency of the change

Renaming safely

A rename is only safe when every reference moves together. Use the parser's caller and import resolution to find the usages, then rename the declaration and all references together so the identifier never has two names. Resist the urge to also refactor the logic in the same diff; a pure rename is easy to review, while a rename mixed with behavior changes is where defects hide. If the same name appears in serialized data, logs, or an external contract, leave those boundaries alone and rename only the internal identifier, since changing a wire field can break callers.

The review has honest limits here. A file with no resolved incoming reference is not proof that nothing uses it, because dynamic loading and framework entry points can be missed. Two pieces of text that look identical do not prove the behavior is interchangeable. Treat the flag as a lead, verify the callers, and keep the rename scoped to what the parser can account for.

Powerduck shows the temporary-name candidate next to the diff with its references, and can export a handoff package so a coding agent performs the rename with the caller context attached. For more on this workflow, see the guide to reviewing AI coding agents.

Frequently asked questions

Where should the ticket number live if not in the variable? In the branch name, commit message, and pull request. Those places track the work; the identifier should track the data.

Does renaming break the build? Not when the declaration and every resolved reference move together. Run the build and tests after the rename; if a script is missing, the check is unverified rather than passed.

What if the tracker id is part of an external contract? Do not rename wire fields or log keys that other systems depend on. Keep the external name and rename only internal variables.

The bottom line

The ticket closes; the code stays. Naming a variable after a ticket number trades one week of convenient context for years of opaque identifiers, and tests will never flag it. Rename after the domain value, keep the ticket in the commit, and make the change a clean, reference-complete rename so the next reader can tell what the value is without opening a tracker.