Recently I have been following and learning some new technologies, and also doing some hands-on AI development work myself. This has given me some increasingly clear thoughts about the question of whether programmers will lose their jobs. From the beginning, I did not think programmers would simply become unemployed or disappear because of AI. What is really worth discussing is not whether code itself will be replaced, but what changes are taking place in the structure of software development once AI arrives, and what position programmers will be pushed into as a result.
A lot of current discussion starts by treating software development as if it were the same thing as writing code, and then moves quickly to a conclusion—if AI can already write code, modify code, and explain code, then programmers must obviously be in danger. That line of reasoning seems smooth, but its premise is already too narrow. Traditional software development has never been only about writing code. In many cases, the most important parts were never in the coding itself. Requirements analysis, system design, testing, deployment, operation, maintenance, performance, security, boundary control, and judgment about real user scenarios have always been there. It is only that, in the past, the cost of manual coding was so high and so visible that it covered up many of the more essential parts. The arrival of AI has not made software development simple. It has exposed software development more clearly for what it already was.
If we look back at the traditional programming era, its most symbolic marker was often Hello, World!. It represented a typical feature of that era—human beings used explicit logic and syntax to issue precise instructions to machines, proving that they could control the system and make it run in a predetermined way. In that sense, the core entry point of traditional software was function, and its core mechanism was logic. Programmers had to compress, decompose, and translate human purposes until they became expressions that machines could execute strictly. The machine did not understand your real intention. It only executed what had already been formalized.
What changes in the AI era is that the entry level of software is moving upward. Software used to mainly understand functions. Now it is beginning to try to understand intent. A function answers what the system is supposed to do. Intent answers why a person wants to do it. Functions have usually already been organized, split apart, and narrowed down. Intent is closer to a person’s original purpose. It naturally carries ambiguity, context, preference, constraints, and expectations that have not been fully stated. Traditional software usually required users to adapt to the system first, break their purposes into a set of selectable functions, and then operate them one by one. AI software is increasingly inclined to receive human intent first, and then gradually translate that intent into tasks, steps, tool calls, and final outcomes.
So this can indeed be understood as a shift from logical programming toward semantic programming. But this does not mean logic has disappeared, nor that code has become invalid. It means the dominant layer of programming has changed. In the past, humans directly wrote logic. Now, more and more, humans define goals, boundaries, context, and acceptance criteria at the semantic level, and then let the system generate, organize, and invoke logic underneath. Logic has not disappeared. It has sunk downward. Semantics has moved to the front, and logic has moved to the back. You could also say that programming is moving from the precise specification of functions toward the stable handling of intent.
In that sense, programmers as a whole will not disappear. They will be elevated. By elevation I do not mean that programmers suddenly become more noble. I mean that the center of gravity of the role is being pushed upward. In the past, the most visible work of programmers was to write functions one by one and organize flows and branches tightly. Now that more and more local implementation can be handed off to AI, the value of programmers is no longer mainly reflected in the amount of manual code they produce. It is increasingly reflected in whether they can define the right problem, construct stable semantic boundaries, reduce vague intentions into reliable system behavior, judge whether the result is valid, control risks, correct deviations, and coordinate the relationships between different modules and different tools.
But this should not be stated too lightly either. Programmers as a whole will not disappear, but that does not mean every software worker will automatically pass safely into the next stage. People who only know how to write code, especially code that is superficial, repetitive, and lacking in overall judgment, do face a very real danger of unemployment. The key issue is not the word “junior” itself. The key issue is whether a person’s ability structure remains mostly at the layer that can be rapidly replaced. If someone’s main value lies in writing CRUD operations according to clear instructions, changing a few pages, connecting a few APIs, fixing some small bugs with stable patterns, or assembling low-complexity pieces within an existing framework, then this kind of work is the easiest for AI to compress in price or replace directly. What is dangerous is not youth. What is dangerous is a capability structure that is too thin. What will be replaced first is not the profession of programmer itself, but the part of a programmer’s abilities that is easiest to replace.
This also shows why it is wrong to lump software professionals together under a label like “code monkeys.” The biggest problem with that phrase is not only that it is dismissive. It is also conceptually crude. It assumes that the essence of software work is merely “typing code,” as if code relates to software in the same way that written characters relate to all writing. But the difference here is much larger than that. Calligraphy and novel writing both involve writing words on the surface, yet they are fundamentally not the same activity. The first focuses on stroke, form, control, and presentation. The second focuses on thought, narrative, character, structure, and expression. Of course the two overlap, but you cannot merge them into the same thing simply because both require writing. Software development is similar. Code is only one medium of expression. It is not the whole content, and certainly not the whole value. A real software professional often works much more on understanding problems, abstracting structures, designing systems, coordinating constraints, making judgments and tradeoffs, controlling risks, and validating results. To understand software development as “writing code” is like understanding novels as “writing words.” On the surface it is not wrong, but in substance it says almost nothing.
What AI is really bringing into the foreground, then, is precisely the work that always belonged to the core of software development but was often hidden by the labor of coding. Early requirements analysis becomes more important, because the easier code is to generate, the easier it is to build a wrong direction into something complete very quickly. If requirements are not understood clearly, AI will only amplify the mistake. It will not automatically correct it. Design also becomes more important, because questions such as how to divide system boundaries, how state should flow, which capabilities should be tightly controlled, which should remain open, which parts can tolerate error, and which parts must remain strict cannot be solved by having AI generate a few pieces of code. The same is true at the later stages with testing and deployment. Testing is not there to prove that something can more or less run. It is there to confirm that the system remains predictable even under abnormal conditions. Deployment is not just sending the program out into the world. It requires thinking about environmental differences, version compatibility, dependency management, logging, rollback mechanisms, update strategy, and data security. AI can compress implementation time, but it does not eliminate any of these stages.
If we look further, software development also involves many engineering problems that are harder than merely “writing functionality.” Real software systems do not live on a blank sheet of paper. They must deal with operating systems, file systems, networks, databases, browsers, third-party services, permission models, and resource constraints. They must handle cross-system calls, concurrency and state synchronization, consistency in distributed environments, retries, failure recovery, message loss, security risks, performance bottlenecks, latency control, resource contention, and malicious input. Many demos appear to work, but the moment they enter a real environment their problems are exposed, and this is why. Writing one piece of local functional code is not the same thing as making a system survive stably in a complex world. The former can become increasingly automated. The latter still requires deep engineering judgment.
So understanding code is not unnecessary. It is just that its necessity has to be reinterpreted. Whether you personally write something line by line and whether you need to understand the technical chain are two different matters. From machine language to assembly language, then to high-level languages, then to frameworks, runtimes, models, and now semantic tools, abstraction has moved upward layer by layer. Human beings truly do need less and less to return to the bottom layer and operate everything by hand. But that does not mean lower-level understanding has become irrelevant. The higher the abstraction, the more complex the system becomes. When problems arise, someone still has to be able to look downward and determine whether the issue lies in semantic understanding, task decomposition, code generation, interface contracts, the execution environment, or still deeper resources and mechanisms. The truly strong people of the future may not stay at the bottom layer every day, but they will definitely be able to move across levels of abstraction. In ordinary times they stand at the higher level and organize goals and structures. When necessary, they can dive downward and see the problem clearly. Whether you do something by hand may change. Whether you truly understand it cannot be abandoned.
This also further shows that future software developers cannot rely on coding thinking alone. They must also have product thinking, market thinking, and systems thinking. Coding ability still matters, but it is no longer the whole picture. Product thinking determines whether you really understand the user’s problem and whether you know what is worth building and what is not. Market thinking determines whether you can judge whether something that is technically possible also has real-world value, whether people are willing to use it, and whether it has communicability and continuity. Systems thinking determines whether you can consider requirements, structure, cost, security, engineering constraints, and long-term evolution together. In the past, many technical people could postpone these questions because simply getting something built was already hard enough. Now that building something is becoming less scarce in itself, what becomes truly scarce is the ability to place technology correctly into a real structure of value.
So the AI era is not reducing software development to speaking one sentence and letting the machine do the rest. It is revealing software development for what it has always been. It has always been a complete chain, with requirements analysis and problem definition at the front, design, implementation, and integration in the middle, and testing, deployment, operation, and maintenance at the back. It has never been only a matter of assembling logic. It has always been about constructing a workable whole around human purposes, system boundaries, and real-world constraints. What AI first changes are only some of the implementation links in that chain, but in doing so it makes the more essential parts of the chain stand out even more clearly.
If this change had to be summarized in one sentence, it would be this—software is moving from understanding functions toward understanding intent. Traditional software mainly understands predefined functions. AI software is beginning to try to understand what the user is really trying to achieve, and then gradually reduce that intent into tasks, plans, tool calls, and feedback on results. This change does not eliminate functions, nor does it eliminate logic. It turns both functions and logic into lower-level supporting mechanisms. The human position has moved upward, and so has the entry point of software.
So what is really happening in the AI era is not that programmers are disappearing, not that code has stopped mattering, and not that software development has suddenly become something light and easy. What is really happening is that the real structure of software development is being seen again. Programmers are moving from direct producers of code toward organizers, constraint-setters, and arbiters of intelligent systems. Programming is moving from the direct construction of logic toward the organization of the mapping between semantics and logic. Software is moving from responding to predefined functions toward handling human intent. Code still matters, but it increasingly looks like the middle section of a value chain rather than the exclusive center.
This is not the end of programming. It is programming entering a new stage—higher level, more integrated, and also more demanding.
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.