Paper deep dive
Why Software Engineering Is Indispensable in the Age of Coding Agents
Alfonso Fuggetta
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 93%
Last extracted: 10/14/2026, 9:17:26 AM
Summary
This paper argues that Software Engineering (SE) and software engineers are indispensable in the age of AI coding agents. It posits that Large Language Models (LLMs) have structural limitations—probabilistic generation, agnosticism, and semantic statelessness—that create a 'structural vacuum' regarding correctness, domain context, and evolutionary trajectory. Filling this vacuum requires four knowledge levers (methodological, domain, design, and process knowledge) reified as persistent artifacts. The software engineer acts as the methodologist, mediator, and custodian, ensuring that AI-assisted development produces trustworthy, verifiable software rather than misleadingly plausible code.
Entities (15)
Relation Signals (12)
Alfonso Fuggetta → authored → Why Software Engineering Is Indispensable in the Age of Coding Agents
confidence 99% · Why Software Engineering Is Indispensable in the Age of Coding Agents ALFONSO FUGGETTA
Software Engineer → fillsvacuumof → AI coding agents
confidence 96% · Filling it requires four knowledge levers... each requires the software engineer as methodologist, mediator, and custodian
AI coding agents → hasstructurallimitation → Semantic Statelessness
confidence 95% · Three structural properties of large language models (probabilistic generation, agnosticism, and semantic statelessness) create a structural vacuum
AI coding agents → hasstructurallimitation → Probabilistic Generation
confidence 95% · Three structural properties of large language models (probabilistic generation, agnosticism, and semantic statelessness) create a structural vacuum
AI coding agents → hasstructurallimitation → Agnosticism
confidence 95% · Three structural properties of large language models (probabilistic generation, agnosticism, and semantic statelessness) create a structural vacuum
Software Engineer → provides → Process Choices
confidence 93% · Process choices... are produced and owned by the software engineer
Software Engineer → provides → Methodological Knowledge
confidence 93% · Methodological knowledge — how to build quality software — is codified by SE as a discipline
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Can AI make Software Engineering (SE) -- the discipline -- obsolete? And can it make software engineers -- the professionals -- redundant? This paper argues that the rise of capable AI coding agents makes SE and software engineers essential, not obsolete: the missing foundation without which AI-assisted development produces misleadingly plausible, unverifiable, and ultimately untrustworthy software. Three structural properties of large language models (probabilistic generation, agnosticism, and semantic statelessness) create a structural vacuum that no amount of training can eliminate. Filling it requires four knowledge levers: methodological knowledge, domain knowledge, design choices, and process choices. All four must be reified as persistent artifacts, and each requires the software engineer as methodologist, mediator, and custodian.
Tags
Links
- Source: https://arxiv.org/abs/2610.10226v2
- Canonical: https://arxiv.org/abs/2610.10226v2
Trouble viewing inline? Open PDF directly →
Full Text
21,333 characters extracted from source content.
Expand or collapse full text
Why Software Engineering Is Indispensable in the Age of Coding Agents ALFONSO FUGGETTA, Politecnico di Milano, Italy Can AI make Software Engineering (SE) — the discipline — obsolete? And can it make software engineers — the professionals — redundant? This paper argues that the rise of capable AI coding agents makes SE and software engineers essential, not obsolete: the missing foundation without which AI-assisted develop- ment produces misleadingly plausible, unverifiable, and ultimately untrustworthy software. Three structural properties of large language models (probabilistic generation, agnosticism, and semantic statelessness) cre- ate a structural vacuum that no amount of training can eliminate. Filling it requires four knowledge levers: methodological knowledge, domain knowledge, design choices, and process choices. All four must be reified as persistent artifacts, and each requires the software engineer as methodologist, mediator, and custodian. CCS Concepts:• Software and its engineering→ Software creation and management;• Computing methodologies→ Artificial intelligence. Additional Key Words and Phrases: software engineering, AI coding agents, large language models, software process governance, specification, vibe coding 1 What We See The advent of coding agents has raised legitimate questions about the fate of Software Engineering and software engineers; in these pages, Welsh went as far as announcing The End of Programming. To answer them, one may assess empirical data or practitioners’ judgment. The first evidence to enable careful judgment is now emerging: field observation and professional practice, randomized trials, cross-country firm surveys. Meyer [9], writing in these pages, frames the current moment. He distinguishes three software categories (acute, business, casual) and argues that vibe coding — Karpathy’s term for code written by those who “fully give in to the vibes” rather than engineering it — works for the third but not for the first two, where correctness is paramount and coding is only 10–20% of project cost. He names the hallucination loop: a plausible suggestion that sends the developer down a path that will not close. His conclusion: for professional software, AI-assisted development must be paired with formal specification and verification, the move from probable to provable. The empirical picture is not uniform. Cui et al. [4] found in field experiments a 26% increase in completed tasks across 4,867 developers at Microsoft, Accenture, and a Fortune 100 firm, with the largest gains among less experienced developers; a Science study of 160,097 GitHub developers finds the opposite, with gains concentrated among senior developers and no significant effect for early-career ones [5]. Becker et al. [3] ran a randomized controlled trial with sixteen experienced open-source developers on 246 real tasks in their own mature repositories: tasks on which AI was allowed took 19% longer, and afterward developers believed AI had helped; a 2026 follow-up by the same team considers speedups now likely, but deems its new measurements unreliable. Xu et al. [10] show where the cost lands: in a difference-in-differences study of 2,755 open-source repositories, lines of code added rose 17.7% after Copilot introduction, but core contributors — Author’s version. Accepted for publication in Communications of the ACM (manuscript CACM-26-07-6124). This is the author’s final version of the work, submitted to the publisher on 11 October 2026. The definitive Version of Record will be published in Communications of the ACM, https://doi.org/10.1145/3858606; please cite the published version.© 2026 Copy- right held by the author. Licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License (C BY-NC-ND 4.0). Author’s Contact Information: Alfonso Fuggetta, Politecnico di Milano, Dipartimento di Elettronica, Informazione e Bioingegneria, Milan, Italy, alfonso.fuggetta@polimi.it. arXiv:2610.10226v2 [cs.SE] 11 Oct 2026 2Alfonso Fuggetta those with the deepest ownership of the codebase — saw a 19% decline in original code output while reviewing 6.5% more code and absorbing the added rework. Two difference-in-differences studies presented at MSR 2026, one on an AI IDE and one on coding agents, find the same pattern: quality costs that persist even when velocity gains fade, with static-analysis warnings up 30% and about 18%, and code complexity up 41% and about 39% [1, 7]. Time saved on generation is recaptured on supervision, spent on output that looks plausible but requires an external reference for correctness. That reference lives with the developer, not with the tool. Huang et al. [8] studied thirteen developers in the field and surveyed ninety-nine more. A dis- tinctive divide has emerged: some developers practice vibe coding, treating interaction flow as evidence of correctness. Professionals do not: they plan, validate output, and retain architectural control, treating the agent as an executor. Where AI-assisted development succeeds, something structured is compensating for what the agent alone cannot do. At scale, the Stack Overflow 2026 Developer Survey — 30,903 respondents across 169 countries — captures the same ambivalence: 83% use AI tools at work, yet only 6.6% trust their output for important work decisions, while 48% trust it when they can easily verify it. AI coding agents have a structural vacuum: on their own, they lack what they need to succeed. The vacuum follows from what AI tools structurally are; the nature of software makes it conse- quential, and the state of SE decides whether it is filled. Software is intangible and, as Balzer [2] ob- served, “rarely consistent”: requirements evolve, knowledge arrives incrementally, practices carry inconsistencies that are features, not errors. Classical engineering converges on a finished artifact; software never settles, its substrate constantly renegotiated. SE is still young — the NATO Confer- ence dating from 1968 — and applied unevenly. In sixty years that discipline has moved toward the classical engineering disciplines: formal methods, safety standards (DO-178C, IEC 62304, ISO 26262), Empirical Software Engineering, Model-Based Systems Engineering, product line engineer- ing. Yet without it, mature or not, AI tools cannot resolve the problems the evidence lays bare. The two reinforce each other: SE supplies what AI lacks, and AI accelerates SE’s systematic application and improvement. 2 Why: The Structural Vacuum The evidence and the practitioner voice reviewed in Section 1 reveal the vacuum; they do not explain it. To do so, we adopt a logical and epistemological approach: examining what AI coding agents structurally are and, from that structure, deriving the roles human knowledge and judgment must necessarily play. The vacuum is not a performance gap: it is a structural condition. Three properties of a large language model define how it operates and, together, constrain what it can and cannot do without external support. Probabilistic generation. An LLM does not compute: it generates. Its output is a navigation over a probability distribution conditioned on training and context. And no digital artifact, gener- ated or otherwise, can be validated against the world it represents without a reference external to the model. Agnosticism. An LLM has absorbed patterns from vast corpora of code and text; three domains resist that absorption. Each has a reducible surface layer and a structurally irreducible core. Methodological agnosticism. The reducible surface is SE principles — specification methods, ar- chitectural styles, testing frameworks — which specialized models can absorb. The irreducible core is evaluative judgment: determining whether this specification for this system meets the bar re- quires a domain-grounded reference the model cannot generate. Asking the model to judge that adequacy itself does not help: it lacks that reference, which is difficult, if not impossible, to reify precisely each time. Why Software Engineering Is Indispensable in the Age of Coding Agents3 Domain agnosticism. The reducible surface is general domain knowledge (e.g., clinical constraints, regulatory requirements) accessible through RAG, fine-tuning, or domain training. The irreducible core is organization-specific knowledge: continuously renegotiated, semantically defined by the practice it describes, and permanently inconsistent in Balzer’s sense. It can only be managed, never eliminated, and requires ongoing human mediation. Evolutionary agnosticism. The reducible surface is general evolution patterns — what design choices constrain future change, what qualities matter in a given domain — in principle trainable. The irreducible core is the project-specific trajectory: what this system must become, given this organization’s constraints, does not exist until the software engineer reasons it into existence. This is a structural absence, not a deficiency of attention. Semantic statelessness. Within a session, the model retains a working footprint: the context window gives it access to what was said, decided, and produced. Modern systems now add persis- tent memory across sessions, but as storage or log of prior exchanges — not as a semantic model of accumulated know-how. The architectural decision made last Tuesday, the domain constraint introduced by the expert last week, the specification agreed upon last month: none becomes usable knowledge unless it has been reified as an artifact. 3 Four Knowledge Levers, Three Actors The vacuum has a precise structure. Filling it requires four distinct levers. Methodological knowledge — how to build quality software — is codified by SE as a discipline: fifty years of accumulated practice on specifications, architecture, testing, and process governance. Domain knowledge — what the system must mean and do in its world — is carried by domain experts: clinicians, operators, traders, and subject-matter specialists who understand the problem the software is built to solve. Design choices — the project-specific decisions that translate into the product: architectural struc- tures, component boundaries, trade-offs, interfaces. These are produced and owned by the software engineer, informed by both methodological and domain knowledge, and accumulate as the system grows. Process choices — how the work is organized for this specific project: the lifecycle adopted, the criteria for agent autonomy, the review structure. All four levers require reification: they must be materialized as persistent, accessible artifacts. Knowledge that exists only in someone’s head does not exist for a stateless agent. Reification narrows the vacuum without closing it: the irreducible cores of Section 2 can be captured only in part, and what escapes the artifacts stays with the people accountable for the system. Three actors do this work. Domain experts supply semantic knowledge — without them, SE structure is form without meaning. The AI agent is the executor, powerful but without intrinsic reference for correctness or future orientation. The software engineer is the active mediator be- tween the two, and the custodian who keeps the system’s evolutionary trajectory explicit over time. One might object that these limits are temporary and that enough training data would let the agent learn without human intervention. But the three irreducible cores named in Section 2 are not gaps in training: evaluative judgment, organizational knowledge, and a system’s future trajectory cannot be distilled from any corpus. The vacuum is structural, not historical. 4 SE and AI The four levers and three actors just described operate through two distinct mechanisms by which SE fills the vacuum. The first is constitutive: SE methodology embedded directly in the agent’s de- sign, so that it asks for specifications when they are missing, signals underspecified requirements, 4Alfonso Fuggetta and structures its outputs according to SE principles before any human provides project-specific input. The second is operational: the software engineer provides SE-structured artifacts — speci- fications, architectural contexts, testing frameworks, domain constraints — that give the agent a reference for correctness on each project. The two mechanisms map onto the two layers: consti- tutive addresses the reducible, operational addresses the irreducible core. AI, in turn, helps SE close a knowing-doing gap it has long been unable to close on its own: for- mal requirements, architectural documentation, and systematic testing are demonstrably effective yet consistently underused. CASE tools in the 1980s and 1990s tried to close this gap, resented for their overhead. AI shifts the cost dynamic: reification, verification, and accountability (concepts SE has developed for decades) become cheaper to apply. Specifications, once expensive to produce and maintain outside critical domains, become byproducts of elicitation sessions and can be pro- gressively formalized to reconnect with established SE practices. Tests, once written after the code to verify it, become the reference the agent generates against. Architecture Decision Records, once documentation debt, become the substrate the agent operates on. Practices once confined to criti- cal domains can become ordinary, as the mechanical cost of applying the method drops below the threshold of abandonment. The software engineer’s role now operates on three axes: methodological (providing the agent with sound SE structure); mediating (eliciting organization-specific domain knowledge and struc- turing it as verifiable artifacts); and custodial (owning the design and process choices that accu- mulate over the project’s lifetime). Custody is, above all, accountability: agents can propose and execute decisions, but responsibility for them cannot be delegated. To govern an AI agent well, the engineer must know more SE, not less. The pattern is visible at organizational scale: the DORA 2025 State of AI-assisted Software Development report, based on nearly five thousand profession- als worldwide, finds that AI adoption amplifies practices already present. Teams with mature engi- neering foundations convert AI into delivery throughput; teams without them find AI accelerating instability rather than productivity. 5 In Practice: Artifacts and Workflows Sections 3 and 4 established that the four knowledge levers must be reified as artifacts, and that AI has made their reification sustainable beyond the critical domains that could once justify its cost. The artifacts named below are largely independent of the software lifecycle adopted; the list is not exhaustive. Specifications (the primary operational artifact of spec-driven development) supply the model with the criterion of adequacy it cannot generate for itself. Architecture Decision Records encode the design choices that accumulate over the system’s life, along with the why and the intended trajec- tory that no session context preserves. Domain constraint records reify the organization-specific knowledge elicited from experts: the artifact form of what is otherwise permanently inconsis- tent and never articulated. Test frameworks structured for agent input externalize the reference of correctness the agent has no internal access to, becoming the agent’s proving ground and the engineer’s acceptance criterion. Process definitions instantiated per project make process choices executable rather than aspirational: the criteria for agent autonomy, the boundaries of automated action, the review structure. Design rationale records, finally, hold the custodial layer of coherence across accumulated decisions, distinguishing incidental patches from principled changes. A natural question is whether AI changes development workflows. AI does not prescribe one. Any lifecycle a team adopts (waterfall, agile, spec-driven, or incremental refinement of existing practices) can be supported by an AI engine, provided the artifacts are present and continuously maintained. The “loop and graph engineering” now celebrated in agentic development revisits iterative, incremental, or more structured development — long practiced in SE — now driven by an Why Software Engineering Is Indispensable in the Age of Coding Agents5 AI executor: AI empowering an established method. The ambition to drive the software process through such an engine is not new. Through the 1990s and 2000s, research on Process Modeling Languages and Process-centered Software Engineering Environments attempted to govern the software process through deterministic formal models. A 2014 retrospective concluded that formal process automation could succeed only in narrow technical phases such as code generation, testing, and deployment [6]. Deterministic execution cannot govern an activity whose normal state is inconsistency: it either blocks or forces premature resolution that erases information. AI resolves the problem differently: a probabilistic engine does not require constraint satisfaction, navigates incomplete specs, and surfaces inconsistencies as outputs for human judgment. The intent behind PSEE research is not abandoned. Where deterministic execution could not, probabilistic delivery opens a new direction. 6 Conclusions SE is not a discipline in decline. It is a discipline whose moment has arrived — the one that defines the structured space in which AI agents can be trusted. And the software engineer is not a profes- sional in decline either — but the one who carries that knowledge into practice: who defines what the agent navigates by, who elicits the domain meaning that no corpus can supply, and who owns the trajectory of the system over time. Three implications follow. Reframe the question. The dominant debate asks whether AI will replace software engineers. The right question is different: what structured knowledge must govern AI agents to produce software that is correct, trustworthy, and built to last? Answering it requires SE and software engineers, not their abandonment. Redirect the investment. Specifications, domain elicitation, architectural governance, and pro- cess discipline are not overhead to minimize — they are the structured space within which AI agents can be trusted to operate with persistent and coherent memory. Organizations that treat them as optional will pay the cost in correctness, maintainability, and accountability. Revalue the discipline. SE education, research, and practice are not legacies to be displaced by AI fluency. They are prerequisites for AI exploitation and governance. A generation of devel- opers trained only in prompting — without methodological knowledge, domain elicitation skill, or architectural judgment — will reproduce at scale the failure modes this paper describes. And without early-career hiring, as Russinovich and Hanselman warn in these pages, the profession’s talent pipeline will collapse. Acknowledgments The author thanks Damian Tamburri for his feedback on different revisions of this paper. Claude (Anthropic) was used as an AI writing assistant during drafting and revision. All arguments, claims, and editorial decisions are the author’s own. References [1] S. Agarwal, H. He, and B. Vasilescu. AI IDEs or Autonomous Agents? Measuring the Impact of Coding Agents on Software Development. In Proc. 23rd Int. Conf. on Mining Software Repositories (MSR ’26), Rio de Janeiro, Brazil, 2026, p. 857–862. doi:10.1145/3793302.3793589. [2] R. Balzer. Tolerating Inconsistency. In Proc. 13th Int. Conf. on Software Engineering (ICSE 1991), Austin, TX, 1991, p. 158–165. [3] J. Becker, N. Rush, E. Barnes, and D. Rein. Measuring the Impact of Early–2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089, July 2025. [4] K. Z. Cui, M. Demirer, S. Jaffe, L. Musolff, S. Peng, and T. Salz. The Effects of Generative AI on High- Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science, 2026. 6Alfonso Fuggetta doi:10.1287/mnsc.2025.00535. [5] S. Daniotti, J. Wachs, X. Feng, and F. Neffke. Who Is Using AI to Code? Global Diffusion and Impact of Generative AI. Science, 391(6787):831–835, 2026. doi:10.1126/science.adz9311. [6] A. Fuggetta and E. Di Nitto. Software Process. In Proc. Future of Software Engineering (FOSE’14), Hyderabad, India, 2014, p. 1–14. [7] H. He, C. Miller, S. Agarwal, C. Kästner, and B. Vasilescu. Speed at the Cost of Quality: How Cursor AI Increases Short-Term Velocity and Long-Term Complexity in Open-Source Projects. In Proc. 23rd Int. Conf. on Mining Software Repositories (MSR ’26), Rio de Janeiro, Brazil, 2026, p. 181–193. doi:10.1145/3793302.3793349. [8] R. Huang, A. Reyna, S. Lerner, H. Xia, and B. Hempel. Professional Software Developers Don’t Vibe, They Control: AI Agent Use for Coding in 2025. arXiv:2512.14012v2, Aug. 2026. [9] B. Meyer. Artificial Intelligence for Software Engineering: From Probable to Provable. Communications of the ACM, 69(6):46–49, June 2026. doi:10.1145/3773295. [10] F. Xu, P. K. Medappa, M. M. Tunc, M. Vroegindeweij, and J. C. Fransoo. AI-Assisted Programming Decreases the Pro- ductivity of Experienced Developers by Increasing the Technical Debt and Maintenance Burden. arXiv:2510.10165v3, Jan. 2026.