AI Refactored a Colleague's Three-Year Codebase in 20 Minutes—and Nearly Torched a Team

How It Started

Our team has an internal admin backend, and the core module is a form engine. This module was built by my colleague Xiao Zhang three years ago. It started as a simple form with a few dozen fields and gradually evolved into a complex form system supporting hundreds of fields, dynamic dependencies, and multi-level nesting.

Over three years, this module ballooned to several thousand lines of code—in a single file. No splitting, no type definitions, variable names ranging from data1 to tempArr2, you name it.

I'm not bashing Xiao Zhang. Anyone's code from three years ago would look the same when viewed three years later. Besides, he was racing against deadlines back then; if it ran, it was a win. The problem was that recently, the product team wanted to add a batch of new dependency rules. I was assigned this requirement and spent two days on it—every time I fixed one place, another place would mysteriously break.

One Weekend, I Couldn't Help Myself

Before leaving on Friday, I was a bit frustrated. I opened Codex, threw the file in, and said: "Help me refactor this file, split it into a reasonable module structure, and add TypeScript types."

In about twenty minutes, Codex produced a complete refactoring plan: it split one large file into 6 modules, each with clear responsibilities, added complete type definitions, and even scaffolded a testing framework.

I spent most of the weekend doing the following:

• Reviewed the AI-generated code line by line to ensure the logic matched the original
• Filled in some edge cases the AI missed
• Got all existing test cases passing
• Implemented the new dependency rules the product team wanted on the new structure—much easier than before

Monday morning, full of confidence, I submitted a massive PR.

Xiao Zhang's Reaction Completely Surprised Me

I thought Xiao Zhang would say, "This will be so much easier to maintain now."

After reviewing the PR, he was silent for about ten minutes, then walked over to my desk and said: "Do you think the code I wrote is garbage?"

I froze for a moment, quickly explaining that wasn't the case, that I did the refactoring because the new requirements were impossible to add. But his expression told me the explanation was weak.

In the afternoon, my manager called me in for a chat. It wasn't a reprimand, but the tone was clear: "Refactoring is a good thing, but you should have aligned with Xiao Zhang beforehand."

Later, I learned that Xiao Zhang had raised a few points with the manager:

1. No prior communication: He had no idea someone was going to refactor his module. On Monday morning, he suddenly received a PR that changed thousands of lines.
2. Feeling invalidated: Three years of work "replaced" by AI in twenty minutes—it didn't feel good.
3. Maintenance burden shifted: He didn't participate in designing the refactored code, but he would still be the one maintaining it going forward.

Every point was valid.

What I Did Wrong

After calming down and reflecting, I realized I made three mistakes:

First, I equated "technically correct" with "the right way to do it."

The refactored code was indeed better: clear structure, complete types, testable. But "better code" does not equal "the right way to do this." In a team, code is not just a technical artifact; it is also a human artifact. Behind every line of code is someone's time, energy, and judgment. The way you "optimize" it implies an evaluation of that time and judgment.

Second, I underestimated the impact of the "efficiency violence" brought by AI.

If I had refactored it manually, it might have taken two weeks. With two weeks of work, a colleague wouldn't feel "replaced"—because you paid a comparable amount of time. But AI turned it into a weekend's work, and that speed carries an implicit negation: "What you wrote in three years, AI can write better in twenty minutes."

Even if I didn't mean it that way, that's how it looked.

Third, I skipped the most important step—reaching consensus.

For something with such a large impact as a refactor, before starting, you should at least:

• Discuss the necessity and plan for the refactoring with the original author
• Involve them in the design, or even pair-program together
• Submit in stages rather than one giant PR

These are basic team collaboration norms. I skipped all of them because "AI made refactoring too easy."

The "Collaboration Trap" in the AI Era

This incident made me realize a deeper problem: AI is changing an unwritten contract in team collaboration.

In the past, the cost of refactoring was equal for everyone. Spending two weeks refactoring a module meant you genuinely invested time and effort, which itself was a form of "respect." Others seeing your PR would think: this person spent two weeks doing this seriously; I should review it seriously too.

But AI has reduced the cost of refactoring to near zero. When the cost of changing someone else's code approaches zero, the psychological barrier between "should I change it" and "just do it" disappears. People are more prone to act impulsively, more likely to skip communication, and more likely to unintentionally damage team relationships.

I summarized an AI-Era Team Collaboration Memo:

Scenario	Correct Approach	Common Mistake
Want to refactor someone else's module	Discuss the plan with the original author first	Directly have AI rewrite it and submit a PR
AI generates a large number of changes	Break into multiple small PRs and merge gradually	Submit one giant PR at once
Find a problem in someone else's code	Point it out in Code Review	Fork it yourself and rewrite with AI
Use AI to speed up development	Share the method, help the team improve efficiency together	Use it secretly alone, creating an efficiency gap
AI solution conflicts with a colleague's solution	Discuss it as "another way of thinking"	Use the AI solution to negate the colleague's

What Happened Afterward

I later talked to Xiao Zhang one-on-one, explaining my original intent clearly—it really wasn't that I thought his code was garbage, but that the new requirements were genuinely impossible to add. I also admitted my approach was wrong and that I should have communicated beforehand.

Xiao Zhang also expressed understanding. He said that module indeed needed refactoring, but the fact that "AI replaced three years of code in twenty minutes" was something he needed to digest.

In the end, we reached a plan: I closed that big PR and reopened several small PRs, each changing only one module, with Xiao Zhang fully involved in the review. The whole process took over a week—much slower than "AI's twenty minutes," but the team relationship wasn't damaged, and Xiao Zhang became familiar with the new code structure during the review process.

Sometimes, slower is truly faster.

Final Thoughts

AI has made many things easier: writing code is easier, refactoring is easier, writing tests is easier. But the things AI can't solve are precisely the hardest ones—communication, consensus, respect, trust.

No matter how strong your technical skills are, if you can't handle the "human" part, you're a ticking time bomb in a team. This principle existed before, but it has become sharper in the AI era—because AI amplifies individual execution ability, and also amplifies the consequences of not communicating.

Have you encountered a similar situation in your team—using AI to do something you thought was a "good deed," only to trigger an unexpected reaction?