2023 年，我写过一篇《我与 ChatGPT 结对编程的体验》。
那时候 GPT-4 已经可以写不少代码。我让 ChatGPT 当 Driver，自己更多扮演 Observer：描述需求，看它实现，然后 Review 代码、指出问题，再继续下一轮。
当时我对这件事的判断其实很明确。AI 可以写代码，但它经常会幻觉 API、误解上下文、遗漏边界条件，所以 Human Review 仍然是最后一道防线。只要人还需要理解实现、判断代码是否正确，软件工程师的核心价值就还在那里。
三年以后，我发现自己已经很少做这件事了。
不是 AI 写得足够好，所以我把它当成了一个更高级的 Copilot；而是整个开发过程逐渐变成了另一种东西。
现在我业余时间维护两个长期项目：Free4Chat 和策引（MyInvestPilot）。它们的绝大多数新代码已经不是我写的。更进一步，我通常也不亲自 Review 这些代码。
Agent 实现功能，另一个模型 Review。Review 发现问题，再交回实现 Agent 修；测试、构建、浏览器验证继续跑。如果 Review 认为可以合并，我通常就会合并。有时候我甚至不知道这次 PR 具体改了哪些函数。
这和我 2023 年对 AI 编程的理解已经不是同一件事了。
这篇文章不是一个“我如何用 AI 一个人做两个产品”的故事。我现在的主业仍然是一名普通的软件工程师，绝大多数工作环境也仍然是我们熟悉的团队软件开发。我只是恰好有两个持续开发了很久的业余项目，可以拿它们当两个长期样本，观察同一件事：
当越来越多的软件工程工作被交给 Agent 以后，一个软件项目到底还需要多少软件工程师？
两个并不简单的样本
先说一下这两个样本。因为如果它们只是两个 CRUD Demo，后面的很多结论其实没有什么意义。
Free4Chat 最早只是一个匿名 WebRTC 聊天室。早期自己用 Go 和 Pion 做过 SFU，后来换过 Elixir 和 Membrane，再后来迁移到 Cloudflare。现在它除了人与人聊天，还加入了 Agent Runtime、权限系统、语音、临时任务、Live View 和 Room Apps。它前后几次架构迁移的过程，我在《一个 WebRTC 聊天室的四次演进：从匿名语音到 Human + Agent 协作》里详细写过。
这个项目并不大，没有企业 SaaS 常见的复杂组织、计费和几十种业务实体，但它有一个特点：小而难。
其中有一段经历特别典型：让一个 Agent 真正在 Room 里“开口说话”。
这句话听起来像是给聊天产品接一个 TTS。真正做下去以后，链路却变成了：Human 的声音先经过 SFU 进入本地 Agent Runtime，由 Pion 接收媒体，做 STT，再交给 ACP Harness 思考；Harness 返回文本以后，又经过 TTS、音频处理、Pion publication、Cloudflare SFU，最后从另一个人的浏览器里播放出来。
早期 Agent Runtime 本身还是 Node/TypeScript，WebRTC 媒体则由单独的 Go/Pion 子进程负责，两边通过 JSONL 通信。随着媒体和 Agent 生命周期不断纠缠，最后干脆把整个 Runtime 重写成了一个自包含的 Go 程序，让 Pion 直接运行在进程里。
但换成 Go 当然也没有让问题消失。有一段时间整个项目快被做成 WebRTC 101 实验室了。
本地 TTS 音频是正常的，Pion 自己做完整的 encode/decode loopback 也是正常的，但经过 Cloudflare SFU 再到浏览器以后，声音会出现周期性的机器人“电音”。Agent Voice 关闭再打开以后，新 track 明明已经发布，某些浏览器却因为一次 subscription 没拿到完整的 session description，一直听不到声音，直到另一个参与者加入，触发新一轮 reconciliation 才恢复。还有一次 Worker 部署以后，Agent 的文字连接已经自动恢复，Voice grant 也还在，STT/TTS readiness 都正常，但 Agent 就是不再说话。最后查出来是本地 publication 状态坏掉以后没有进入正确的 rebuild 路径，文字恢复了，媒体没有真正恢复。
这里面还夹着权限问题。一个 Agent 被允许往 Room 里发布自己的声音，并不意味着它就应该获得发现 Human audio track、监听 Room 里其他人声音的权限。这两种能力最后还必须在同一套媒体连接里独立授权。
而这些问题经常不是单元测试能测出来的，只有真实浏览器、真实 SFU、真实 Runtime 和多设备一起跑的时候才会暴露。所以 Free4Chat 的代码量并不是它复杂的主要原因。真正麻烦的是，一个看起来很小的功能，经常会同时跨过浏览器、WebRTC、Cloudflare、原生 Runtime、Agent Harness、授权和生命周期几层边界。
最近几个月，它又继续长出了 Task、Live View、Room Apps、Agent Permission，以及 Human 和 Agent 共享的各种临时协作能力。功能和代码增长的速度，已经明显超过我用业余时间逐个 PR 理解它们的速度。
策引则是另一种复杂度。它从一个投资组合和策略工具逐渐长成了一个比较完整的系统：行情数据、策略执行、回测、任务调度、组合指标、AI 分析、研究系统、邮件通知，以及运行这些东西需要的一堆基础设施。它目前的 AI 与系统架构也单独整理在公开的 ai-architecture 仓库里。
如果说 Free4Chat 的复杂度来自一条实时链路往下挖得很深，策引则更像一个小型软件公司逐渐长出来的技术面：从 Web 产品一直跨到数据、策略、任务调度和生产基础设施，而且还夹杂着金融领域自己的正确性问题。
比如定投组合里，外部现金不断进入账户以后，如果直接使用 broker portfolio value 计算收益，就可能把“新打进来的钱”误认为投资赚到的钱。系统里其实已经有一条剔除现金流影响的 NAV，并用它重新计算 CAGR、最大回撤、波动率等指标，但 Sharpe Ratio 曾经恰好漏掉了这条修正。最后原始 Sharpe 接近 2，换成正确的现金流调整收益序列以后只有 0.6 左右。这种 Bug 没有什么炫酷技术，但如果结果错了，整个产品就是错的。
还有一类是数据和基础设施问题。比如过期的行情缓存可以从对象存储恢复到 Redis，但如果恢复动作同时刷新 Redis TTL，那么 TTL 表示的就不再是“这份行情有多新”，而只是“我什么时候从对象存储读过它”。更麻烦的是，第一次修它以后还会引入新的问题：如果上游 Provider 故障，scheduler retry 可能放大请求；如果 cooldown 在 Provider 调用以后才建立，就挡不住并发；对象存储的旧值还可能反过来覆盖 Redis 里更新的值。最后一个看起来只是“缓存过期”的问题，会一路牵扯 source freshness、retry amplification、cooldown ownership、Redis recovery 和多级缓存之间的数据优先级。
一个往技术深处走，一个往业务和系统宽度走。它们当然不能代表整个软件行业，但至少都已经复杂到不能简单当成两个 Vibe Coding Demo。也正因为如此，后来发生的变化才让我越来越难忽略。
从实现层退出
以前我判断一个工程师水平，很大程度就是看代码。代码里有太多东西无法伪装：怎么拆边界，怎么处理异常，状态放在哪里，怎么避免 race condition，什么时候抽象，什么时候不抽象，一个错误到底是在局部打补丁还是找到真正 ownership。代码就是工程师留下的思考痕迹。
但是现在，如果你让我打开 Free4Chat 最近一个月的代码，随机挑一个模块问我里面怎么实现，我很可能答不上来。策引也差不多。
我知道它们整体是什么，为什么这样设计，哪些边界不能碰，哪些方向我不想做；我知道 Free4Chat 为什么必须保持 temporary、anonymous-first，为什么不能慢慢变成一个永久 Workspace，也知道策引为什么坚持白盒策略和组合级决策，而不是最后变成一个神秘 AI 选股器。但很多具体实现，我已经不知道了。
这不是因为我从项目退出了。恰恰相反，我每天仍然在决定这两个项目接下来做什么。改变的是：我正在从软件的实现层退出。
现在常见的开发方式大概是这样。我和 ChatGPT 讨论一个问题，确定产品方向和工程约束，然后把任务交给 Codex、Claude、DeepSeek、GLM 或其他 Coding Agent。Agent 读仓库、查 issue、实现、跑测试、修 CI。完成以后，我再让另一个模型做 Review。现在我经常用 ChatGPT 的高能力模型来做这一层。Review 认为有问题，就把意见再发回实现 Agent。修完再 Review。直到 Reviewer 认为没有 blocker。然后合并。
最值得注意的一点是：这个循环里经常没有我对代码的逐行 Review。2023 年我还认为 Human Review 是 AI Coding 最后不可跨越的防线。到了今天，这道防线本身也开始由另一个 Agent 承担。
某种意义上，我从：
设计 → 写代码 → 测试 → Review
变成了：
决定要解决什么 → 看结果是否值得接受。
甚至中间那个“把 Reviewer 意见复制给 Coding Agent”的动作都开始消失。Computer-use Agent 可以自己操作浏览器，访问已经登录的系统，甚至自己打开 ChatGPT，把 Review 结果继续喂回下一轮开发。
以前我还开玩笑说，将来的软件工程师可能退化成“复制粘贴工程师”。现在看来，连复制粘贴都不一定需要人。
风险结构变了
这里很容易产生一个误会：既然我不 Review 代码，是不是因为 Agent 已经几乎不会出错了？
当然不是。
Free4Chat 就出现过 CI 全绿、PR 合并，然后首页直接不工作的情况。多人真实测试也抓出过大量自动化没有覆盖的问题：浏览器随着 Room 时间变长越来越卡、附件在不同设备上读取失败、某些 Agent 收不到 @mention、手机和桌面看到的 Screen Share 不一致、一个十几 MB 的视频有人能收到、有人收不到。WebRTC 尤其喜欢教育所有相信“测试已经全绿”的人。
所以我现在不亲自 Review 代码，并不等于风险消失了。只是风险结构变了。
以前我的假设是：AI 写，人来确保正确。现在更接近：Agent 写，Agent Review，自动测试和真实运行一起不断暴露问题，Agent 再修；人接受这个系统不是数学上可靠的，只在真正重要的地方介入。
Agent Review 不会创造正确性。它只是把 Review 本身也机器化了。这也是为什么我并不认为现在的开发模式意味着“工程经验没用了”。恰恰相反，经验仍然重要，只是它越来越少直接表现为我亲手写出的代码，而更多表现为：我知道什么地方不能随便相信。
连“发现问题”也开始被交出去
另一个很容易产生的误解是：是不是我仍然扮演那个真正的 Senior Engineer——由我发现问题、定义问题，然后让 Agent 去修？
如果真是这样，那么变化其实没有那么大。只是 Senior Engineer 多了一批非常便宜的执行者。但实际情况也不是这样。
前面策引那个 Sharpe Ratio 的问题，并不是我拿着公式检查报表时发现的。很多缓存、并发、安全问题也不是我先定义好了，再让 Agent 写代码。它们往往来自 Agent Review、自动测试、日志调查或者生产异常后的系统性排查。
例如策引有过生产任务报错，Slack 先收到告警。以前这种事情意味着我得登录服务器、查日志、定位 job、检查 Redis、看看队列、比对最近发布，然后慢慢把故障链串起来。现在很多时候，我把错误交给 Agent。它自己查日志、看部署状态、分析最近修改、检查相关缓存和队列，最后给我一份类似 incident report 的东西：发生了什么、在哪一层失败、是不是暂态错误、有没有数据损坏、是否需要修、需要的话怎么修。有时候我对这次事故的全部了解，就是最后读了这份报告。
这件事对我的冲击其实比“Agent 会写代码”大得多。写代码本来就是最容易被自动化的软件工程活动之一。但当 Investigation、Code Review、Test、Production Diagnosis 也逐渐变成 Agent 的工作以后，问题就不再只是：以后程序员还要不要自己写代码？而是：软件生产过程中，到底还有多少环节必须有软件工程师持续参与？
人还剩下什么
当然，这不意味着我什么都不管了。恰恰相反，我对某些事情反而管得更紧。
首先是产品方向。Free4Chat 到底是什么，不是 Agent 决定的。它很容易继续往功能上长：永久 Workspace、Agent 平台、账号体系、中央 Memory、任务管理、插件市场、远程桌面……这些方向每一个都可以写出非常合理的 PRD。但我不想让它变成这些东西。
Free4Chat 的价值在我看来恰恰是：一个低成本、临时、无需永久 Workspace 的协作空间，Human 和 Agent 可以临时进来，各自带着自己的能力，协作完就走。很多时候最重要的产品决策不是“加什么”，而是“不做什么”。Agent 很擅长回答“如何把这个需求实现得更完整”。但一个项目为什么存在、什么东西虽然可以做却不该做，这些目前仍然高度依赖人的价值判断和品味。
第二类我一定会看的是成本。Free4Chat 是免费的。所以很多架构选择最终不是一个纯技术问题，而是一个非常现实的问题：如果用户增长 100 倍，我愿不愿意付这张账单？
我会去看 Cloudflare Durable Object duration，算 SFU egress，看长期连接有没有破坏 hibernation，看一个功能是不是悄悄把高频数据写进存储。策引也一样。Fly.io、Cloudflare、模型 API、行情服务，最后都会变成真实信用卡上的数字。这时候我会突然重新变得像一个非常保守的架构师。因为 Agent 不会因为下个月 Cloudflare 从它信用卡里扣钱而睡不着。我会。
第三类是最终的人类体验。一个 Voice Agent 的声音到底自然不自然，一个按钮放在那里是不是很奇怪，手机上这个 Room 用起来是不是让人烦，等待三秒和等待八秒到底有什么区别。这些东西当然也可以做自动化测试，可以做 Browser Agent，可以让 Vision Model 打分。但我还是会自己打开它。毕竟这个软件最后还是给人用的，而我刚好是个人类。
最后还有一件更根本的东西：责任。账号是我的，服务器是我的，信用卡是我的，用户遇到问题最后找的也是我。Agent 可以提出判断，可以执行判断，但最后什么风险值得承担，目前仍然是我的问题。
所以我现在越来越觉得，人没有完全从软件生产里消失。更准确地说，人正在从大量过程里消失，然后集中到少数高后果的决策点上。
注意力成为新的瓶颈
这也带来了一个以前没有的问题。过去业余项目最大的限制是时间。想到一个功能，周末可能只剩四个小时。你得自己设计、写、调试、测试。一个稍微复杂的功能做几周很正常。所以我们天然会控制 Scope。不是因为产品判断特别高明，而是因为根本写不过来。
现在这个约束明显变弱了。Agent 可以在我工作、吃饭甚至出去玩的时候继续实现、测试和修问题。周末我有时候只需要集中看半天。剩下的机器自己跑。
于是新的瓶颈出现了：我根本看不过来。不是代码写不完，而是 Agent 生产出来的代码、PR、分析、issue、实验、Review 结果越来越多，我没有足够注意力逐个理解。这也解释了为什么“不亲自 Review 代码”最终几乎是必然的。如果机器一天可以产生几十个值得合并的修改，而人仍然坚持逐行读完，那么 Agent 的生产能力最终还是会被人的 Review 带宽锁死。
所以我现在越来越主动地区分：哪些东西值得我花注意力？普通实现细节，不看。测试失败，Agent 自己修。一般 Review 意见，Agent 自己处理。偶发生产错误，先让 Agent 调查。但如果它涉及成本突然上升、产品方向改变、权限边界变宽、架构开始失控，或者某个真实用户体验我觉得明显不对，我才会进去。
以前软件工程的稀缺资源是 Engineering Time。现在至少在这两个项目里，更稀缺的是 Human Attention。
经验从生产能力变成风险控制
做到这里，一个很自然的反驳是：你能这么玩，是因为你本来就是一个做了十几年软件的人。这个反驳我认为是对的。
我虽然没有逐行 Review，但我并不是完全不理解这些系统。Free4Chat 的整体架构边界、为什么要拆 Runtime 和 Harness、为什么 capability 不能等价于 authorization、为什么高频 App 数据不能走 Durable Object，我是知道的。策引为什么必须区分外部现金流和投资收益，为什么组合指标不能只看漂亮数字，为什么白盒策略比“AI 神秘预测”更重要，这些我也知道。这些经验决定了我更容易知道该问什么，哪些结果值得怀疑，什么设计虽然能 Work 但从根上就不该做。
Anthropic 今年 6 月发布的研究《Agentic coding and persistent returns to expertise》分析了大约 40 万个 Claude Code session。一个很有意思的结果是，典型 session 里，人仍然承担大约 70% 的 planning decision，而 Claude 承担大约 80% 的 execution decision；更有经验的用户往往还能让 Agent 在每一次指令后完成更长的 action chain。他们还发现，经验仍然显著影响成功率。被判定为 novice 的 session，严格意义上的 verified success 只有大约 15%；到了 intermediate 以上，大致提高到 28%—33%。而当任务已经遇到明显问题时，novice session 最后仍然成功的比例大约 4%，expert 可以达到 15%。这和我的体验非常一致。
只是这种经验的作用已经不像以前那样直接。过去是：你不懂，所以你写不出来。现在越来越像：即使你不懂，Agent 也可能给你做出来；但你懂不懂，会影响你是否知道什么时候不能相信它。软件工程经验正在从一种直接生产能力，逐渐变成一种风险控制能力。
更有意思的是，Anthropic 的数据里，在真正产生代码的 session 中，软件相关职业的 verified success 大约是 34%，其他职业已经达到约 29%；如果把 partial success 也算进去，则分别是 89% 和 88%。如果这个差距继续缩小，那么软件生产可能逐渐变成所有职业中的一种普通活动，而不再天然属于一个单独的专业职业。这可能才是软件工程师真正需要担心的部分。不是 Agent 会不会写代码，而是“能够生产软件”这件事，本身是否还需要成为一个独立职业。
软件工程本来就是为人设计的
我以前写过一系列 Google Software Engineering 相关的文章。其中一个我很认同的观点是，Programming 和 Software Engineering 不是一回事。程序写出来，只是开始。软件会存在很多年，会不断变化，会有越来越多人修改它。真正困难的是怎么让一个团队在时间和规模上持续安全地改变一个系统。
所以我们才有 Code Review、CI、Design Doc、Tech Lead、Ownership、On-call、Knowledge Sharing、Coding Convention，以及各种开发流程。这些东西当然有技术价值。但回头再看，会发现它们里面相当大一部分其实是在解决一个问题：怎么让一群能力不同、信息不同、会犯错、会遗忘、会离职，而且沟通带宽有限的人一起维护一个复杂系统。
Code Review 不只是检查 Bug，它还传播知识。Design Doc 不只是记录设计，它让不同的人先形成共识。Coding Convention 不只是追求漂亮，它减少团队认知成本。On-call 和 Ownership 也不仅是 Debug 机制，它们首先回答“出了问题到底谁负责”。
过去我们默认：软件复杂度增长，最终一定需要更多人。人变多以后协调成本上升。于是 Software Engineering 这整套方法论出现，用来控制人的协作复杂度。但如果一个参与者可以同时读完整仓库、Issue、PR、日志和文档，不会因为今天请假漏掉上下文；如果它可以在几分钟内 Review 一个巨大 Diff；如果另一个 Agent 又可以重新独立 Review；如果它们不需要开会，不需要等第二天上班，也不存在“这个模块只有老王知道”这种组织记忆问题——那我们过去一些理所当然的软件工程结构，至少会开始变得奇怪。
并不是所有流程都会消失。但它们原本优化的对象正在改变。
2016 年的 Full Stack，和 2026 年的 Agent
这件事让我想到 2016 年我写过的一篇《一款产品的从 0 到 1 之旅》。当时让我很兴奋的一件事是，一个人借助开源软件、云服务和 Full Stack 技术，已经可以把一款完整产品做出来。
但当年的“一人开发”是什么意思？意思是一个人自己做更多事情。自己设计。自己写 iOS。自己写 Backend。自己设计数据库。自己部署服务器。自己测试。Full Stack Engineer 的本质其实是：一个人会做整个 Stack。
十年以后，这件事情变得有点不一样。Agent 时代的一人开发，不一定意味着一个人学会了整个 Stack。甚至可能恰恰相反：一个人越来越不需要亲自去做整个 Stack。这两个状态表面上都叫“一人开发”，背后的生产方式却完全不同。一个是人的技能边界不断扩大。另一个是软件生产开始脱离人的直接执行能力。从这个角度看，Full Stack Engineer 也许只是一个很有意思的过渡形态。
样本的边界
说到这里也必须把样本的局限讲清楚。Free4Chat 和策引都是我的项目。没有大型组织，没有几十个团队，没有复杂审批链。很多事情我可以直接决定，做错了也主要由我自己承担损失。所以我能够非常激进地把权限交给 Agent。
企业里显然没有这么简单。金融、医疗、大型基础设施和各种受监管系统，需要审计、责任分离、合规签字、变更审批。就算 Agent 技术上可以完成某件事，也不代表组织会允许它自己做。而且团队协作里的很多“摩擦”本来就不是纯粹的浪费。知识扩散、责任确认、多人 sign-off，本身也是风险控制和组织治理。
所以我并不认为：两个 side project 已经证明未来所有公司只需要一个工程师。这当然是胡扯。这两个样本真正有意思的地方，是它们接近一个低组织摩擦环境。一个人拥有比较完整的产品决策权、架构权和最终责任，又可以自由使用 Agent。在这种条件下，我们可以看到一个以前很难看到的东西：一个有一定复杂度的软件，为了持续演进，最低到底需要多少 Human Engineering Labor？
我现在看到的答案，比三年前想象得低很多。大型企业不会立刻达到这个下限。甚至可能永远不会。但这个下限本身一旦下降，就已经足够重要了。因为市场最后会不断尝试逼近它。
当 Engineering 变得便宜
更讽刺的是，当“做软件”越来越容易以后，我没有觉得做产品变容易。Free4Chat 可以快速实现很多新能力。策引也可以不断增加实验、分析和自动化。但真正难的问题一个都没有消失：谁需要它？为什么要用？为什么愿意长期用？为什么愿意付钱？这个需求是真的，还是我自己觉得有意思？产品有没有 PMF？
这些问题没有因为 Coding Agent 变强而自动得到答案。某种程度上，问题反而变得更严重。以前很多产品不会出现，是因为做出来太贵。一个想法如果需要五个工程师做半年，很多人连试都不会试。现在同一个想法可能几天就能做出第一版。于是软件的供给会变得非常便宜。而需求没有同步增长。人的时间没有变多，钱包也没有变厚。这意味着 Agent 时代也许不是“每个人都有一个成功软件产品”，而是：世界上会突然出现多得多的软件，然后绝大多数软件仍然没人要。
Engineering scarcity 正在下降。Problem scarcity 没有。这也是为什么我现在会比以前更频繁地砍掉 idea。既然实现越来越便宜，那么真正需要节约的就不再是代码，而是注意力和机会成本。
下一代 Senior 从哪里来？
但这里还有一个我目前没有答案的问题。
我今天能够这样使用 Agent，很可能确实和我已经做了十几年软件有关。以前那些痛苦经历——自己 Debug 并发问题、自己看线上事故、Review 别人的代码、被别人 Review、做过错误架构然后再重构——共同形成了某种风险直觉。很多东西我甚至没办法写成 Checklist，只是看到一个设计，就觉得哪里不太对。
但这些经验过去是怎么产生的？过去一个 Junior Engineer 会亲手写大量代码，也会不断犯错。他会在 PR 里被 Senior 一遍遍指出问题，自己 Debug，遇到线上事故，再回头修改设计。几年下来，这些密集的反馈才慢慢变成经验，最后让他知道哪些地方最容易出错，哪些方案虽然局部合理，却会在长期把系统带向错误的方向。
如果未来最有效的软件生产方式变成 Agent 负责写代码、Review、Debug 和事故分析，而 Junior 更多只是在最后看到一句“tests passed”，那么这条经验形成路径就会发生很大的变化。十年以后，我们还能够期待这样的人自然拥有今天 Senior Engineer 的判断力吗？如果可以，这种判断力又会从哪里来？
这也许是 Agent 对软件工程行业最反常的长期影响之一。当前最有效的 Agent 工作流，似乎仍然非常受益于有经验的人；但这种工作流本身，却可能正在减少产生这些经验的机会。软件行业也许不仅在减少 Junior 岗位，它甚至可能在改变自己生产 Senior Engineer 的方式。
也许未来的工程经验会通过完全不同的路径获得——更多来自设计、评估、模拟和对 Agent 失败的观察，而不是亲手写几十万行代码。也许模型本身最终会补上现在人类专家提供的判断。Anthropic 在那份研究最后也专门提到，他们正在观察“expertise 的收益是否会随着模型进步而下降”；如果有一天这种收益真的持续下降，那么今天我们还能保留下来的这部分人的价值，也未必稳固。
我不知道答案。但这个问题可能比“Junior 要不要学 Python”重要得多。
置身其中
2016 年，我看到的是开源软件和云计算让一个人可以做过去一个团队才能做的软件。2023 年，我看到 ChatGPT 已经可以当 Driver 写大量代码，但我仍然觉得人的 Review 不可替代。2024 年以后，我开始越来越少亲自写代码，把自己放到更高层的架构和设计位置；那时我已经把这种方式称作 AI 驱动开发。而现在，我发现连 Review、测试、Debug、生产故障调查这些原本属于软件工程师核心职责的工作，也在不断离开人。
我并没有感觉软件因此变简单了。Free4Chat 比以前复杂得多。策引也比以前复杂得多。代码更多，系统边界更多，真实用户和真实生产问题也更多。奇怪的地方恰恰在这里：软件仍然在越来越复杂，但这种复杂度已经不再要求同比例增长的人类工程劳动。
这也许才是 Agent 时代真正重要的变化。过去我们通常默认：软件越复杂，需要的软件工程师越多。未来这个关系未必成立。
也许仍然需要一个有经验的人决定产品方向、约束系统边界、盯住成本、承担风险，并在真正重要的地方做最终判断。也许大型组织仍然需要很多人，因为责任、合规和组织结构本身不会消失。也许今天的 Agent 工作流还有大量我们尚未理解的风险。但至少在我亲手维护的这两个项目里，我已经很难再假装一切只是“程序员获得了一个更好用的工具”。
我现在看到的更像是：软件本身仍然需要被设计、被运行、被维护。只是完成这些事情的主体，正在发生变化。
我仍然是一名软件工程师。但在我自己的软件里，我已经越来越不像传统意义上的软件工程师了。
如果未来的软件仍然可以继续增长、继续变化、继续处理复杂的工程问题，而人类工程师越来越少进入它的实现过程，那么真正值得问的也许已经不是：AI 会不会取代软件工程师？
而是一个更基础的问题：复杂的软件，还需要和过去一样多的软件工程师吗？
以及那个我现在反而越来越在意的问题：如果以后真的只需要少数有经验的人带着一群 Agent 工作，那么这些“有经验的人”，又是从哪里来的？