维护老旧系统的程序员，大多对AI直接修改代码这件事带着一种难以说清的抵触。外人看会觉得这是思想保守，不愿意接受新工具，但长期泡在老系统里的人清楚，这份顾虑都很现实，每一条都和工作风险挂钩。
老旧系统最大的隐患就是缺少完备测试。新项目一般都配备单元测试、集成测试，AI改动代码之后，跑一遍测试就能快速发现问题。老系统不一样，已经运行十几二十年，测试用例早就和代码脱节，部分模块连文档都找不到。让AI修改某个函数，生成的代码看着逻辑通顺，但没法判断改动会不会牵动隐藏的依赖关系。完整的测试环境甚至都搭建不出来。AI修改每一行代码都相当于冒险，顺利上线没人会特意认可，一旦出问题就是生产事故。
老代码里藏着很多不能随意改动的逻辑。有些代码看着冗余别扭，似乎可以简化，背后往往都有原因。可能是早年客户单独提出的特殊需求，也可能是故障之后临时补上的补丁，或是早已离职人员留下的遗留代码。这些背景信息不会写在文档里，只留在长期维护人员的记忆中。AI看不到这些历史，碰到重复代码就合并，发现死循环就优化，遇到多层嵌套就重构。改完之后基础功能正常，但一些极少触发的边缘场景行为会出错。这类场景可能一年才出现一次，等到故障爆发时，很难联想到是半年前AI改动代码造成的。
责任划分也是绕不开的难题。AI参与代码修改，改动成功大家会归功于工具；一旦线上出故障，责任由谁承担？系统发生故障，负责人不会去找AI，只会找到提交代码上线的程序员。程序员心里清楚，AI可以一次性生成大量方案，出问题却不用承担后果，背锅的是自己。所以很多人宁可保持代码原样，也不愿意让AI介入核心模块。这不属于技术层面的分歧，本质是责任风险考量。
还有一点和职业安全感相关。这套老旧系统虽然落后，但支撑着不少程序员的工作价值。整个公司只有少数几个人读懂这套代码，自己就是其中一员，这就是不可替代的价值。AI把代码梳理清楚，补全注释，生成完整文档之后，这份独特优势就会减弱。这不算是自私，属于人的本能。当一个人花费数年吃透一套复杂系统，突然出现工具可以接手相关工作，心里难免会有顾虑。
老系统本身的代码风格也是阻碍。AI生成代码有固定习惯，变量命名、注释写法、异常处理逻辑，都会和原有老代码风格冲突。让AI修改单个函数，它经常顺带重构周边代码，提交代码之后，评审人员查看改动记录，大片内容被修改，很难区分哪些是必须调整的部分，哪些是AI额外改动的内容。这种改动记录没法完成评审，只能退回重写。经历几次之后，团队一般会达成共识：AI可以用来咨询思路，但不要直接改动代码。
还有一个比较隐蔽的原因，在于代码背后的背景逻辑。维护老系统十几年的开发，清楚每段代码产生的缘由。这一行是当初为优化性能添加，那一行用来规避数据库bug，某个判断条件是过去领导确定的方案。这类信息不会写进代码，只存在人的记忆里。AI修改代码只能根据现有代码做判断，不清楚背后故事。改动之后功能正常，但这段代码的设计初衷就丢失了。后续再次遇到故障排查，没人知道该从哪个方向入手。这类知识流失，比代码本身出现bug更难处理。
总的来说，维护老系统的程序员不是否定AI本身的能力，而是不信任AI能读懂代码里那些没有写出来的历史背景。一套运行二十年的系统承载的不只是业务逻辑，还有历代人员的决策、妥协、试错积累下来的经验。这些内容没有文档记录，只保存在人的记忆当中。AI改动只能调整代码表层逻辑，很难顾及深层的历史约束。一旦表层代码改动，潜藏的业务逻辑就有可能被打乱，这才是大家真正担心的地方。
