Two Years of AI Coding Tools Taught Me That Speed Is the Wrong Metric
After Two Years of Using AI Programming Tools, I Re-understood What a 'Senior Engineer' Really Is
Recently, my Juejin feed has been flooded with posts like "AI programming boosted my efficiency tenfold," "I used Claude Code to refactor 100,000 lines of code in three days," and "Programmers who don't use AI are being eliminated."
Honestly, I'm getting a bit tired of seeing them.
Not because I deny the value of AI programming—quite the opposite. I was among the earliest technical leads in China to fully roll out AI-assisted development across a team. From GitHub Copilot to Cursor, from Codex CLI to Claude Code, I've tried nearly every tool available on the market.
But after two years of use, I have to say something that might not be popular: The greatest value of AI programming tools is not making you write code faster, but making you see more clearly—exactly where you fall short.
1. Writing Fast Does Not Equal Writing Well
This is the most common illusion I've observed.
Many developers' first reaction after adopting AI is: "Oh my god, I can finish in a day what used to take a week." But if you examine that code closely, you'll discover a brutal fact—speed goes up, but depth of thinking goes down.
What was the old development workflow? Receive a requirement, first draw a flowchart, then think about data structures, then write pseudocode, and finally start coding. Every step was mentally processed. Now? Throw the requirement into a dialog box, hammer the Tab key, and the code appears.
It looks seamless. But the problems are:
- Have you considered whether the state management solution AI chose for you will cause performance bottlenecks at your data scale? It won't tell you that when the user list exceeds 10,000 entries, that elegant reactive listener will freeze the main thread.
- Does the concurrent request logic AI wrote for you handle race conditions? You deploy it excitedly, and then in a weak network environment, the page data the user sees is leftover from the previous request—this is a bug you could write yourself. You could. But when AI writes it for you, you Accept without even looking.
- That third-party library AI introduced—do you know when it was last updated? Is its maintainer a university student who has been out of contact for three years?
Writing fast only lowers the cost of making mistakes, not the probability of making them. One could even say it raises the probability—because you no longer review line by line, you start trusting a black box you don't truly understand.
2. The Degradation of Code Review Ability Is More Serious Than You Think
This really happened in my team.
Last year we hired a backend engineer with 5 years of experience. His resume stated "Proficient in AI-driven development using Claude Code and Codex, efficiency improved by 60%." After joining, he was indeed fast—his requirement delivery speed ranked in the top three on the team.
But during one code review, I asked him to review a piece of AI-generated authentication middleware written by a colleague. He looked at it for three minutes and said, "No problem, can be merged."
I asked him: "In this code, the token refresh logic has a time-window vulnerability. Did you see it?"
He froze. Then he looked again, and his expression changed.
That code indeed ran, and the unit tests passed. But when it initiates a refresh request 5 seconds before the token expires, if a concurrent request happens to use the old token, the old request will return a 401 before the new token takes effect, causing the user to be unexpectedly logged out. This is a classic concurrent authentication race condition.
This incident made me realize a deeper problem:
When a person gets used to being fed code by AI, their code review ability degrades irreversibly. Because reviewing code requires not "understanding syntax," but "seeing things beyond the code"—concurrency scenarios, boundary conditions, exception paths, security vulnerabilities. These are precisely the parts AI is worst at and most likely to omit.
AI excels at generating the Happy Path, but production environments are never the Happy Path.
3. True Seniority Is Knowing When to Turn AI Off
After two years, my current workflow is this:
When writing CRUD boilerplate code, form validation, or those "I know how to write but don't want to type" template codes, Codex is fully on, Claude Code is fully on. These codes have simple logic and controllable risk; the time saved by AI is real.
But in the following scenarios, I turn AI off:
- When designing domain models. This is where human judgment is most needed. Your business context, your organizational structure constraints, your future expansion expectations—these things cannot be fully described in a prompt. Letting AI design a domain model is like letting a renovator who doesn't know your family design your home layout—he can produce a plan that looks reasonable, but after you move in, you'll find awkwardness everywhere.
- When handling online incidents. When a sporadic memory overflow occurs in production, you need to read GC logs, analyze heap dumps, and understand the JVM memory model. Claude Code can't help you here—it doesn't even have the context of your online environment, let alone understand the various implicit dependencies of your legacy system that has been running for three years.
- When making technology selection decisions. AI will give you a comparison table that "looks objective," but its judgment is based on popularity distribution in training data, not your team's actual situation. Your team's proficiency with Rust, whether your ops system can support Kafka's complexity, whether your budget allows introducing a certain commercial component—only you can judge these.
The gap between those who use AI as a tool and those who are used by AI as a tool lies right here. The former knows where AI's boundaries are; the latter thinks AI has no boundaries.
4. The Three Abilities I Value Most When Interviewing Now
If you come to interview with me, no matter how dazzlingly your resume highlights AI efficiency gains, what I truly care about are these three things:
1. Can you clearly articulate the troubleshooting thought process for a complex problem without AI?
I won't test you on reciting API signatures—you can look those up in documentation. But I will give you a real production failure scenario and ask: From user feedback to root cause identification, what is your investigation path? Which logs will you check? What hypotheses will you make? How will you verify them?
Codex can't help you with this question, and neither can Claude Code. Because it tests not knowledge reserves, but engineering intuition—something that only grows after countless late nights troubleshooting online issues.
2. Do you have an engineering mechanism to constrain AI output?
I will ask: In your project, how do you ensure that AI-generated code does not deviate from team standards? Do you maintain a Type Definition constraint layer? Have you added automated auditing of AI code in CI?
If a candidate tells me they directly paste Claude Code-generated code into the project and submit a PR, then no matter how high their efficiency, I have to hesitate. Because it means their codebase is accumulating technical debt at an uncontrollable rate.
3. Can you spot the "silent debt" hidden in AI code?
I will give them a piece of AI-generated code that runs but has hidden dangers, and ask: In this code, which parts are correct but meaningless, and which are hidden pitfalls? If this code runs for two years and then fails, what is the most likely failure mode?
Someone who can answer this question is truly capable of mastering AI tools. Because they are not "using" AI; they are "auditing" AI.
Finally
Let me speak from the heart.
AI programming tools are good things. Codex and Claude Code have indeed raised my team's per-person output by a level. But I also see a dangerous trend: the stronger the tools, the lazier people become; the lazier people become, the weaker their judgment; the weaker their judgment, the more they depend on the tools. This is a vicious cycle that boils the frog slowly.
I have seen too many developers who, the longer they use AI, the less they dare to question AI's output. Not because they trust AI, but because they gradually lose the ability to question—when your muscle memory becomes Tab + Enter, how many opportunities do you still have to truly understand why a line of code is written that way?
The greatest paradox of AI programming tools is this: their most useful places are precisely the areas where people who don't need them excel most. A senior engineer who can write high-quality boilerplate code saves real time using Codex. But a junior developer who can't even write boilerplate code properly just uses Claude Code to produce garbage more efficiently.
So, if you ask me what my biggest gain is after two years of using AI programming tools, it's not efficiency, not output, but a realization:
A true senior engineer is not the one who writes code the fastest, but the one who, after AI gives an answer, still asks "why."
What do you all think?
Tags: Frontend Backend AI Programming Career Growth Technical Management
Top 1 from juejin.cn, machine-translated. The original thread is authoritative.
[Like]