What should the developers in the information department do when programmers' salaries drop to 5000?

In Lao Yang's article "When Programmers' Salaries Drop to 5000 RMB, Hire Humans or Use AI Coding", the most discussed line in the backend and group chats is: What should the developers in the IT department do? Will the boss use the market rate of 5000 RMB from outside to cut our headcount?

When the marginal cost of AI Coding approaches zero, and the cost of low-end human labor is also driven down by the market, the value positioning of the development team is being redefined. Many people have not yet realized that the real problem is not "Will AI replace me", but "If I can only do what AI can do, what value do I still have?"

Three paths, choose one

In Lao Yang's view, when the external environment undergoes structural changes, there are no more than three coping strategies for individuals: move upward, move horizontally, or stay in place and be pushed along.

The first path: move upward, do things that AI cannot do.

AI is good at writing code, but not good at making judgments. If you still take "writing code" as your core competence, your living space will indeed be continuously compressed. And those things that AI cannot do are exactly the direction you need to move upstream.

Understand the business. AI can read requirement documents, but cannot understand the unspoken rules behind the business. Why do we need this function? Why is the process designed in this way? The answers only exist in the business context and cannot be written into prompts.

Technical decision-making. AI can generate Plan A and Plan B, but it has no judgment on which one to choose. What technology stack adapts to the team's current maintenance capabilities? What architecture can take into account the business evolution in the next three to five years? These require experience, trade-offs, and understanding of the team's current situation.

Guarantee the bottom line of quality. The code generated by AI seems to be runnable, but it has hidden pitfalls. Who will review it? Who will find the problems that "will crash under large data volume"? Who will deal with the hidden dangers of "correct generation logic but inconsistent with production environment configuration"?

Solve complex problems. When the system fails, AI can read logs, but cannot understand the business impact. Who can quickly locate the root cause, coordinate multiple parties, and make emergency decisions?

So it is not difficult to see that the direction is very clear: change yourself from "a person who writes code" to "a person who solves business problems". Code is a means, not an end. The goal is to make the business run faster, more stably and at lower cost.

The second path: move horizontally, become a native of AI.

Don't just treat AI as a code writing accelerator, but regard it as a new way of working. This means three things:

①. Use AI to do things you couldn't do before, such as generating test cases, automatically generating documents, and assisting code review;

②. Manage AI as a member of the team, be clear about what it can do, what it can't do, and under what circumstances manual intervention is mandatory;

③. Establish a working rhythm of human-machine collaboration, let AI take on the parts it is good at, and focus your energy on the parts it is not good at.

The difference here is: you are not "using AI", you are "collaborating with AI". This tiny difference determines whether you are the one to be replaced, or the one who controls the tool.

The third path: stay in place and accept the reality.

The cost of this path is that the boundary of your capabilities and the boundary of AI's capabilities are more and more overlapping. When the overlap reaches a certain level, bargaining power will disappear. The salary no longer depends on your ability, but on how many people can replace you. This path is not impossible to choose, but you need to be clear about the result before choosing.

The three paths have no right or wrong, only different costs. Think clearly before choosing, and don't regret after choosing.

Cut headcount, or improve capabilities?

This is the most realistic question at the management level. As the labor cost in the market continues to drop and AI tools become more and more popular, the first reaction of person in charge is often to do accounts: labor is cheaper, can we recruit a few more people? Or conversely, since AI can do it, can we use fewer people?

Both of these calculation methods are linear thinking, assuming that there is only one variable in the problem. In fact, the efficiency of the IT department is never the addition and subtraction of "number of people" and "number of tools", but the multiplier of "the efficiency of people using tools to solve problems".

What you need to answer is: What kind of team do I want to build to cope with the technological changes in the next three to five years?

Lao Yang believes that cutting headcount is a short-term account, and improving capabilities is a long-term account. The money saved by cutting headcount is one-time, and the efficiency improvement brought by improving capabilities is continuous compound interest. Unfortunately, most managers of traditional enterprises currently lack this awareness. You need to know that if a person's work can be replaced by AI, it means that he was originally doing low-value work. The problem is not with AI, but why he was arranged to do low-value work in the first place. So whose problem is this?

Does the enterprise have the conditions to "improve the capabilities of developers"?

This is a problem that enterprise managers must face. You can't improve capabilities just because you want to. Whether the preconditions are met determines whether the strategy can be implemented. Lao Yang believes that the evaluation should be carried out from the following three dimensions.

Premise 1: Are there enough "high-level work" to support capability improvement?

If all the work of the team is repetitive, templated, and low-complexity tasks, no matter how high the developers' capabilities are, they cannot be put into use. Capabilities are developed in practice, not trained. Without complex problems to solve, there is no soil for capability improvement.

Premise 2: Is there trust between managers and developers?

Improving capabilities means delegating power, allowing fault tolerance, allowing attempts of new methods, and allowing phased failures. If managers lack trust in developers, approve everything, and control at every level, the space for capability improvement will be extremely limited. The essence of capability is judgment, which must grow out of the practice of independent decision-making.

Premise 3: Is the enterprise's own digital maturity sufficient?

If the enterprise is still in the stage of "the system is barely usable", and the core demand is stability and no accidents, then any attempt to improve capabilities will be suppressed by the iron law of "stability first". This is not a matter of right or wrong, but a matter of different stages. When the foundation is unstable, the priority of capability improvement naturally comes later.

From the above, it is not difficult to see that improving capabilities is not a simple matter of one sentence. It requires the team to have appropriate tasks, managers to have correct management methods, and the enterprise to have sufficient carrying space. Forcibly promoting it when the conditions are not met is just another form of internal friction.

What should the development team look like?

The popularization of AI Coding will not eliminate the development team, but will change the talent structure of the development team. In the next three years, Lao Yang believes that three roles will coexist.

First, the architecture and design role, responsible for requirement analysis, system design, technology selection, and core module decision-making. This part cannot be done by AI, because it requires understanding of business context and long-term system evolution.

Second, the human-machine collaborative development role, responsible for using AI tools to quickly generate drafts, conduct code reviews, and handle complex integration and edge scenarios. This is the main execution force of the team.

Third, the quality and operation & maintenance role, responsible for system stability, performance monitoring, security reinforcement, and automated CI/CD. This part also requires human judgment as the final guarantee.

Low-level, repetitive coding positions will be greatly reduced, but high-level development positions that require judgment will not decrease, and will even be more scarce.

Final Conclusion

Price is determined by the market, and value is determined by yourself. The salary of programmers drops to 5000 RMB, which does not mean that "writing code" is worthless, but that "only being able to write code" is worthless.

If you can provide additional value on top of AI, understand the business, make judgments, and guarantee the bottom line of quality, your value will not decrease, but will rise because of scarcity.

The task of the head of the IT department is not to compress costs and cut headcount to protect himself, but to redefine the value of the team. When AI can do more, the team should also be able to do more. Not to develop more functions, but to do things at a higher dimension. This is the correct solution to cope with changes.

In your digital team, how many people are doing things that "AI can do"? And how many people are doing things that AI cannot do, such as understanding business, making technical decisions, and guaranteeing the bottom line of quality? Feel free to share in the comment area.

This article is from the WeChat Official Account "Xiangjiang Digital Review" (ID: benpaoshuzi), the author is Lao Yang, published with authorization from 36Kr.