代码不再稀缺之后，软件工程还剩下什么？

过去几十年，软件工程师最核心的工作之一，就是把需求变成代码。但过去两年，AI Coding 正在快速改变这件事情。从最早的代码补全，到现在可以理解整个代码库、完成复杂任务、调用工具、修改代码、运行测试，甚至参与 Code Review。AI 正在把“生产代码”这件事情变得越来越便宜。但有意思的是，我们并没有因此觉得软件工程变简单了，甚至恰恰相反。 近日，InfoQ《极客有约》X QCon直播栏目特别邀请前阿里高级技术专家吴子奇担任主持人，和小红书客户端基础技术负责人杨凯、阿里巴巴高级研发工程师李峥峰、哔哩哔哩技术专家张忻正一起，在 QCon 全球软件开发大会 " 2026（上海站）即将召开之际，共同探讨AI 时代研发效能该怎么重新衡量。 部分精彩观点如下： 大公司因为协作复杂度需要指标来洞察研发效能，但日常过程中，尤其是现在有了 AI、一个人就能干成一家公司，就不要纠结于这些率。研发和测试分开的范式，后面一定会被测试驱动的开发替代，测试 80% 甚至 90% 的工作量都会揉进出码过程。如果没有确定性工程去约束 AI 怎么写代码，它自然就会学坏，而且放大得更快，确定性工程就是让 AI 学对的东西。架构足够好才能承载更高的并发协同，不容易冲突，也能降低每个参与者的变更频率，避免在一个 PR 里反复 rebase。 在 10月 22-24 日将于上海举办的 QCon 全球软件开发大会 " 2026（上海站）上，我们特别设置了【 AI 驱动的软件工程 "】专题。该专题将聚焦AI Coding、研发 Agent、工程智能化、复杂项目落地实践与研发效能建设等方向上的探索与思考，共同探讨 AI 驱动下研发体系的演进路径与未来趋势。查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2026/shanghai/schedule完整直播回放可查看：https://www.infoq.cn/video/P6mBiPWbwZIIpWpUVcOa?utm_source=home_video&utm_medium=video 以下内容基于直播速记整理，经InfoQ删减。 AI Coding 到底改变了什么 吴子奇：当 AI 已经能写代码之后，你认为真正难的是什么？ 杨凯：AI 已经能写出非常漂亮的代码。但软件工程对程序员的要求是两层：下层是编码实现，现在 AI 在做；上层是对问题的拆解、对代码风格的审美，以及最终下判断。AI 取代了下层，但对上层的要求反而更高，而且因为 AI 出码更快，系统复杂度增长也更快，进一步提高了要求。 吴子奇：作为管理者或者面试官，你会怎么审视人才？ 杨凯：昨天我正好在校招面试。首先是计算机基础能力，网络、操作系统原理；在这之上是知识迁移能力，以及对复杂系统的掌控能力。AI 来了之后，一个人能 handle 的代码量变多了，以前一天写 1000 行已经不错，现在一天写 1 万行都很容易。但这 1 万行你能否掌控住、出了问题能否判断修复？要求更高了。 吴子奇：你们为什么会从“通才模型”进一步走向“专才 Agent”？是通用模型本身已经遇到了瓶颈，还是大型工程对专业上下文、工具和流程的要求越来越高？ 杨凯：我不觉得大模型本身遇到了瓶颈。但面对小红书、B 站、阿里这些复杂项目，巨大的代码量、庞杂的业务知识、漫长的演进历史知识都不在训练数据里，代价就是推理时间和 token 成本。我常打个比方：把大模型直接拿到大公司做 Coding，好比请了一位非常厉害的工程师，却不给他时间了解项目、上手代码，只给几个文档设计稿，就要他几小时内交出符合要求的代码，甚至不让测试。这对任何工程师、任何模型都不合理。所以现在流行的 Harness 工程，其实就是把 AI 当顶级工程师对待，喂足业务背景、项目知识和代码架构。 吴子奇：在你们实际的研发实践中，你觉得影响 AI Coding 最终效果的最大变量是什么？模型能力、上下文、代码库、工具链，还是工程规范？ 杨凯：模型能力肯定是第一位，但对做工程的人来说它不可控。我认为变量最大的是一头一尾。头是上下文工程、业务背景知识。最近跟复旦大学软件工程学院副院长彭鑫老师交流，他提了个“代码数字孪生”的概念，希望对代码建立数字孪生系统，把业务、架构、模块知识建成一套上下文系统，辅助 AI 熟悉项目。尾是测试。我做客户端出身，客户端的代码测试是大模型做得不好的地方：它没法天然的拿到手机做端到端测试，更多是白盒单测，这不是真正的质量保证，模型也就没被真正“完成任务”奖励到。我认为研发和测试分开的范式，后面一定会被测试驱动的开发替代，测试 80% 甚至 90% 的工作量都会揉进出码过程，跟抖音、快手的同学交流，大家也都意识到了。 吴子奇：结合我以前移动端的背景，代码量一膨胀，再强的大模型在现有上下文窗口下理解都困难。移动端更麻烦：真机环境跑在手机上，和 Agent 常跑的云端、本地是割裂的。服务端、前端都能让 Agent 感知最终结果、形成正反馈，但 iPhone 的封闭性让 AI 很难感知程序的真实运行状态，只能修编译报错或跑单测，我们最看重的 UI 测试、QA 回归在手机端还挺难。 张忻正：B 站一直是 monorepo，后端是 Go，移动端在用 Kotlin，模块代码规模非常大。我认为最大的变量不是模型能力。从语言角度，AI 对哪种语言的理解，Opus 4.8、GPT-5.6 这种级别其实都满足了。更大的点在后端的大规模架构：它绝对不是有向无环图，而是网状的依赖，最大的问题是怎么把线头捋出来。我们怎么基于一个环境，无论 mock 还是真实的 FAT、UAT，把它跑起来，才是让 AI 更快工作的点。所以最重要的变量不一定叫工具链，更多是 environment，比如现在有些项目 share 每个人自己的 environment：我本地装了很重的 Xcode 和复杂环境，作为协同方，你可以 share 我的 environment、接着我的 session 继续工作，就能打破一些工程交互的边界。AI Coding 本质是个 loop engineering，它要更快的 loop。移动端很难 debug、很难断言，那我就用日志，1 分钟跑起来、1 分钟出结果。 吴子奇：AI Coding 不是简单地“换一个更强的模型”，而是开始往工程系统里面走。李老师，你们在 Code Review 的实践里，是不是也有类似的感受？ 李峥峰：我们做 AI 非常早，我所在的是阿里内部的代码平台团队，类似阿里内部的 GitHub，离代码最近。22 年底我们就开始做内部 Copilot，同步做了 AI 评审，那时千问可能还在 1.5 版本，模型看 diff 幻觉非常厉害。后面我们也尝试训模型，每次换个更强的模型去看 diff，通过提前的程序分析给它相关上下文。但转折可能在 Claude 4 那个时代：模型一代代变强，强到一定程度之后效果就上不去了。这时看上下文、看 trace 就会发现，补上下文要么很有限，要么很冗余。不管多强的模型，只要生产规模足够大，就一定有概率出幻觉，放大之后各种问题，模型层基本解决不了，所以我们后来把这些转移到工程上。就拿 Code Review 来说，一个