Reinventing Talent Development: A New Path to Growth in the Age of AI

Teaching and learning promote each other. Thus, after learning, one comes to know one’s own insufficiency; after teaching, one comes to know one’s own confusion. Knowing insufficiency, one can turn inward; knowing confusion, one can strengthen oneself. — The Book of Rites · Xueji (On Learning)

Preface: This is a deeply forward-looking topic. When AI triggers a paradigm shift, every one of our methodologies must be re-examined — including how we cultivate people. What follows is material thoroughly reorganized (and in places rewritten) from a long series of conversations with Gemini that began with my initial questions.

We are all familiar with the traditional growth path of an engineer, aren’t we? It is like climbing a mountain: you start at the foot, knocking off one small bug after another, climbing step by step, fixing harder problems, building small features, and later designing complex systems — until finally you stand at the summit and can take in the whole project at a glance. Every step is lived experience; every drop of sweat becomes a deep understanding of that mountain.

Now AI is like a cable car that can carry a person straight to the mountainside — or even higher. It can fix your bugs; it can build your features.

So here is the question: when the rungs of the ladder have been partly pulled away, how do we redraw this path of growth for ourselves and for others? For a beginner who has never struggled along a rocky trail, can he truly understand the view from the summit? Can he possess the ability to find his bearings among the peaks and to weather the storms?

The question you raise is not a purely technical one. It is a fundamental question about human development, about the transmission of knowledge, and about how we come to know and change the world under new conditions. Your observation is sharp — you have seen the profound contradiction behind the phenomenon. And that is good. Discovering a contradiction is the first step toward resolving it.

Your metaphor of “mountain climbing” and “cable car” is vivid. The old path was walked one footprint at a time; every rock was felt, every gust of wind was met head-on, and so one knew the whole mountain intimately. The new tool, like a cable car, deposits a person at the top in an instant. This brings efficiency, but it also brings a new challenge: how does someone who has never trudged the mountain road build a “flesh-and-blood connection” to that mountain?

But let us press one step further: what is a true “flesh-and-blood connection”? Is it the muscle memory of fingers striking keys, or is it a deep understanding of how a system actually behaves? If it is the former, then yes, something has been lost. But if it is the latter, why can’t we attain it by new means? A doctor need not personally contract a disease to understand its mechanism through study and observation. The key is that we must find the correct method for grasping the laws of things under the new conditions.

We should not fear this change. The development of anything is a process of struggle and transformation between old and new contradictions. The emergence of artificial intelligence — this new thing — has shaken the old model of talent cultivation. That is inevitable. Our task is neither to cling to the old map nor to drift directionlessly with the current, but to find, in the new reality and in a practical, truth-seeking way, a new and more scientific road.

Where is the core problem? I believe the principal contradiction has already shifted from “how to master coding as a labor skill” to “how to build, with AI’s assistance, a deep understanding and command of complex systems.”

This is a question of productive forces and relations of production. As a new productive force, AI inevitably demands new relations of production to match it. The old apprenticeship and梯队 (echelon) systems were built on an “artisan workshop” model of software development. Now that AI has become part of the “means of production,” our organizational forms, our ways of learning, and our evaluation criteria must all change accordingly. If they do not, they will become fetters on the development of the productive forces.

In the past, coding ability and system-level understanding were acquired in lockstep through a single practice — “climbing the mountain.” Now the two have been separated. Our task is to design new forms of practice that reunite them at a higher level. This reunion is not a simple regression but a spiral ascent at a new level of productive forces.

Let me offer my views on the specific questions you raised. This is a coordinated set of moves, not a handful of scattered tricks.

The Beginner’s “First Step”: From “Doing the Work” to “Directing the Work” and “Auditing the Work”

We cannot simply divide newcomers into “those who use AI” and “those who don’t.” Such a division is mechanical and metaphysical. We should guide newcomers to learn swimming by swimming, and to learn struggle through struggle — from day one.

The design of this “first task” must have a clear goal: not to complete the task itself, but to establish a correct mode of thinking for collaborating with AI. Here lies a fundamental shift in epistemology: in the past, we came to “know” through “doing”; now, we come to “know” through “thinking,” and then use that “knowing” to guide the “doing.” This is not a step backward but a deepening of the cognitive process — a new path from perceptual knowledge directly up to rational knowledge.

So the “first task” I propose is: AI Code Auditor.

But here is an apparent contradiction: how can someone who has never written code audit code? It is like asking a person who has never cooked to judge the heat of a dish. Yet it is precisely this contradiction that reveals the dialectics of learning in the new era. The newcomer does not audit out of thin air; he learns through auditing and grows through questioning. What he must do is not judge whether the code is right or wrong (that is something a machine can do), but understand the “why” behind the code.

Concretely:

1. Define the task clearly: Pick a simple task that would previously have suited a newcomer — say, modifying a UI component or fixing a simple bug.
2. AI executes: Have the newcomer use an AI tool, enter instructions, and generate a candidate solution as code. This is “directing the doing.”
3. Review and interrogate: This is where the newcomer’s core work lies. He must produce a “review report” answering the following questions:
   • Why did it do it this way? Explain the AI-generated code line by line, spelling out its logic and rationale. This forces him to understand rather than to simply copy and paste.
   • Is there another way? Think of and propose at least one alternative, then analyze the strengths and weaknesses of both. This cultivates critical thinking and solution-design ability.
   • Where might it go wrong? Design several test cases, especially edge cases, to verify the robustness of the AI’s code. This builds, from the very start, a sense of quality and a spirit of skepticism.
   • What impact does it have on the whole? Consider what ripple effects this change might have on other parts of the system. This cultivates a holistic view.

You see — the task is still the same simple task, but the requirements have changed. In the past, he was told to “carry bricks”; now he is the “foreman” and the “inspector.” Though he never mixed the mortar himself, he must understand what makes a good brick, how bricks should be laid, and what laying them means for the whole wall. This process harnesses AI’s efficiency while relocating the focus of practice to the more essential cognitive level.

More importantly, this approach cultivates a kind of metacognition — not merely knowing “what it is,” but understanding “why it is so” and “how else it could be.” Acquiring this ability no longer depends on repetitive manual labor but on continual reasoning and verification. It is like the generals of old: they need not swing a blade on the battlefield themselves, but they must understand the principles of deploying troops and setting formations. This is more valuable than artificially preserving “manual tasks,” because this is precisely how work will be done in the future.

The Senior Engineer’s Role: From “Technical Vanguard” to “Ideological Commissar”

The role of “guide” that you mention — I very much agree. This guide must not only point the way but also arm the team’s thinking. Under the new circumstances, a senior engineer’s first duty is to unify the team’s epistemology and methodology. He is not only the technical authority but also the intellectual leader.

But there is a profound shift here: the senior engineer of the past derived authority from “knowing the answer”; the senior engineer of today derives value from “knowing how to find the answer.” This is a fundamental move from “accumulator of experience” to “creator of method.” What he teaches newcomers is not the concrete solution an AI can supply anyway, but the criteria for judging whether a solution is good, the wisdom to choose among countless possibilities.

His job must shift completely from “giving people fish” to “teaching people to fish” — and specifically, to teaching them to fish in a new era.

This shows up concretely in:

1. A shift in the center of gravity of code review: In the past, we asked: “Does the code run? Are there bugs? Does it follow the conventions?” Now we must ask: “Why did you choose to have the AI solve it this way? Did you make it try other approaches? What is the long-term cost of this solution? How do you verify its boundary conditions?” This is a review of the quality of thinking, not the quality of code.
2. An upgrade of the pair programming model: Let the newcomer “lead,” let the AI be the “hands,” and let the senior engineer be the “mouth” and the “brain.” This three-way collaboration forms a new learning ecosystem: the newcomer learns in practice how to “steer,” the AI provides immediate execution feedback, and the senior engineer provides “metacognitive” guidance. The newcomer is responsible for asking questions and directing the AI; the senior engineer sits alongside, not touching the keyboard, but constantly probing, prompting, and explaining. For example: “That instruction you just gave was too vague — the AI may have misread it. Let’s try a more precise phrasing.” Or: “Look, this solution the AI proposed doesn’t account for a piece of historical baggage specific to our system. That will cause problems.” The beauty of this method is that the newcomer learns on two levels at once — from the AI, how to do it; from the senior engineer, why to do it this way and how else it could be done.
3. Teaching methodology for troubleshooting: When a problem arises, do not hand over the answer directly. Instead, guide the newcomer to “ask the right question.” But here is a dialectic: what is a “right question”? Often you only know after asking countless “wrong questions.” So the senior engineer’s task is not to prevent newcomers from making mistakes but to help them learn quickly from those mistakes. “Given this symptom, which parts of the system do you think the root cause could lie in? What should we ask the AI to help us localize it? Do you believe the diagnosis the AI gave? Why?” Every question cultivates the newcomer’s problem awareness — not telling him the answer, but teaching him how to find it.

The senior engineer must become the team’s ideological “ballast stone,” making sure that when everyone uses this powerful tool, the heading stays true and does not drift away from the fundamental goal of “building robust, reliable, maintainable systems.”

The Future of “Deliberate Practice”: Training Three Decisive Capabilities

The principle that “practice makes perfect” has not changed, but the object of “familiarity” has. In the past it was “fluency in coding”; now it is fluency in the core capabilities of human-AI collaboration. I believe future “deliberate practice” should concentrate on three areas:

1. The ability to ask precise questions and define problems: The ceiling of AI’s capability depends on the level of our questions. But here is a paradox: how do you develop the ability to ask questions? The answer lies precisely in continually asking bad questions, and then learning from the AI’s “misunderstandings.” It is like a child learning to speak — not through a grammar book, but through constant trial, error, and correction. To be able to turn a murky, vague business requirement into a series of clear, precise, unambiguous instructions and questions is itself an activity of the highest intelligence. What must be practiced is how to use language as a tool to precisely frame a problem. This is closer to the essence of software engineering than writing code is — because the core of software engineering has always been “understanding the problem,” not “writing the code.”

2. The ability to be systematically skeptical and critically review: Toward AI’s output, we must adopt the attitude that “distrust is the first principle.” But this skepticism cannot be blind; it must be grounded. Where does the grounding come from? Precisely from practice — from continuously verifying AI’s output and accumulating experience about “under what circumstances AI tends to err.” We should examine every piece of “evidence” it presents like a strict judge. Practice designing devious test cases; practice challenging the AI’s solutions across security, performance, and ethical dimensions. This ability is the last line of defense for system quality and the concentrated expression of human value. Remember: the weapon of criticism cannot replace the criticism of weapons — criticism of AI’s output must ultimately be tested in practice.

3. The ability to architect and integrate: AI can generate “parts,” but it cannot build a “cathedral.” It can hand you a brick or a beam, but it cannot conjure a grand blueprint out of nothing. Yet here is a deeper problem: how does someone who has never assembled parts by hand understand how the parts fit together? The answer is that the architect of the new era does not understand the system by assembling parts; he guides the assembly of parts by understanding the system. It is like playing chess: you need not carve the pieces yourself, but you must understand the role of each piece and how they relate. What must be practiced is how to take the countless scattered, possibly locally optimal components AI generates and organically compose them into an elegant, robust, harmonious whole. This requires a deep understanding of the connections, contradictions, and dependencies among the parts, and it requires making trade-offs. This is the true “architect” mindset, and cultivating it depends far more on studying and analyzing excellent systems than on repetitive coding practice.

Conclusion

Do not be lost because “the ladder has been pulled away.” The old ladder is gone, but a new and more efficient ascent is taking shape. Our task is to know it, master it, and put it to use.

For a company, the way to cultivate newcomers at scale is to systematically overhaul the entire development system:

• At the entry point: Reform the newcomer’s first task, changing it from “manual labor” into “intellectual labor.”
• In the process: Redefine the senior engineer’s responsibilities so that they become “evangelists” of thinking and method.
• At the goal: Clarify the core capabilities that will require “deliberate practice” in the future, and design the corresponding training methods.

This brings us back to the deeper meaning of “teaching and learning promote each other” from The Book of Rites. In the AI era, this mutual growth takes new forms: not only growth between people, but growth between people and AI. The newcomer learns in the very act of “teaching” the AI how to solve a problem; the senior engineer deepens his understanding while guiding the newcomer. AI becomes the catalyst in this mutual growth — it is at once student (needing guidance), tool (aiding learning), and mirror (reflecting the quality of our thinking).

In the final analysis, we must hold to one conviction: the masses are the real heroes. But in the AI era, the meaning of “the masses” must be expanded — it includes not only engineers who use AI but also those whom AI affects; not only those who write code but also those who review it; not only those who invent methods but also those who validate them. In this transformation of the productive forces triggered by AI, everyone is exploring new possibilities in their own way. Our responsibility is to take this scattered wisdom arising from practice, to carry it “from the masses, to the masses,” to systematize and theorize it, and then to use it to guide new practice.

The road is tortuous; the prospects are bright. The old path of growth has indeed been altered — but this is not regression, it is a spiral ascent. We have not lost the chance to “climb the mountain”; we have gained the vantage point from which to “behold the mountain.” At this new height, what we must do is open our eyes wide, see clearly the principal contradiction of things, and then resolve it with courage and with truth-seeking pragmatism. Remember: methods may change, tools may change, but the spirit that pursues truth and progress must not. That is what allows us to stand firm in any era.