06. Why "Coding with AI" Can Lead to Negative Productivity

The Betrayal of Speed: From Demo’s “Takeoff” to Project’s “Crash”

After talking with a large number of frontline R&D teams, I observed a widespread “Inverted U-shaped” efficiency curve: In the Demo phase at the beginning of the project, AI can indeed bring an astonishing 3-5 times speedup. A prototype that originally took two weeks can now be running in two days. But after entering the complete project cycle (including testing, repair, changes) lasting several months, the overall delivery efficiency improvement will drop rapidly, and even show negative growth in some teams lacking governance.

Many managers are puzzled by this: “The code written by AI looks very standardized, the comments are detailed, and it even thoughtfully wrote unit tests. Why do we fall into endless Debug and rework in the later stage of the project?”

The answer hides beneath the surface of the code: AI is a perfect “Executor”, but it is a terrible “Questioner”.

AI’s Fatal Flaw: Defaulting to “Problem Correctness”

When human engineers receive a requirement, their first reaction is usually to question:

• “Why do we need this feature?”
• “Does this logic conflict with the existing permission system?”
• “Will this data structure have problems scaling later?”

AI’s first reaction is Obedience. If you tell AI: “Please write me a function that polls the database every second to check for new orders.” AI will immediately write you a perfect polling function with retry mechanisms and even connection exception handling.

But it won’t tell you: “In a high-concurrency scenario, polling the database every second will crush the DB; you should use a message queue.”

This is “High Quality Error Execution”. AI uses extremely elegant code to efficiently implement a design that is wrong from the architecture. If the engineer using AI lacks sufficient judgment to identify this architectural defect, then this elegant code is a time bomb buried in the system.

The Deceptiveness of Beautiful Code

Even more terrifying is that AI-generated code often has strong deceptiveness.

In the past, crappy code written by junior engineers usually looked ugly: messy indentation, mixed variable names, overly deep logic nesting. Senior engineers could tell at a glance: “This code is no good, rewrite it.”

Now, AI-generated code looks very “professional”: conforms to PEP8 standards, idiomatic variable names, and even has Docstrings. This “beautiful skin” will greatly lower the vigilance of reviewers. Code Reviewers might subconsciously feel: “It’s written so neatly, it should be fine, right?” thus ignoring the deep review of core business logic.

This is why bugs brought by AI are often harder to troubleshoot than human-written bugs: They are cloaked in “correctness”, lurking in the deepest parts of the system.

Who Is Qualified to “Supervise AI”?

This leads to a key management question: In your team, who is qualified to press the AI’s “Confirm Key”?

I believe managers must set a red line: Only when a person has the ability to write this code independently without AI, or at least fully understand every line of logic of this code, are they qualified to use AI to generate this code. And this red line must be explained and borne by the manager, rather than leaving the engineer to bear the consequences alone.

If an engineer doesn’t even understand the Join mechanism of SQL, letting AI generate complex report query statements is not just laziness; it is dereliction of duty. The problem here lies not in individual ability, but in whether the organization allows or even encourages direct confirmation without understanding.

Conclusion: The Return of Judgment

In the AI era, the biggest risk we face is not that AI is not smart enough, but that we are too easy to give up the right to judge.

When generating code becomes so easy, thinking about “the logic behind the code” becomes a chore. But it is precisely this chore that constitutes the core value of engineers.

For managers, the challenge now is not how to encourage everyone to use AI more, but how to establish a mechanism to prevent everyone from losing reverence for complexity under AI’s sugar-coated bullets.

Remember: AI is not a silver bullet; it only makes execution faster. AI can save you time typing on the keyboard, but it should never save you time thinking.