AI Replacing Programmers: Don't Rush to Switch Careers

I noticed an interesting detail. This time, Lü Weifeng, Vice Chairman and Secretary-General of the China Software Industry Association, responded to "AI replacing programmers" by using the phrase "highly valued," and also mentioned supporting employees in transitioning to high-value-added roles. In the context of the industry, this feels more like pushing the question from "can models write code?" a step further, onto jobs, organizations, and industrial distribution. This direction is worth investing in, but before investing, you need to get your organizational accounting straight.

I've led teams of over a hundred people, and I'm still looking at AI platforms, CI, testing pipelines, and compute costs. Over the past month, I integrated tools like Copilot, Claude Code, Kimi K3, and Tencent Hunyuan Hy3 into our daily R&D process, and recently hooked up the testing pipeline to run on CI. The results are direct: code generation speed has indeed increased, but the team hasn't become any easier off. Many reworks haven't disappeared; they've just changed locations. Before, it was humans writing wrong logic; now it's AI providing an implementation that looks reasonable but has no one backing up the edge cases. Before, requirements weren't aligned; now, with unaligned requirements, the volume of code clearly increases, and review pressure goes up too.

This is why I'm reluctant to understand "AI replacing programmers" as job disappearance. More accurately, it first replaces the vague, repetitive, and acceptance-lacking parts of engineering processes. I find Academician Mei Hong's judgment weighty: historically, programming methods and tools have always evolved, changing the division of labor each round. What's different about this AI round is that it starts entering "implementation" itself, compressing the initial coding, boilerplate code, and interface glue that used to rely on accumulated experience down to a very low cost. Thus, what becomes scarce in organizations are people who can clearly articulate business rules, system boundaries, risk responsibilities, and acceptance criteria.

So-called high-value-added roles cannot just remain slogans. From my perspective, at least three types of work will be elevated. One is the owner of requirements and domain rules. Implicit rules in finance, healthcare, industry, and automotive sectors are hard for models to fill in on their own. It can write a function that looks plausible, but it doesn't know why an approval flow can't skip steps, or why a certain gray-release strategy might cause downstream systems to avalanche. Another type is the designer of evaluation and acceptance systems. I wrote a post last week about solo AI development, with the gist being "don't rush to make it a team template," and the reason lies here. A single person running a demo through AI doesn't mean the team can copy-paste it. Teams need reproducible tests, traceable defects, and quantifiable launch thresholds. The third type is platform engineering in the AI era. Permissions, compute, logs, observability, rollbacks, and costs—these don't look sexy, but they determine whether AI can go from a toy to a productivity tool.

So when I see news about "transitioning to high-value-added roles," I care more about how enterprises implement it. Many companies hear "AI" and immediately ask if they can cut headcount. That question is too crude. I care more about whether ROI has been calculated. If AI just lets junior engineers write less boilerplate code but makes senior engineers spend more time on security reviews, it might just be shifting costs from coding to maintenance. Conversely, if teams can use AI to organize interface documentation, test cases, requirement tracking, and release checklists, even without cutting headcount, delivery cycles and accident rates might improve. From a management perspective, the former is saving small money while losing big; the latter is slow work, but the direction is right.

I've also seen quite a bit of job anxiety recently, discussing which developers get replaced first. Honestly, this ranking tends to oversimplify the problem. What gets compressed first is often a certain way of working, such as only waiting for clear requirements, only doing CRUD, relying solely on copy-paste, avoiding online responsibility, not writing acceptance criteria, and not doing retrospectives. AI boosts efficiency for this type of work quickly because if input/output boundaries are clear, models can indeed run the loop for humans. But once inputs are vague and outputs require accountability, AI isn't so useful. It pushes people into uncomfortable positions, forcing them to turn the "roughly correct" stuff in their heads into machine-executable rules.

For enterprises, this change demands more from organizational structure than from individuals. Previously, much knowledge was locked in veteran employees' heads—requirements, historical baggage, gray-release strategies, verbal promises to clients—all relied on human transmission. After AI arrives, if this implicit knowledge continues to remain un-explicitized, it becomes a source of accidents. I even feel that future team management needs to be like managing multi-Agent systems: setting boundaries, permissions, acceptance criteria, and failure attribution for each role. Otherwise, multi-Agent collaboration sounds advanced but is actually just a cost amplifier. This judgment applies to humans too. Organizations won't automatically become smarter just because you used a few models.

From an individual perspective, I also don't recommend rushing to sign up for a bunch of courses upon hearing about transition. First, break down the value chain of your current work. Are you producing code, decisions, or trust? If it's just code, AI will indeed drive down the price. If you can define problems, judge risks, align business with technology, and ensure systems don't blow up after launch, then the room for transition is right in front of you. High value-add depends on whether you can turn your judgment into assets that are reusable, verifiable, and accountable within the team.

Looking ahead, there won't be a unified answer soon. The industry association stating "highly valued" indicates it has moved beyond internal tech circle discussions into industrial expectations and talent policy levels. For enterprises, the more pragmatic approach is not to treat AI as a layoff excuse, nor as a panacea. Start with one project, one pipeline, one set of acceptance criteria. If it works, expand. If it doesn't, take some organizational classes first. What AI replaces are those engineering actions that lack clear definition, acceptance boundaries, and responsibility attribution.