01. What AI Changed and What It Didn't

The Era of Fever and Anxiety

If you’ve scrolled through social media recently, you might get the illusion that the history of software engineering is coming to an end.

In videos, a vlogger builds a decent-looking SaaS application in just a weekend using AI; in articles, a startup claims that introducing AI coding assistants boosted efficiency by 500%.

For technical managers, this narrative is both a stimulant and a toxic source of anxiety. Boards of directors start asking: “Since AI is so efficient, can we cut our R&D budget in half?” CTOs start confusing: “Why has my team started using Copilot, but the delivery speed hasn’t increased 10 times like in the videos?”

This is a moment full of noise. As practitioners standing at the intersection of engineering and management, we need to hit the pause button and calmly ask a fundamental question: What exactly has AI changed? And what are the things it simply hasn’t changed, or even cannot change?

To be honest, I was once bewildered by this speed narrative until several projects paid a higher price in later stages.

Illusion 1: The Trap of Linear Acceleration

The first pitfall managers most easily fall into is what I call the “Linear Acceleration Illusion”.

The logic of this illusion goes like this: If AI makes coding 5 times faster, then project delivery speed should be 5 times faster. If developing a feature used to take 5 days, can it be done in 1 day now?

I’ve seen more than one manager, after watching a “weekend app building” video, turn around and ask their team: “Can this feature go live next week?”

The answer is: In most real engineering scenarios, this does not hold true.

Because software engineering has never been just about “writing code”. In a typical R&D cycle, real coding time often accounts for only 20% - 30%. Where does the rest of the time go?

• Requirement Clarification & Negotiation: Time spent understanding “what the user actually wants”.
• System Design & Trade-offs: Time spent deciding “how to do it so it won’t crash in three months”.
• Debugging & Troubleshooting: Those moments of “it works fine in this environment but breaks in production”.
• Communication & Alignment: Frontend waiting for backend APIs, Product waiting for designs, QA waiting for deployment environments.

AI indeed significantly compresses that 20% of coding time. It can generate a boilerplate or write a regex matching function for you in seconds. But AI has not changed the “friction” of the physical world.

It cannot argue with indecisive product managers for you, it cannot predict business pivots three months down the line for you, and it certainly cannot bear the responsibility for data inconsistencies after the system goes live.

AI changes the execution efficiency of local links, but it does not change the overall complexity of the system.

Distinction: Demo ≠ System ≠ Product

The vast majority of those “apps made in a weekend” on social media stop at the Demo stage.

• Demo is fragile: It just needs to not crash during the two minutes of demonstration. It doesn’t consider high concurrency, dirty data cleaning, security, or future code maintenance.
• System is robust: It needs to handle Edge Cases, requires robustness, and requires observability.
• Product is complex: It contains not just the system, but also user systems, compliance requirements, data privacy, multi-language support, and even fault tolerance for billing systems.

AI excels at generating a Demo from 0 to 1. At this stage, its acceleration effect is astonishing, even disruptive. But in the process of moving from Demo to System, and then to Product, the marginal utility of AI diminishes.

When the code volume goes from 500 lines to 50,000 lines, when the Context exceeds AI’s window limits, and when the coupling between system modules becomes intricate, AI is no longer that omnipotent god. At this point, human engineers are still needed to perform architectural governance and understand those implicit business logic constraints.

Unchanging Cornerstones: Physical Constraints and Entropy

No matter how powerful AI is, some core laws of software engineering have not been broken:

1. No Silver Bullet: The Law of Conservation of Complexity still exists. Business complexity doesn’t vanish into thin air; it’s either encapsulated in code or shifted to Prompts.
2. Entropy: Software systems tend to become chaotic and hard to maintain over time. AI might even accelerate this process—because it can generate massive amounts of “code that runs but no one fully understands” at high speed. This means that without architectural governance and responsibility boundaries, the accumulation rate of technical debt could be multiplied by AI.
3. Human & Organizational Limits: Communication costs still grow with the square of team size ($N(N-1)/2$). AI hasn’t solved misunderstandings between people; in fact, due to changes in communication media, it might introduce new noise.

Conclusion: Calibrating Course in the Fog

So, what exactly is AI?

It is not a god, nor a magician who can instantly turn a mud pit into a skyscraper. It is an amplifier of execution and an accelerator of knowledge retrieval. Simply put, AI accelerates “coding”, not “doing things right”.

For managers, recognizing this is crucial. If we make plans with the expectation of “linear acceleration”, we are bound to be hit hard by reality.

The AI era no longer rewards those who simply “write code the fastest”, nor does it reward those who “memorize the most APIs”. It rewards those who know best what to do and what not to do, and can harness the wild engine of AI to move steadily forward in the complex terrain of reality.

In the following articles of this series, we will delve deeper into the drastic changes happening in organizational forms, talent standards, and management philosophies under this new normal.