A couple of weeks ago I posted “Why AI Can’t Replace Software Engineering,” a blog in which I discussed an important distinction that is often overlooked: software engineering is not synonymous with programming.
I keep coming back to this topic because, in my opinion, the difference between programming and software engineering offers a particularly concrete way of understanding the difference between human and AI capabilities. It is also highly relevant to current debates about jobs and automation, since several widely discussed studies have identified programming as one of the occupations most exposed to AI.
Given the extraordinary advances in AI coding tools, why haven’t software engineering jobs already begun to disappear?
I recently read an excellent essay, “Why AI hasn’t replaced software engineers and won’t,” by Princeton computer science professor Arvind Narayanan and PhD candidate Sayash Kapoor that sheds considerable light on this question.
“There is great anxiety and uncertainty about AI replacing jobs,” wrote the authors. “How can we move past vague warnings and bombastic predictions and bring data to bear on this question? One good way is to look at the profession where AI capabilities are furthest along and adoption has been exceptionally rapid: software engineering.”
They argue that there is already enough evidence to reject the narrative that once AI reaches some capability threshold, mass layoffs will inevitably follow. If software engineering — a profession with relatively few regulatory barriers and where AI adoption has been extraordinarily rapid — has not experienced widespread labor displacement, then many other professions are likely to be even more insulated.
The Decide-Execute-Deliver Sandwich
Narayanan and Kapoor explain why coding agents have not led to lab or displacement through a simple but powerful metaphor: the decide-execute-deliver sandwich.
The sandwich consists of three layers.
This visual metaphor helps explain why AI-based coding agents have not led to mass layoffs in software development and, more generally, in many kinds of knowledge work. “AI compresses the execute layer,” they write, “but the other two layers resist automation in a way that will not be overcome by capability improvements alone.”
This observation immediately raises an important question. If AI can generate code so effectively, why has it not had a larger impact on software engineering jobs?
Writing Code Was Never the Bottleneck
“Writing code isn’t, and never was, the bottleneck,” say Narayanan and Kapoor.
They cite a 2019 IEEE study, “Today Was a Good Day: The Daily Life of Software Developers,” based on an analysis of approximately 6,000 professional software developers at Microsoft.
The study found that developers spend surprisingly little of their day actually writing code.
On a typical day, developers spent only about 15% of their time writing or reading code, 14% debugging, 8% running unit tests, and 2% documenting their work. The rest of their time was spent in meetings (15%), email (10%), helping and mentoring colleagues (5%), learning (3%), and administrative activities (2%).
Software development is fundamentally a collaborative activity that requires coordinating people, understanding requirements, integrating systems, and making trade-offs.
If coding itself is not the bottleneck, then what is?
The Real Bottlenecks
Narayanan and Kapoor argue that the true bottlenecks are three activities that continue to resist automation:
“In other words,” they write, “software engineers’ work consists of a decide-execute-deliver sandwich (with understanding being a prerequisite for all three).” AI has significantly compressed the middle of the sandwich, but the two ends remain largely unchanged.
As long as software teams are responsible for making decisions and accountable for what they deliver, engineers still need to spend considerable time developing a deep understanding of the systems they build and maintain.
Evidence from the Real-World Software Development
Narayanan and Kapoor cite a recent NBER working paper, “Writing Code vs. Shipping Code,” as empirical support for the sandwich model.
The paper asks two important questions. Do increasingly capable AI coding tools produce corresponding increases in productivity? And if they do, do those task-level productivity gains ultimately translate into more software being successfully delivered to users?
The researchers analyzed software development data on more than 100 GitHub developers and found that successive generations of AI coding tools produced enormous increases in coding activity. Synchronous coding agents increased lines of code by 741% and pull requests by 65%.
But software releases increased by only 20%. The productivity gains attenuated sharply as one moved up the production hierarchy.
The study reached an important conclusion: “The binding constraint appears to be shifting from writing code to reviewing, integrating, and ultimately distributing it.”
This finding aligns remarkably well with the decide-execute-deliver sandwich. AI has dramatically improved execution. But it has had a much smaller impact on decision making, integration, verification, and accountability.
Can the Sandwich Be Further Compressed?
Narayanan and Kapoor don’t believe so.
At one end of the pipeline, development teams still need to decide what to build. Requirements specification takes far longer than most junior engineers initially expect and resists automation because it requires understanding user needs, market signals, organizational priorities, and, increasingly, regulatory requirements. This is true in all major engineering disciplines, whether building a bridge in civil engineering, an airplane in mechanical engineering, or a power plant in electrical engineering.
Compressing this process usually creates significantly more problems downstream.
At the other end of the pipeline, human teams remain accountable for what they deliver. Today’s AI systems remain too unreliable for organizations to ship mission-critical software without fully understanding and testing what they deploy. In most organizations, such behavior would represent an existential risk to both the software team and its customers.
These two layers of the sandwich resist automation not because current AI models are insufficiently capable, but because they fundamentally require human judgment, organizational understanding, and accountability.
What Does the Future Hold?
“AI boosters might claim that mass layoffs are coming; they just haven’t happened yet because human-level software engineering abilities are very recent,” write Narayanan and Kapoor. But if the sandwich model is correct, these predictions are unlikely to come true.
The middle of the sandwich has already been substantially compressed, a process that began decades ago with increasingly powerful programming tools, integrated development environments, code libraries, frameworks, and automation technologies. Even if future AI systems make the execution layer nearly instantaneous and nearly perfect, it would represent a relatively modest change compared with the broader responsibilities of software engineering.
In fact, the authors suggest that demand for software engineers could actually increase. As software becomes cheaper and easier to create, people will want far more of it.
Virtually all cognitive work benefits from software. As AI lowers the cost of creating applications, people are already developing countless one-off utilities, workflows, and specialized applications that previously would never have been economically viable.
The amount of time people spend getting computers to perform new tasks is likely to continue increasing. These activities may involve building software, orchestrating AI agents, managing complex workflows, or creating entirely new kinds of digital systems. They will require a combination of software skills, AI skills, and domain expertise.
AI will undoubtedly create major structural changes in how software is produced. Some software engineers will benefit more than others, depending on their skills, seniority, geography, and ability to adapt. But the evidence increasingly suggests that software engineering is not disappearing. Rather, its center of gravity is shifting away from writing code and toward the activities that have always been hardest to automate: understanding problems, making decisions, integrating complex systems, exercising judgment, and being accountable for what gets delivered.
In that sense, software engineering provides an excellent lens through which to understand the broader impact of AI on work:
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。