AI’s potential threat to programming has been widely debated over the past few years, as evidenced by the growing number of provocative headlines. For example, “The End of Programming” argued that “the end of classical computer science is coming, and most of us are dinosaurs waiting for the meteor to hit.” Other articles have predicted that “ChatGPT Will Replace Programmers Within 10 Years,” while NVIDIA CEO Jensen Huang has suggested that coding may no longer be a viable long-term career because of increasingly capable AI systems.

In addition, several widely discussed studies have identified programming as one of the occupations most exposed to AI and have documented declining employment among younger workers in software-related jobs. Unsurprisingly, parents of computer science students increasingly worry about their children’s career prospects.

But these concerns raise a more fundamental question: What exactly is being threatened? Is AI making software engineering obsolete, or is it primarily changing the nature of programming?

“Social media provide a steady diet of dire warnings that artificial intelligence (AI) will make software engineering (SE) irrelevant or obsolete,” wrote Carnegie Mellon computer scientists Mary Shaw and Eunsuk Kang in their 2024 article “Chill, Y’all: AI Will Not Devour SE.” “To the contrary, the engineering discipline of software is rich and robust; it encompasses the full scope of software design, development, deployment, and practical use; and it has regularly assimilated radical new offerings from AI.”

I have long known professor Shaw since we both served in the President’s Information Technology Advisory Committee (PITAC) in the late 1990s. She’s been writing about software as an engineering discipline, going back to her 1990 article on “Prospects for an Engineering Disciplines of Software.” Over the years, I have closely followed her continuing research on the topic.

“Software engineering (SE) is a rich, robust discipline that covers software systems from idea through their lifetime,” Shaw and Kang explained in their article. SE is “the branch of computer science that creates practical, cost-effective solutions to computing and information processing problems, by applying the best-systematized knowledge available, developing software systems in the service of mankind.” It “encompasses the full scope of software systems from concept to retirement — a full spectrum of issues from understanding what problem the software should solve through overall design, tradeoff resolution, performance, reliability, sustainability, usability, fitness for purpose, programming of components, composition of components, validation, adherence to policy and standards, and evolution.”

Their observation highlights an important distinction that is often overlooked. Software engineering is not synonymous with programming. Programming is an important activity within software engineering, but software engineering encompasses a much broader set of responsibilities, including requirements analysis, architecture, design, trade-off evaluation, testing, reliability, maintainability, security, deployment, governance, and evolution over the lifetime of a system.

To this day, software engineering remains poorly understood outside the profession. The term is often used interchangeably with programming or software development, even though its scope is much broader. This misunderstanding has become increasingly important as AI systems become more capable of generating code while remaining far less capable of understanding the broader context in which software systems are designed, deployed, and maintained.

Software engineering is fundamentally concerned with designing and managing complex systems throughout their entire lifecycle. Programming is one component of that process, but it is only one component. This distinction becomes even more important in the age of generative AI.

Earlier this year, professor Shaw along with her CMU colleagues Michael Hilton and George Fairbanks  published “AI Tools Make Design Skills More Important than Ever” in the March-April  2026 issue of IEEE Software.

Their article argued that the responsibilities of software developers are increasingly shifting from writing code toward specifying, evaluating, integrating, and governing software systems. AI tools may generate code, but humans must still determine what should be built, whether the generated code is correct, whether it satisfies the underlying requirements, and whether it fits within the larger architecture of the system.

“In other words, the responsibilities of software developers are rapidly becoming more about designing and less about programming. Reading, understanding, evaluating, and repairing someone else’s code is now more important than writing code from scratch. Judging whether you requested the right thing looms larger when the code is not written by you. Attempting to develop complex software without these skills can put a programmer in the position of the Sorcerer’s Apprentice – able to invoke the technology but lacking the skills to control it.”

This is where software engineering and programming begin to diverge most clearly.

To better understand why, Shaw recommended that I read another recent IEEE Software article, “An Abstraction Is Worth a Thousand Vibes,” by software engineering researcher Marcus Borg. Borg offers a particularly useful explanation of why abstraction remains one of the most important intellectual tools in software engineering and why AI does not eliminate the need for it.

His argument is especially relevant given the growing popularity of vibe coding. AI-assisted development tools have made it easier than ever for individuals to rapidly prototype applications, explore ideas, and generate working code. Borg himself is quite supportive of vibe coding as a good prototyping tool for quick-and-dirty experimentation and innovation.

However, building production-quality software systems is fundamentally different from rapidly created prototypes.

Complex software systems, explains Borg, can’t be created by jumping directly from requirements to source code. They are built through multiple layers of abstraction that progressively transform ideas into working systems:

• Requirements are refined into architectures.
• Architectures are decomposed into components.
• Components are implemented in code.
• Code is validated through testing.

Each layer provides critical feedback and helps engineers manage complexity. AI can accelerate parts of this journey, but it does not eliminate it.

As Borg notes, decades of software engineering experience have taught us that abstractions are essential for understanding, designing, and maintaining complex systems. They compress information, expose relationships, and provide the context needed to reason about large software systems. Skipping these abstractions is not a shortcut; it is often a recipe for failure.

“AI should not skip abstractions,” he writes. “Instead, our existing tooling should expose these structures so that AI-powered solutions can consume and modify them. To do that properly, our AI tools need access to the same information human engineers rely on — more context to understand the bigger picture.”

That statement points to what may become the next stage in the evolution of AI-assisted software development. Rather than replacing software engineering, AI systems will increasingly need to incorporate the abstractions, architectures, requirements models, design artifacts, and engineering knowledge that human software engineers have developed over decades.

The ability to create meaningful abstractions that capture the complexity of large production systems remains fundamentally human. Software engineering is ultimately about managing complexity, balancing competing requirements, making design trade-offs, and guiding systems through their entire lifecycle.

AI may dramatically change how code is written. But code has never been the whole story.

As programming becomes increasingly automated, software engineering — the discipline of understanding problems, designing solutions, and managing complexity through abstraction — is likely to become even more important. The future of software development may involve less programming, but it will almost certainly require more software engineering.