In an era where AI code generation tools are readily accessible, a fundamental question has emerged for both technologists and the general public: “If AI can generate perfect code or articles in seconds, what is the point of studying deeply?”

When making money seems possible through tool stacking and speculation, is it still necessary to grapple with obscure foundational principles?

The answer is not a simple “learn” or “don’t learn,” but rather that our learning sequence and focus must undergo a fundamental inversion. This concerns not only technology but also how we strategize the game of life.

1. Misconception: Linear "Before-During-After" Thinking

Most people's life plans and learning paths are linear:

Early Stage (Beginner) Mid Stage (Intermediate/Practical) Late Stage (Mastery/Results)

  1. Early Stage: Methodically memorize grammar and vocabulary, starting from zero.
  2. Mid Stage: Solve problems as they arise, navigate by feel, and prioritize speed.
  3. Late Stage: Hope for a good outcome (but often not knowing what that outcome specifically is).

This order is fatal in the AI era.

It is like playing Cities: Skylines. Beginners in the early stage only "blindly build," placing buildings on any available empty lot. Quickly entering the mid stage, you will find the city congested into a chaotic mess. To fix the traffic, you build elevated roads and change one-way streets, only to find that the problem remains unsolved.

Because the root solution to traffic congestion requires having the "late stage" road network planning vision before laying the first brick.

If this is writing code, this is the origin of "Tech Debt": because there is no foresight of late-stage requirements such as high concurrency and security audits, the mid stage ends up constantly applying inefficient patches. The collapse of countless systems is due to blind patching in the "mid stage" without the "late stage" perspective.

II. Breaking Through: Early, Late, Mid

True masters, whether playing chess, architecting systems, or navigating life, all follow this same logic:

Early Game Late Game Mid Game

1. Early Game: Getting Started Quickly

Back panel, fixed back, and mastering basic operations. This is the entry ticket—the faster, the better.

2. Late Game: Anchoring the Endgame

This is the most critical step, and the one most people miss. Before entering the mid-game, you must first jump to the late game and see what the "winning" state looks like.

  • Chess: A master doesn't play one move at a time; they know that once this formation (Late Game) is set, all variations are under control.
  • Architecture: Before writing the first line of code, you have already envisioned how memory will be organized, how certificates will be handled, and where security risks lie after 100,000 lines of code.
  • Life: Do you want to live to 80? Then go check the health indicators of a healthy 80-year-old. If your current health report shows your liver is at the level of a 50-year-old, you'll know what to do in the current "mid-game."

The so-called "mid-life anxiety" is essentially a loss of control over the "late game" situation.

3. Mid Game: Filling the Path

Once you have a starting point (early stage) and an end goal (late-stage blueprint), all mid-stage actions cease to be confused trial and error and become a fill-in-the-blank exercise.

With a blueprint, the mid-stage is clear; without one, it becomes a "well, it works, I guess" mentality of making do, ultimately leading to collapse.

3. The Role of AI: The Strongest "Mid-Term" Filler

Under this model, the role of AI becomes very clear: AI is the strongest Mid Game player in human history.

  • It can help you write CRUD;
  • It can help you polish emails;
  • It can help you generate boilerplate code.

However, AI cannot draw the blueprint for you. AI has a fatal flaw: Loss of Situational Awareness.

  • AI's perspective is local and one-sided. It sees "you need to write a function," so it quickly generates one, with perfect syntax.
  • Human perspective must be global and temporal. You know that this function might become a performance bottleneck in 3 years, or that relying on an unstable library could cause the system to crash.

If you don't have a "late-game" blueprint and blindly direct AI to work, the result is accelerated accumulation of "code spaghetti." Previously, manual coding was slow, so code spaghetti accumulated slowly; now, AI writes fast, and code spaghetti without architectural constraints will expand at an exponential rate until it becomes unmaintainable.

Human core competitiveness is no longer hand-crafting mid-game implementations, but defining late-game constraints.

4. What Should We Actually Learn? — "Engineering Intuition"

Now that AI has taken over the specific "techniques," humans must master the higher-dimensional "principles." This leads to the true moat of engineering education in the AI era: the engineering intuition of having "seen the pig run."

Many people question: "I'm not going to write Haskell or work on mathematical proofs in the future, so what's the use of learning these dry theories?"

The answer is: This "useless" knowledge determines the boundaries of your blueprints.

1. Never Wrote a Line of Code, Yet Possessed "Thinking"

Take Functional Programming as an example. You may have never written a single line of Lisp code in a production environment, but because you have studied it, your subconscious instinct during system design is to avoid "side effects" and pursue "immutability."

This is "lateral thinking" at work. You don't need to write the code yourself, but you recognize that this paradigm can resolve complexity.

2. Useless "Dragon-Slaying Techniques" Expanded the Search Space

Take formal verification, for example. This is utterly irrelevant if you're just writing a small script to make some quick money, but when planning for the "long term," it provides a rare perspective: completeness.

  • Ordinary people: It's fine as long as the code runs.
  • Trained individuals: Instinctively ask, "Is this logic closed-loop?" or "Are the boundary conditions mathematically complete?"

This experience expands your thinking's search space. When directing AI, you have an additional option in your mind called "mathematical completeness."

"I've never eaten pork, but I've seen a pig run."

In the AI era, this has become a core competitive advantage. Because only those who have "seen the pig run" know that such a creature as the "pig" even exists, and can point to a blank space when drafting a blueprint and tell the AI:

"Here, draw me a pig. A declarative pig. A pig that conforms to the definition of completeness."

Those who have never seen it, due to their lack of knowledge, can only ask the AI to draw a chicken that runs very fast.

V. Conclusion: Restructuring Your Learning List

Back to the original question: what should ordinary people learn in the AI era?

❌ Don't obsess over:

  • Memorizing syntax details (AI can look them up for you).
  • Framework APIs that will quickly become outdated (AI can write them for you).
  • Mechanical, repetitive boilerplate tasks (AI can do them for you).

✅ Must learn:

  • Paradigms: Even if you don't write code, you should understand various programming paradigms (functional, logical, declarative). They are the "arsenal" in your mind.
  • System Theory and Architecture (System Design): Understand how modules interact and where complexity originates.
  • Aesthetics and Taste: Know what makes good code, good writing, and good design. Only then can you effectively review and validate AI-generated output.

Don't be a "mid-level craftsman" who just looks down to fill in the blanks. Be the architect who knows when to stop, look up, and see the "endgame."

Next Steps Recommendations

Now that we have clarified the importance of "Late Game Vision," would you like me to recommend some specific classic books or learning resources that can enhance "engineering intuition" and "paradigm thinking" (not specific programming language tutorials, but rather resources focused on mindset and thinking)?