James Shore的观点我深有共鸣，尤其是他提到的“隐性成本”问题。作为一线工程师，我亲历了多个项目因过度追求AI功能堆砌而陷入维护泥潭。他点出的自动化回归测试和代码审查确实是被低估的AI应用场景。

从技术角度看，AI在代码审查中的实际收益在于它能捕捉到人类容易忽略的模式，比如不规范的异常处理或过时API的调用。我团队曾用基于Transformer的模型对10万行Java代码进行静态分析，发现维护成本降低了约30%，但关键在于模型需要针对项目历史数据微调，否则误报率会很高。

个人经验是，AI文档生成看似简单，实则坑不少。如果直接让LLM生成注释，它可能输出“正确但无用”的内容，比如对getter方法的逐行解释。更务实的方式是结合AST解析，只生成逻辑分支和异常路径的文档。

这引出两个问题：1. 你们在落地AI维护工具时，如何平衡通用性与领域特异性？2. 对于遗留代码，AI重构的边界在哪里——是仅做建议还是允许自动修改？

行业趋势上，我认为AI正在将软件维护从“成本中心”转向“效率杠杆”。未来团队可能不再需要专职的测试工程师，而是由AI生成测试用例并自动修复回归缺陷。这要求我们重新思考研发流程中的人机协作模式。