Last year, the team started using AI programming tools, and everyone felt that coding had become faster. But after a year, I noticed an odd phenomenon: although coding time had indeed decreased, Code Review time had been increasing. Previously, reviewing a PR involved scanning the logic and raising two questions, and it was done. Now, for every change, I have to repeatedly confirm: was this part written by AI or by a person? Were the boundary conditions handled? Are there hidden performance issues? By the end of the review, it was more exhausting than rewriting it myself.

I. AI coding is fast, but reviewing is slow

At the beginning of this year, I took over the team's core project. Several colleagues in the team used Cursor and Copilot, and the output was indeed high. But when it was my turn to review, I always felt something was off.

For example, a colleague submitted a functional module, and the code ran without issues, but when I reviewed it line by line, I found: three useEffect were hung in one component, with two of them overlapping in functionality. The author said he didn't notice it and that it was automatically completed by AI. Such issues became the norm: AI-generated code often ran, but it was structurally disorganized, logically repetitive, and lacked boundary checks.

Code written by humans in the past, you can feel the author's thought process. Code written by AI is like a big mess, it looks like it has everything, but it's just uncomfortable. During code review, you can't just check if the logic is correct, you also have to help the author remove redundancy, add missing parts, and organize the structure. This whole process can double the time spent.

II. Common "ailments" in AI-generated code

I've summarized several types of AI traces that are often encountered during code review:

1. Logic is correct, but boundaries are missing

AI is good at getting the main flow working, but it doesn't usually handle issues like null pointers, timeouts, or concurrency proactively. For example, for a query interface, AI might write data.list.map(...), but it won't check if data is null. During review, you need to help add data?.list?.map or if (!data) return null.

2. Over-engineering, complicating simple problems

Sometimes AI can make something very simple seem particularly "high-end." For example, adding debouncing, it gives you a complete custom Hook, which usesuseRef.useCallback,useEffect, running for four or fifty lines. But in fact, only one is neededdebounceWhen reviewing this kind of code, you need to first understand its implementation before judging if it's overkill.

3. Comments and naming like "Machine Translation"

Variable names generated by AI are oftendata.items.configIt's hard to understand the specific meaning. Function comments are either missing or are vague like "get data." During review, it's necessary to help change the naming to be meaningful or add necessary comments, otherwise, the next person won't understand.

III. My Personal Strategy: How to Make Reviews Less Painful

After about half a year, I've figured out a few somewhat effective methods:

• Let AI Review AI: Before submitting a PR, ask the author to have the code reviewed by AI (using a different model) and make a round of changes based on the suggestions.
• Differentiate Treatment: Utility classes, unit tests, and documentation comments can be safely written by AI; core business logic is recommended to be hand-written or heavily modified.
• Establish Small Guidelines: For example, "useEffect must have a cleanup function," "API calls must have loading and error states." AI may not always follow them, but they can be quickly referenced during reviews.

These methods cannot completely eliminate the problem, but at least they can bring the review time back to an acceptable range.

IV. Reflection

I have a contradictory attitude towards AI programming now. On one hand, it确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实确实帮我省了不少重复劳动； on the other hand, it又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又又把负担转移到了review环节。以前一个人写代码，大家一起审；现在一个人写AI代码，另一个人替他审漏洞。

This is not the fault of AI, nor is it the fault of the tool; it's that we haven't learned how to collaborate with AI yet. Maybe in the future, there will be better review processes, or AI will be able to review itself. But as of now, AI hasn't reduced my overtime work; it's just shifted the content of my overtime from "writing" to "reviewing"。

Five, finally

If you're also experiencing similar feelings, give a thumbs-up to let me know I'm not alone。Discuss in the comments: Has your team's review process slowed down due to AI code?