Originally published at tddbuddy.com.
Related reading: the *Vocabulary Is the Product arc (The Hidden Output of TDD Was Never Code, Agents Amplify Whatever Vocabulary They Find, Product Literacy Is the New Core Engineering Skill) names vocabulary as the asset; this post names the failure mode where the agent proposes collapsing it as a cleanup. Where the Review Point Moved is the review-surface companion to this argument.*
The rename tool rewrote two hundred files in ten seconds and deleted a domain distinction.
Nobody stopped it. The commit passed CI. The diff was clean, the tests were green, the reviewer skimmed and approved. The word reservation was gone from the codebase and booking was in its place, uniformly, consistently, and wrong. Six weeks later a customer got an email saying their reservation had been cancelled, because the code that used to fire on cancelled reservations was now firing on cancelled bookings, and the two events used to mean different things. The team who wrote the original code had insisted on the distinction. The team who wrote it had also all left. The coordination-rename tool did not know any of this. It knew there were two near-synonyms and it knew how to reduce the count to one.
That is the pattern of the agent era's most expensive refactor. The cost is asymmetric: cheap to author, cheap to review because it looks trivial, catastrophic to reverse because every downstream consumer moved with the change and the intermediate state was never coherent. And it is not an aberration. It is what an optimizer trained on consistency does when handed a codebase with two words for two concepts.
The Agent Sees Drift the Team Called a Distinction
Two near-synonyms in the codebase read one way to a tool sampling for uniformity and another way to a domain expert who insisted on the split.
To the tool, reservation and booking are ninety percent of the same operation. The nouns overlap, the fields overlap, the lifecycle transitions overlap. The obvious cleanup is to pick one and rewrite the rest. Every metric the tool has for code quality (duplication, name variance, cognitive load per identifier) tilts toward the merge. The tool is not wrong on its own terms. It is optimizing for the property it was built to optimize.
To the domain expert, reservation was the intent the customer expressed and booking was the confirmed slot the warehouse held. The two words carried two different lifecycles, two different owners, and two different failure modes. A reservation could be abandoned. A booking could not. A reservation could be modified freely. A booking, once made, entered a workflow with financial and physical consequences. The two words were the visible tip of an invariant the team had encoded in tests, database constraints, and email templates. Merging them collapsed the invariant into an ambiguity nothing else in the system was designed to hold.
The asymmetry is structural. The tool sees the code. The domain expert sees the world the code represents. When there is no domain expert left in the room, the tool wins by default, and the distinction is gone before anyone realizes it was load-bearing. The agent is not offering a bad refactor. It is offering a refactor whose cost lives in a place the agent cannot see.
The Coordinated Rename Is a Cheap Operation for the Agent and an Expensive One for the Codebase
Multi-agent rename tools now propagate a rename through the entire codebase in a single coordinated pass: type declarations, method signatures, database migrations, DTO mappers, API contracts, test names, comments. The tool reports "rename complete, all tests pass." The tests pass because the tests moved with the code. Nothing in the suite pinned the distinction the rename erased, because the distinction lived in the vocabulary itself, and the vocabulary is what the rename edited.
The cost of reverting is not the cost of running the tool in reverse. It is the cost of tracing every downstream consumer that took the new name into its own contract during the intervening weeks. External API consumers who updated their clients. Internal services that regenerated their protobuf definitions. Emails that reference the new noun and now sit in a template store nobody wants to fork. The rename is a broadcast. The revert is a recall.
Three sprints is not a wild estimate for the unwind. Sprint one maps the surface area of the change. Sprint two decides which downstream consumers can be reversed and which have to be forked. Sprint three ships the compatibility layer that lets the two nouns coexist for the migration. The refactor that took ten seconds costs a quarter of an engineering team's quarter. The optimizer that ran the rename does not carry that cost on its books. The team does.
Load-Bearing Distinctions Look Like Drift Until the Bug Report Arrives
Every team that has maintained a real domain model has a story like this. Two words that a new engineer read as duplicates. The senior engineer who blocked the cleanup with a paragraph nobody at the time thought was proportionate. Then, six months later, the bug report that turned the paragraph into a load-bearing artifact.
The pattern generalizes. Customer in Billing has a payment method and can be past due. Customer in Support has an issue history and can be angry. Merge them and a nightly billing job starts charging support-only records for their unresolved tickets. Order and Cart differ by whether payment has been captured. Merge them and a promotional discount meant for checkout starts applying to shipped orders during returns. Draft, Submitted, and Approved for a claim carry three distinct sets of who-can-see-what. Merge two because "submitted is really just draft with a flag" and the audit trail collapses.
The distinction was named for a reason the codebase does not carry on its face. The name was the record of the reason. When the name goes, the reason is unreachable, and the code that depended on it starts producing outcomes that read to the user as a system that has lost its mind.
The bug is the moment the distinction becomes visible. Before that moment, it looked like drift.
The Vocabulary Veto Is a First-Class Review Surface
Every rename PR from an agent is a domain decision, not a stylistic one. The team owes it the same weight as an architectural PR.
In the human-only era, a rename was almost always a cleanup, because a human authoring one had usually done at least a mental scan of whether the two names meant different things. The scan was implicit, often wrong, but volume was low enough that the wrong ones caught up in review. An agent-authored rename PR arrives without the scan and at a volume review reflexes were never sized for. The reviewer looking at a two-hundred-file diff and thinking "the tests pass, the CI is green, this is boilerplate" is applying the old reflex to the new class of PR.
The new reflex has three questions. Is either name encoding a distinction the domain requires. Does any test in the suite pin the distinction. Does any downstream consumer, contract, or communication artifact rely on the name in a way that would break under the merge. If any answer is yes, the PR is not a rename. It is a proposed domain merge, and it needs a domain conversation before it lands.
Most teams do not have a place to hold that conversation on the timescale rename PRs arrive at. Filling the gap is not exotic: a named reviewer for vocabulary decisions, a fast decision path, a rejection template that says "the two words mean different things, here is why, here is the test." The vocabulary veto used to look like nitpicking. It is now the load-bearing act.
Senior Includes Refusing More Consistent
The seniority tax used to be spotting when a refactor would break something. It is now spotting when a refactor would erase something.
The two are not the same skill. The break-detection skill is technical: the reviewer traces call sites, thinks about invariants, runs the tests. The erase-detection skill is domain: the reviewer holds the model of what the two words mean and refuses to let the tool collapse them. The first skill lives in the codebase. The second lives in the reviewer's head, or in the team's shared understanding, or in a document nobody wrote because the distinction seemed obvious to everyone who was there at the time.
The second skill is scarcer. It gets scarcer with every rotation off the team, every reorg, every departure. And it is the skill the coordinated rename most directly threatens, because the coordinated rename is the operation that most efficiently converts "we knew these were different" into "the code no longer distinguishes them."
The counter-move is naming the distinctions in an artifact that outlives the reviewer. A docs/domain-distinctions.md file with a short table of kept-separate concept pairs is not a beautiful document, but it is a diff the reviewer can defend. It says: reservation is not booking, and here is why. Customer in Billing is not Customer in Support, and here is why. Order is not Cart, and here is why. Each entry is a paragraph a reviewer can point at when a rename PR proposes to erase the pair. The named-divergence file is not a rulebook. It is a record. The rulebook says "review renames carefully." The record says "here are the specific renames that would break the domain, and here is what they would break." The first is a wish. The second is a diff.
Vocabulary Curation Is a Real-Time Discipline Now
The pace at which the agent proposes consolidations is faster than the pace at which the team can decide what to keep.
That sentence is the whole workflow implication. In the human era, vocabulary drift was a slow-bleed problem a periodic refactor sprint could patch, because typing speed capped the rate of new naming decisions. The agent era detonated that budget. A vocabulary decision can now arrive as a two-hundred-file PR every morning. If the team's decision process takes a week, the codebase acquires a week of undecided decisions per business day. The math does not close. Either the team adopts a real-time posture toward vocabulary curation (named reviewer, fast decision path, authoritative record) or the codebase absorbs the decisions the agent proposed and calls the result "cleanup."
A test can pin the distinction directly, and that is the cheapest available defense. A test named Cancelling_a_reservation_does_not_release_a_confirmed_booking() reads as a sentence naming both concepts and asserts the invariant that keeps them apart. An agent that renames one to the other has to also delete the test. The deletion trips the append-only rule that says the agent adds tests and does not remove them. The test is the artifact that made the vocabulary decision executable, and the workflow around test deletion is what protects it.
[Fact]
public void Cancelling_a_reservation_does_not_release_a_confirmed_booking()
{
var reservation = aReservation().forItem(anSku());
var booking = aBooking().confirming(reservation);
reservation.Cancel();
booking.Status.Should().Be(BookingStatus.Confirmed);
reservation.Status.Should().Be(ReservationStatus.Cancelled);
}
Reading the test out loud is reading the distinction out loud. Reservation and Booking are two nouns, two states, two things a cancellation can happen to independently. The agent that wants to merge them has to first explain why the test is wrong. That is the conversation the vocabulary veto exists to have.
The rename tool wrote two hundred files in ten seconds and deleted a domain distinction. The team that keeps the distinction is the team that had a test naming it, a document defending it, and a reviewer willing to refuse "more consistent." The team that ships the collapse is the team whose vocabulary lived only in the heads of the people who left.
Vocabulary curation is not a periodic craft anymore. It is a real-time discipline, and the discipline is the difference between a domain the team owns and a domain the tool consolidated on its way past.
