What Kind of Programmers Are Needed in the AI Era?

Every year on October 24, known as “Programmer’s Day,” the tech community celebrates the contributions of programmers. This day, 1024, symbolizes the romance of binary and the foundational principles of programming. However, as AI becomes a dominant tool, we must ask ourselves: how much of the programmer’s role still involves the “human” element? Do we still need programmers?

Last year, some were still writing code by hand; this year, they are teaching AI how to code. What about next year? Will they become AI prompt engineers, never touching a compiler again? Is this day a celebration of a profession’s glory or a quiet memorial for a status that is fading away?

Do we still need to memorize syntax, algorithms, and frameworks? Should we still understand optimization, refactoring, and performance tuning? If “writing code” is no longer a core competency for programmers, what kind of programmers do we need?

The Old Way of Programming

In the early 2000s, learning programming was a ritualistic endeavor. You started with C, tackled data structures, managed pointers, and memorized algorithms. When encountering errors, you copied the exceptions, searched online, and carefully tested your fixes. Programmers then resembled farmers, trading time for growth and labor for output.

Even by 2015, technology was evolving in a linear fashion: Java matured, Python became the darling of data science, and frameworks like jQuery, Vue, and React emerged, all focused on how to create attractive, functional pages more efficiently. Experience was built brick by brick, akin to a sushi master spending years perfecting their craft. Today, however, the need to slice cucumbers has vanished.

The arrival of generative AI has changed the game. The best programmers are no longer the fastest coders but those who can guide AI to produce quality code. They must be like the dream architects in “Inception,” knowing how to create environments, set constraints, and build prompts. They no longer write “code”; they create “scenes for code construction.”

The Challenges for Veteran Programmers

However, not everyone can switch operating systems in time. I know a senior engineer in his forties whose resume boasts participation in developing a national bank’s core system. Despite his experience, when using Copilot, he struggles to keep up, rewriting AI-generated code due to concerns about its rigor. He only produces about 300 lines a day, less than an intern.

His issue isn’t a lack of ability but a mismatch in thinking models. He believes code is something to be crafted, not generated. Software is built, not just fed prompts. The reality has shifted; now, the real time investment lies in designing effective prompts and deciding what tasks AI can handle versus what requires manual optimization.

The accumulated experience has become a set of outdated habits that need reevaluation. His efforts are commendable, but the direction is obsolete.

The Risks for AI-Native Graduates

We shouldn’t rush to praise the “AI-native” graduates either. I’ve seen many recent graduates who can write prompts quickly and switch tools with ease. They let AI handle code generation and use design tools for interface creation, but when product iterations require integration with ERP systems, they falter. They lack understanding of why certain financial reconciliation timelines are peculiar and why government procurement contracts need to be split into sub-items.

They assume AI is omnipotent, only to be slapped by reality. They don’t realize that the history of complex business processes is not in code but in people. Enterprise processes are the result of decades of accumulated inertia. Departments like finance, internal control, and legal cannot be overnight restructured by AI; they must be understood, not bypassed. Even if you can generate all APIs with AI, you need to know that some field names are remnants of compatibility issues from a decade ago—untouchable and unchangeable.

We find ourselves in a strange phase where writing code resembles drawing. You sketch a vague idea, and AI fills in the structure you intend to convey. Some have begun to think, “As long as my vibe is right, the code will appear on its own.” This may hold true in certain scenarios, but when facing a legacy system spanning seven subsystems with data sources scattered across three locations and documentation mixed with Excel and PDFs, vibe coding is akin to using sketching techniques for urban planning. You need to understand how the city developed, where the pipes run, whether walls bear weight, and what historical issues have been left behind. Which lines of code are buried under technical debt that three generations of programmers dare not touch? Which API documentation has long gone unupdated due to fear of repercussions?

What Kind of Programmers Do We Need?

So, what kind of programmers do we need? Not those stuck in the C language era, handwriting everything; nor those floating on the AI cloud, relying solely on model outputs to go live. We need “hybrid” programmers who can speak both machine language and human language, engaging with AI tools while also understanding business, systems, and history. They are “bilingual programmers”—fluent in code and organizational language.

They understand that prompts are not just keyword stacks but context-rich system design specifications; deployment is not mere copy-pasting but assessing the entire service dependency chain; and understanding why a field cannot be changed is not just a technical issue but a blend of business inertia and historical baggage.

Valuable programmers are not the fastest or most skilled with tools; they are those who recognize that “systems are products of time, and problems often stem from people.” They can see through an architectural design diagram to uncover the compromises made by generations and can anticipate potential model errors based on prompt design. Their problem-solving approach is not about having the most powerful tools but the most stable judgment.

This type of individual is increasingly sought after by companies. Large firms like Meta, Google, Alibaba, and Tencent are not looking for “code-writing machines” but technical coordinators who can harness AI tools to ensure that the code produced runs smoothly and lasts. Startups are even more direct: you need to handle an entire system alone—modeling, designing, implementing, and launching. AI tools can help, but the prerequisite is knowing which parts can be automated and which must rely on you.

Programmers Are Becoming System Designers

This profession is becoming less about “craft” and more about “structure.” Just as architects no longer lay bricks themselves, programmers no longer write every line of code. Bricks can be handed to machines; structure must be determined by humans. The new golden skill is not “coding” but “abstraction.” You must understand the dependencies of complex systems, know which components can be reused, and which interfaces need rewriting. You should be able to quickly assess the cost of technical debt and foresee maintenance costs five years down the line.

The most important abilities for future programmers will be: system abstraction capability—understanding complex relationships; architectural judgment capability—controlling the overall rhythm; historical understanding capability—knowing why problems have evolved. These are skills that AI cannot provide.

Jin Yong wrote in “The Smiling, Proud Wanderer”: “No move is better than a move.” When you master every technique, you can be flexible and adapt. The future of programmers is precisely this: when you master all languages, frameworks, and tools, you can put them down and have the ability to flexibly combine, choose, and create a “sustainable” solution based on business objectives, technical constraints, and time costs.

Writing code is merely a means; solving problems is the goal. The strongest programmers of the future may be those who can challenge AI, articulate requirements clearly, and neither idolize AI nor fear unemployment. They understand that the ones truly eliminated are not those who don’t know new tools, but those who refuse to update their cognitive models.

The new generation of technical interviews may no longer ask, “Can you write code?” but rather, “Can you understand the essence of the problem and design an AI-compatible solution that respects history?”

The Turing Test was once used to determine if a machine could mimic humans. For programmers today, the Turing Test has transformed into a different question: can you maintain your human judgment in an era flooded with AI tools?

Can you remain discerning and not blindly follow AI tools? Do you still possess human instincts: judgment, abstraction, and system awareness? Can you still grasp the full scope of a problem without relying solely on input fields?

Perhaps one day, the term “programmer” will be replaced by new titles: technical structure architect, AI system coordinator, human-computer interaction logic designer… Regardless of the name, the 1024 celebration should always belong to those who can master technology, understand complexity, and continuously evolve.

Happy Programmer’s Day to all of you who are evolving!