AI正让软件工程从写代码扩展到管理可执行与半可执行混合系统。
The Semi-Executable Stack: Agentic Software Engineering and the Expanding Scope of SE

- 提出六层半可执行栈模型,涵盖从代码到组织机制的全链条
- 指出当前挑战是工程对象扩大而非职业消失,需重新定位角色
- 适合关注AI时代软件工程转型的研究者与实践者
基于AI的系统,特别是由大语言模型和工具调用智能体驱动的系统,正被广泛讨论为对软件工程的潜在威胁。随着基础模型能力增强,智能体能进行多步规划与行动,诸如代码搭架、常规测试生成、简单修复及小型集成工作等任务,较几年前显得更加脆弱。这种趋势引发了学生、初级开发者乃至资深从业者普遍的焦虑,担心积累的专业知识将失去价值。本文主张另一种解读:软件工程的重要性并未减弱,而是其工程对象已从纯可执行代码扩展至半可执行产物——即自然语言、工具、工作流、控制机制与组织惯例的组合,其执行依赖于人类或概率性解释,而非确定性运行。为此,本文引入‘半可执行栈’作为六层诊断参考模型,覆盖可执行物、指导性物、编排执行、控制机制、运行逻辑及社会制度适配。该模型帮助定位贡献点、瓶颈或组织转型的核心层级及其依赖关系。论文通过三个案例展开论证,将常见质疑重构为可解决的工程目标,并提出‘保留优于净化’的决策准则,用于判断哪些传统流程应保留、简化或重构。本文为概念性主旨文章,重在诊断与设定议程,非实证研究。
原文摘要 · Abstract (English)
AI-based systems, currently driven largely by LLMs and tool-using agentic harnesses, are increasingly discussed as a possible threat to software engineering. Foundation models get stronger, agents can plan and act across multiple steps, and tasks such as scaffolding, routine test generation, straightforward bug fixing, and small integration work look more exposed than they did only a few years ago. The result is visible unease not only among students and junior developers, but also among experienced practitioners who worry that hard-won expertise may lose value. This paper argues for a different reading. The important shift is not that software engineering loses relevance. It is that the thing being engineered expands beyond executable code to semi-executable artifacts; combinations of natural language, tools, workflows, control mechanisms, and organizational routines whose enactment depends on human or probabilistic interpretation rather than deterministic execution. The Semi-Executable Stack is introduced as a six-ring diagnostic reference model for reasoning about that expansion, spanning executable artifacts, instructional artifacts, orchestrated execution, controls, operating logic, and societal and institutional fit. The model helps locate where a contribution, bottleneck, or organizational transition primarily sits, and which adjacent rings it depends on. The paper develops the argument through three worked cases, reframes familiar objections as engineering targets rather than reasons to dismiss the transition, and closes with a preserve-versus-purify heuristic for deciding which legacy software engineering processes, controls, and coordination routines should be kept and which should be simplified or redesigned. This paper is a conceptual keynote companion: diagnostic and agenda-setting rather than empirical.
Thank you to arXiv for use of its open access interoperability. PaperDance 不是 arXiv 官方产品;中文卡片由大模型生成,请以原文为准。