Quiet Behaviour Changes

A refactor is supposed to change how code reads and nothing about what it does. An agent that tidies code on the way to a task often changes a rule as well, a rounding mode, a boundary or a default, and no test notices, because no test covered that rule. The change is quiet because nothing checks it, not because it is clever.

The refund diff carried two of these. Neither was asked for, neither failed a test, and each one changes what a member is paid. They are the reason Chapter 6 asked you to write a before-and-after rule for every changed expression.

The Shape

The line nobody asked to change sits inside code everyone agreed could be touched. The task named the refund function, so the refund function was in scope, and the agent rewrote more of it than the task needed, "for readability". Agents reorganise surrounding code freely unless told not to, and every rewritten line is a chance to swap the project's deliberate choice for the common idiom.

Nothing about the result looks wrong. The new line is shorter, more familiar and often what a style guide would suggest. The only way to see the change is to state what the old line did and what the new one does, as rules, and compare them.

In the refund diff both quiet changes sit in the refunds file, inside the one hunk, about 30 lines long, that also wrapped the refund decision in the new policy check. A reviewer who reads that hunk for its purpose, "now uses the policy", reads past both. That is the general pattern: a quiet change rides inside a larger change that has an obvious purpose, and the purpose is what the eye follows.

The Rounding Case

Cragmoor sells three-class packs. When a member cancels one class of a pack, the refund is a third of what they paid, and the finance team's rule is that the amount rounds down to the cent. For a pack bought for $50.00, the numbers this page uses, one class refunds $16.66. The refund diff rewrote the amount function, and the new version rounds to the nearest cent instead.

 def class_share_cents(booking: Booking) -> int:
     """One class's share of what the member paid."""
-    return booking.paid_cents // booking.classes
+    return round(booking.paid_cents / booking.classes)

16.66
16.67

 export function classShareCents(booking: Booking): number {
-  return Math.floor(booking.paidCents / booking.classes);
+  return Math.round(booking.paidCents / booking.classes);

16.66
16.67

   public static long classShareCents(Booking booking) {
-    return booking.paidCents() / booking.classes();
+    return Math.round((double) booking.paidCents() / booking.classes());

16.66
16.67

One cent per pack refund, in the member's favour, on every pack refund from the deploy onwards. No test covered packs, so the suite gave the same result before and after. The change is one line, it sits inside a hunk of about 30 lines that rewrote most of the refunds file, and its new form is exactly what most engineers would write if asked to divide money by three.

The Boundary Case

The second quiet change is worse. The old rule refunded a cancellation made at least 24 hours before the class. The task changed 24 to 12. Inside the block the agent re-indented to wrap in its new policy check, "at least" also became "more than". In code that is one character in a comparison.

Nobody asked for it and nothing failed, because no test cancelled at exactly the boundary. A member who cancels exactly 12 hours before the class is now refused, against Ines's ruling that "up to 12 hours" includes the twelfth hour. Chapter 8 adds the test that would have failed.

Why It Happens

The agent writes the most common way to say a thing. The most common rounding in public code is to the nearest, and the most common comparison against a limit is strict. A codebase's deliberate exceptions are, by definition, uncommon, so to a model they look like mistakes, and a model asked to tidy code "corrects" them.

The same pull towards the common form shows up everywhere a codebase made a choice. A range that includes its end becomes one that excludes it. A sort that kept equal items in their original order becomes one that does not promise to. A default of "no refund" becomes a default of "full refund", because the agent read the parameter's name and guessed. Trimming whitespace from a member's name, treating an empty string as missing, comparing names without regard to case: each is a reasonable idiom, and each is a rule change if the code had chosen otherwise.

Nothing in the code told the agent otherwise. The round-down had no comment and no test; the inclusive comparison had no test at its boundary. A line that carries a business decision looks exactly like a line that carries an accident unless something says which it is.

Catching It

Keep refactors and behaviour changes in separate commits, the rule Chapter 9 enforces with one task per branch. A pure refactor can then be checked against tests that pin current behaviour, the method Chapter 11 builds, and declared "no behaviour change" with evidence. A refactor mixed into a behaviour change can only be declared tidy.

In review, write a before-and-after rule for every rewritten expression. "Before: rounds down. After: rounds to nearest." takes ten seconds and shows what the syntax hides. And give every deliberate rule a test or a comment that says why, so the next author, human or agent, knows it is deliberate.

A comment that only restates the code does not help: "rounds down" over a line that rounds down tells the next reader nothing they could not see. The comment that protects the rule says where it came from: "Finance rule: pack refunds round down to the cent, never in the member's favour." A test does the same job and also fails when the rule is broken, which a comment cannot. The best answer is both, and the test is the one that counts.

What It Costs

A quiet change is found months later by a member, an accountant or an auditor, when nobody remembers the diff. The cost is not the cent. It is the investigation into why pack refunds stopped reconciling, the correction of every refund since the deploy, and the trust lost by a finance team that had written its rule down and watched it disappear in a change about something else.

At Cragmoor's volume the money is small. With about 3,000 pack refunds a year, the figure this page uses, one cent each is $30.00. Nobody would approve a project to save $30.00, and nobody would approve a change that silently overrides a finance rule either. The number that matters is not the cent but the count of rules the codebase holds without a test, because each one is a quiet change waiting for the next tidy-up.