本文是「每周 Signal｜AI × SE」第 31 期，关注 AI 如何改变软件工程与研发实践。
本期 Signal：AI Coding 正在更深入参与存量系统中的复杂工程任务。Agent 扩大了工程师能够持续推进的改造范围。
过去很多 AI Coding 的演示和讨论，集中在实现功能、修 Bug、完成相对局部的代码变更。
但最近几个案例开始把 Agent 放进另一类任务：对一个已经运行多年、规模庞大，而且不能轻易出错的现有系统，持续进行大范围改造。
这类任务的难点远不只是代码生成。
真正困难的是：如何理解原有行为、拆解改造范围、控制迁移风险，并且在持续变化的代码库里证明“改完以后系统依然工作”。
这也是本周几个案例真正值得关注的地方。
9 月，GitHub 披露了一个很极端的案例：他们使用 GitHub Copilot，把 Copilot Agent Runtime 从 TypeScript 迁移到了 Rust。
最终形成了超过 83 万行生产 Rust 代码，AI Agent 编写了其中的大部分代码。整个迁移被拆成 128 个 Pull Request，持续合入主干，而没有等到最后一次性切换。
单看“80 万行代码”，很容易把它理解成又一个展示 AI 代码生成能力的案例。
真正值得看的，是 GitHub 如何把这么大规模的改造放进一个可控的工程过程里。
他们没有把迁移整体交给 Agent 后等待最终结果，而是把工作持续拆成可以独立合入的变更。
原有 CLI 和 SDK 的端到端测试持续运行在新的 Rust 实现上，必要测试失败，对应 PR 就不能合入。整个约 14.5 周的迁移过程中，主干发布了 135 个版本，让迁移后的组件不断接受真实使用验证。
这里还有一个很重要的工程原则：负责修改实现的 Agent，不能同时随意改变判断实现是否正确的测试。
Agent 可以承担越来越多执行工作，但验证标准需要保持独立。
整个过程实际上形成了一个持续运转的闭环：
拆分变更 → 实现 → 测试 → Review → 合入 → 发布 → 继续验证。
规模就是在这样的闭环里被逐步消化掉的。
GitHub 的复盘里还有一个比代码量更值得关注的变化。
项目负责人 Stephen Toub 主要把注意力放在架构、设计、约定和实现方式上；Agent 承担大量新旧实现对比和具体编码工作，测试与静态分析负责机械验证，人则集中处理架构、API Contract 和高风险区域。
目的架构怎么设计、哪些行为必须保持、任务怎么拆、高风险代码是否可以合入，这些关键判断依然由工程师负责。
变化发生在另一边。
过去，一名工程师的大量时间会消耗在具体实现上。当 Agent 可以持续完成迁移、修正，以及围绕验证反馈继续迭代时，工程师能够把更多注意力放到系统边界、风险和最终判断上。
一名工程师因此能够持续推进更大范围的系统改造。
这可能才是这个案例最值得关注的地方：
Agent 扩大了工程师能够持续推进的改造范围。
同一周，GitHub Security Lab 开源的 Fuzzing Taskflow 又展示了另一类任务。
它针对已有 C/C++ 项目，让 Agent 自动编写 Fuzz Harness、运行模糊测试、读取覆盖率结果，再根据没有覆盖到的分支修改 Harness 或补充输入，然后继续下一轮测试。
Agent 还可以对 Crash 进行归类、分析调用链，并生成漏洞分析和修复建议。
当然，GitHub 也明确提醒：Agent 对漏洞和补丁的判断依然可能出错，最终结果需要人工 Review。
这个案例和大规模语言迁移做的是两件完全不同的事。
但它们背后的变化很接近：
AI Coding 正在进入更多建立在既有代码、既有测试和既有工程约束之上的复杂任务。
Agent 不只是实现一个孤立需求，它开始读取系统状态、执行任务、获得验证反馈，再基于反馈继续行动。
Anthropic 在 Claude Opus 5.5 发布时也披露过一个案例：一名早期测试者完成了一次 68 万行代码迁移。
这个案例来自厂商披露，公开信息有限，缺少 GitHub 案例里完整的工程过程，单独看不足以说明趋势。
但把这些案例放在一起，可以看到一个越来越清楚的方向：
大型代码迁移、安全治理，以及更多围绕已有系统展开的工程任务，正在进入 Coding Agent 的实际使用范围。
这件事对企业研发尤其重要。
真实世界的软件开发，很少从一张白纸开始。
更常见的是一个已经运行多年的系统：技术栈需要升级，架构需要调整，依赖需要迁移，安全问题需要治理，同时业务还在持续变化。
很多这样的改造过去并非做不到，而是投入太高。
庞大的实现量、持续不断的验证、大量机械性的修改和修复工作，让一些技术债即使已经知道怎么解决，也会被不断推迟。
当 Agent 大幅降低这部分执行成本，一些过去成本过高的系统改造，就可能重新变得可行。
但 GitHub 的案例同时给出了另一半答案。
Agent 能写更多代码，并不意味着可以把一个巨大任务直接扔给它。
相反，代码生成能力越强，越需要把大的变化拆成可验证、可合并、可发布的小变化，并保留工程师对架构、风险和最终结果的判断。
AI Coding 正在深入存量系统改造。
它带来的变化，可能不只是让一次迁移做得更快。
更重要的是：
工程师能够持续推进的系统改造规模正在扩大。
《企业研发 AI 自动化》是我持续记录 AI 进入真实研发流程后的实践系列。
它关注的不只是 AI Coding 工具本身，而是从需求输入、任务表示、Agent 执行到自动化验证的完整链路：AI 如何在真实工程系统里稳定运行，并逐渐形成可复用的研发自动化能力。
欢迎关注和交流～
