AI Refactored a Colleague's Three-Year Codebase in 20 Minutes—and Nearly Torched a Team
AI tools collapse the time-cost of large-scale code changes from weeks to minutes, which also collapses the social signal that effort equals respect. Teams that don't deliberately rebuild communication norms around this new speed will accumulate interpersonal debt faster than technical debt.
A weekend experiment with Codex turned a monolithic, untyped JavaScript form engine into six clean TypeScript modules. The technical result was objectively better: clear boundaries, full types, passing tests, and new features that were suddenly trivial to add. But the PR landed like a bomb. The original author saw three years of work replaced in twenty minutes by a tool, and the team lead flagged the real failure—zero communication before a change that rewrote someone else's domain.
The core problem wasn't the code quality. AI's speed collapsed the normal cost of refactoring from weeks to hours, erasing the implicit signal that serious effort signals respect. When changing someone else's work becomes nearly free, the psychological barrier between "should I" and "I did" disappears, and the human contract that holds teams together starts to fray.
The resolution required killing the giant PR, splitting the work into small, reviewed chunks, and spending a week on what AI did in minutes. The code ended up in the same place, but the team survived.
AI doesn't just accelerate coding; it removes the natural braking mechanism that manual effort provides. When a refactor takes two weeks, you think twice before starting. When it takes twenty minutes, impulse wins.
The phrase 'efficiency violence' captures something real: a tool that makes someone else's years of work look replaceable in minutes carries an implicit judgement, whether intended or not.
Code ownership in teams is partly a social contract. AI tools that let anyone rewrite anyone else's module instantly threaten that contract unless new norms are explicitly built.
The fix wasn't technical—it was procedural. Small PRs, co-review, and a slower pace produced the same code outcome but preserved the relationship, which is the harder and more valuable asset.
AI-era collaboration needs explicit rules—like discussing refactors with original authors first and never using AI output to ambush a colleague in review—that were previously enforced by sheer effort cost.
The core objection is that touching code outside one's own scope—especially with AI—is reckless and professionally insulting. The speed of the change is seen as a liability, not a virtue, because the original author alone bears the maintenance burden and understands the business logic. A minority view suggests AI could handle the review and testing, but the dominant stance treats unsolicited refactoring as a direct threat to job security and a violation of ownership.
Don't touch code that isn't part of your own business!!! Whether you or AI slip a landmine in there, it's hard to pin the blame.
Exactly, good intentions end up causing trouble.
Take this story with a grain of salt. A large module someone else owns—there's no way an outsider can know all the business logic, let alone review every line of code and pass every test case. Laughable.
Just hand the code review and test-case running to AI, no?
The main reason Xiao Zhang has a problem with you is that you might have threatened his job. Threatening someone's livelihood is like killing their parents...
Never daring to do that again.