From Craftsman to Guide: Redefining the Programmer's Role in the Age of AI

The gentleman is not a vessel. — The Analects · Wei Zheng

In the age of AI, a programmer’s value lies not in becoming some particular “vessel,” but in possessing wisdom across many dimensions: weighing technology against business, clarifying the vague into the precise, bearing responsibility for what is generated, and leading between inheritance and innovation. We transcend mere skill to become nodes of wisdom connecting different domains.

A note before we begin: the upheaval set off by AI coding agents will reshape our future in many ways. Gemini and I discussed this at length; what follows is the organized and revised result, shared with you here.

The Engineer’s Irreplaceable Core Value

To keep this from staying too abstract, let’s examine it from a few concrete angles.

First: On “Creation” and “Judgment”

Imagine AI as an incomparably skilled craftsman who can instantly produce any part you ask for, down to the last millimeter. In that case, who is more valuable — the person who draws the “blueprint,” or the person who “signs off on the finished product”?

• When AI hands you five “correct” solutions to a problem, what lets you pick the “best” one? Is it your knowledge of programming languages? Or is it your deep understanding of the system, the business, and the changes that may yet come — what we usually call “taste” and “judgment”?
• Among the tens of thousands of lines of AI-generated code, spotting that subtle logic flaw that could bring the system down under extreme conditions — isn’t the value of this “insight” actually amplified?
• When is an engineer’s most valuable contribution to say “no,” to propose “we shouldn’t build this feature,” or “this technical direction is fundamentally wrong”? Where do the courage and wisdom to veto come from? Can AI possess them?

So where does the value of “creation” and “judgment” lie? I believe it lies in “trade-offs.”

We ask: when AI can offer five solutions, how do you choose the best one?

Perhaps no absolute “best” exists at all. Every engineering decision is, in essence, a trade-off under a host of constraints. Solution A delivers the highest performance, but its code is opaque and hard for newcomers to maintain; Solution B is the most readable, but introduces a new technical dependency; Solution C ships fastest, but plants the seeds of future technical debt.

AI can analyze the “complexity” of code — but can it understand your team’s “capacity boundaries”? AI can evaluate an algorithm’s “efficiency” — but can it weigh “business urgency” against “investor patience”?

From this it seems the engineer’s core value is as an “interpreter of context” and a “wise weigher of trade-offs.” They stand at the crossroads where technology, business, and human nature meet, making the decision that is most appropriate for the moment rather than most perfect. This kind of judgment, grounded in multidimensional context, is hard for AI to reach.

And so a new question emerges: if this “wisdom of trade-offs” is key, how do we cultivate it? Should we have engineers participate more in business discussions and user interviews, or should they study things that seem unrelated to code — economics, say, or psychology?

Second: On “Translation” and “Connection”

Is an engineer’s work really just a conversation with machines?

• Don’t they often play the role of “translator” — turning a product manager’s vague, even self-contradictory requirements into precise, unambiguous logic a machine can understand? Turning complex technical realities into a language their colleagues can follow? What is the value of this act of “translation”?
• They are the “connection points” in a team, needing to collaborate, argue, compromise, and reach consensus with others. They mentor newcomers and learn from their elders. Isn’t this human-to-human “connection” something no AI can replace? And when code can be generated in seconds, does the value of this communication and collaboration fall — or rise?

So where does the value of “translation” and “connection” lie? I believe it lies in “clarification.”

We called engineers “translators.” Let’s go one layer deeper.

A great translation is not a word-for-word correspondence; it re-embodies the soul of the original in another language. When a product manager says “I want a smarter recommendation system,” his real meaning can vary wildly. He might be expressing anxiety about user churn; he might have just seen a competitor’s new feature.

AI can understand the instruction “smart recommendation,” but it cannot probe the unspoken, fuzzy, emotionally charged “true intent” behind that instruction. A good engineer, by contrast, will “clarify” that intent through follow-up questions, challenges, even a minimal prototype. In that act of clarification, the requirement itself may be reshaped — or rejected outright. This process, moving from chaos to order, is creation of the highest value.

So the new question is: in a team that prizes “agile development” and “rapid iteration,” should we encourage engineers to spend more time clarifying the problem, or should we push them to execute the instruction as fast as possible? How do we build a culture in which this questioning and clarifying — which seems to “slow things down” — is recognized as the most efficient contribution of all?

Third: On “Ownership” and “Responsibility”

A programmer’s main worry about AI-generated code is: “If I didn’t write it, I don’t understand it.”

• When the system fails — especially late at night, when users are complaining, when every second of downtime costs money — what does the person who has to step up and fix it need? The ability to generate code fast, the ability to solve problems fast, or an “ownership” and deep understanding of every corner of the system?
• AI can generate code, but will AI take responsibility for the ultimate outcome of that code? On whose shoulders does this ultimate “responsibility” finally land? And what abilities and qualities does bearing it demand?

So where does the value of “ownership” and “responsibility” lie? I believe it lies in “internalization.”

The engineer handling an outage at midnight needs an “intuition” about the system.

That intuition comes from every “pit” he personally fell into while building it, from the endless debates over each design decision, from debugging after failure after failure. Every line of code is bound to some memory and some thought of his. This process of “internalizing” external logic into his own knowledge and intuition is what grants him true “ownership.”

AI-generated code is like a borrowed book: you can read it, but you never wrote your own notes and reflections in the margins. You haven’t “internalized” it. So when a crisis comes, you can’t wield its knowledge with any ease.

Our challenge, then, becomes: how do we “internalize” AI-assisted code? Do we need a new process? How do we design new rituals to complete this transformation from “generation” to “ownership”?

Fourth: On “Growth” and “Learning”

If AI takes over a large share of coding work, how does a junior engineer grow into a senior one?

• What will “practice” look like in the future? Practicing how to ask AI better questions? Or practicing how to review AI’s code, design better systems, debug more complex problems?
• We used to rely on “writing code” to consolidate learning and deepen understanding. In this new era, how should we construct new learning paths that cultivate genuinely deep understanding, rather than merely producing AI operators?

By exploring these questions, we seem to glimpse a portrait of the engineer’s new value: no longer merely the ability to write, but the ability to judge, design, communicate, take responsibility, and keep learning.

So where does the value of “growth” and “learning” lie? I believe it lies in “leading.”

We worry about the growth path of junior engineers.

Perhaps the future model of growth is no longer “from laying bricks to raising towers,” but “from apprentice to master.” AI is that tireless but mindless sorcerer’s broom. What the apprentice must learn is not how to fetch the water himself, but how to observe and understand how the master — the senior engineer — commands, guides, and steers that broom.

The senior engineer’s value is no longer merely writing the most exquisite code, but making his “wisdom of trade-offs,” “art of clarification,” and “process of internalization” visible and learnable. Like a commentator, he must continually explain to the team: “I had AI do it this way because…” “The solution AI gave looked good, but I rejected it, and here’s why…” If you’re a senior engineer, see Jon Gjengset’s YouTube video: Vibe coding complex changes in Rust. It’s a very good example of vibe coding.

This means that within a senior engineer’s core responsibilities, the weight of “teaching” and “leading” will rise to an unprecedented level.

And so our final question becomes clearer and sharper: if the senior engineer’s future core value is “leading thought,” then you — the person on your team with the deepest understanding of AI — how will you begin to play the role of “guide”?

Let’s Talk About Growth in Depth

“Growth” — the word itself brims with vitality and hope. It acknowledges that we’re living through an era of change, but it focuses not on passively “not being eliminated,” but actively on “how to become stronger.”

The Ladder of Growth

In the past, an engineer’s growth path was familiar to all of us, wasn’t it? Like climbing a mountain: starting at the foot by fixing small bugs, step by step upward, fixing harder problems, building small features, then designing complex systems, and finally standing at the summit, able to survey the whole project. Every step was firsthand experience; every drop of sweat became a deep understanding of that mountain.

Now AI is like a cable car that can carry you straight to the halfway point, or higher still. It can fix your bugs; it can build your features.

So the question arises: when part of the climbing ladder is pulled away, how do we redraw this path of growth for ourselves and for others? For a beginner who never struggled on the rugged trails, can he truly understand the view from the summit? Can he gain the ability to find his bearings in the mountains and weather the storms?

The Newcomer’s “First Step”

Let’s focus on the youngest members of the team. In the past, we might have had them fix a piece of copy, correct a simple UI issue. Simple tasks, yes — but they familiarized him with the codebase, built his confidence, and let him experience a full commit–review–deploy cycle. It was his ritual of joining the team.

Today, these tasks can perhaps be done in minutes with one AI instruction. So how do we design a newcomer’s “first task”?

What is that task for? To teach him to use tools with maximum efficiency, or to build the deepest possible understanding of the code? Do we have him “supervise” AI through the simple task, or do we deliberately, artificially preserve some “less efficient” but educational manual tasks for him? Behind that choice lies our value judgment about “growth.”

How Should Senior Engineers Fulfill Their Duty to Lead?

If the senior engineer of the past was “the strongest climber,” then the senior engineer of the future should be more like “an excellent guide.” His job is no longer to reach the summit fastest himself, but to teach the team how to ride the “cable car” safely, how to read the map of places the cable car cannot reach, and how to open new paths on their own once they arrive.

How does this “guide” duty show up in daily work? Is it in code review, shifting from asking “does the code run?” to asking “why did AI choose this solution — have you considered others?” Is it in pair programming, letting AI write while you concentrate on narrating and steering the thinking alongside? Is it in incident response, focusing on helping newcomers ask the right questions and understand the new methodology, rather than simply handing them the answer?

The “Deliberate Practice” of the Future

In the past we said “practice makes perfect,” and that “practice” meant writing code over and over. Now the act of “writing” is partly replaced. So what is “deliberate practice” in the future? How do we hone our craft?

What should we practice in order to become stronger?

Is it the ability to ask — how to describe a complex, fuzzy problem to AI in the most precise language? Is it the ability to doubt — how to design the trickiest test cases to review and challenge AI’s answers? Or is it the ability to integrate — how to take AI-generated fragments and, like an architect, assemble them into an elegant, robust, harmonious whole?

None of these questions has a standard answer. But the questions themselves are a path to growth.