10月30日，《财富》披露了一条让工程圈吵翻的消息：思科总裁 Jeetu Patel 把重写公司 98% 遗留代码的任务，押在了一个 27 岁的年轻人身上——2 个人，24 个月，AI token 无限供应。36氪小红书
这个叫 Paddy 的年轻人不是普通工程师，他是被思科收购的 AI 创业公司前 CEO。按 Patel 的说法，团队里最有经验的老工程师都没敢提这种方案，只有这个「不懂规矩」的人提了。
先泼冷水：这目前只是个目标，Cisco目前尚未披露已完成的代码比例、系统范围、技术方案或测试结果，Paddy 自己只定了四周的初步验证期限。所以现在争论「成没成」，双方都在脑补。36氪
但「AI 能不能大规模重写遗留代码」这个问题本身，技术上已经有答案了。
Redis 作者 Antirez 今年 1 月把 Redis Streams 的设计文档交给 Claude Code，让它重做一遍内部逻辑。按他的记录，不到二十分钟就重做出来了，其中还花了时间等他检查代码、批准操作。他还让 AI 反复复现偶发故障，排查时序和 TCP 死锁这类老问题。知乎
迁移类的活反差更大：Anthropic 把 Bun 从 Zig 迁到 Rust 只用了 11 天，原本预估 1.5 个工程师年；Uber 把 60 万个 JUnit4 测试迁到 JUnit5 用了 4 个月，原本预计好几年。36氪
所以「写得动」是真的，这一层不用再争了。
真正值得讨论的是后面三件事。
第一，老代码里藏的不是代码，是事故记录。
Joel Spolsky 在 2000 年的文章里，借网景重写浏览器的经历反对轻易推倒旧代码。他的理由是：旧代码里那些看起来难看、难懂的分支，很可能保存着多年修 bug 的经验。比如一个旧接口在超时后有一段去重处理，文档没写原因，新实现看着碍眼就删了——正常调用一切顺利，客户一重试，同一笔订单执行两遍。知乎
新代码更漂亮，用户碰到的却是十几年前修过的问题。重写最大的成本从来不是写新代码，是丢掉旧代码里没写下来的隐性知识。
第二，验证才是真正的大头。
Linux 基金会 10 月的报告给了一组反差数据：开发者用 AI 后写代码时间平均省了 52%，但维护者估计收到的 PR 里约四分之一是低质量贡献，大型项目里这个比例升到 31%。InfoQ
被拖住的不止开源社区。英伟达工程师用一段1.2万行CuTeDSL编写的Megakernel，将月之暗面2.8万亿参数的KimiK3推理速度大幅提升。vLLM 团队在博客里直接承认：智能体优化的代码，产出速度已经超过人类的审查和维护速度。他们的应对是改流程——限定变更范围、系统化验证正确性，人类只审设计和证据，不再逐行看代码。钛媒体
这条新闻下面，点赞第二高的评论直接说：超级无敌背锅侠啊，以后出了任何问题都是他的锅了。有人问得更具体：嵌入式、后端、云服务，测试才是占比最大的一环，一个人做？哔哩哔哩
这个提问不是抬杠，它是整件事能不能成立的前提。
第三，出了事谁背锅。
那条「背锅侠」评论被顶到前排，说明大家担心的是同一件事：思科的客户是企业网络和关键基础设施，2 个人加 AI 重写生产系统，出一次事故的代价，可能抵得上省下的全部人力。技术之外，这是一道纯商业题。
那这件事跟普通开发者有什么关系？
关系不在「2 个人干掉一个部门」，而在于：你手里那些「知道该修但一直没排期」的模块，现在真的可以修了。过去不动它，是因为人手不够、风险太大；现在 AI 能先把调用链查清楚、把测试补上，再动手改。
但顺序别搞反。参考 Antirez 的做法：先给设计文档，让 AI 沿着调用关系查实现、补上测试，再动手修改，人只需要检查它有没有理解错业务；遇到看不懂的老分支，先让 AI 查它影响哪些调用、从历史提交里找原因，把对应场景写进测试——而不是直接删掉。
AI 把写代码的时间砍掉了近一半，省出来的时间该花在哪？Linux 基金会的报告里，66% 的受访者把效率收益投进了技术债务治理。InfoQ
这一次，别再把「没排期」当成理由了。
