近期，开发者社区中流传着一种观点：自 2025 年起，部分从业者已不再亲自编写代码；代码审查环节被取消；人们也不再阅读源代码。尽管软件行业正在经历变革，但那些完全依赖自动化工具而放弃人工介入的团队和项目，正面临严峻的可维护性挑战。
代码质量缺乏量化标准
随着时间推移，过度依赖 AI 生成代码的项目往往陷入混乱。核心原因在于，目前业界缺乏衡量代码可维护性和架构良好程度的有效指标。
通常意义上的“坏代码”具有以下特征：
- 难以阅读、理解及扩展；
- 局部修改可能引发不可预测的全局故障（蝴蝶效应）；
- 因多处重复逻辑未同步更新导致的不一致性；
- 设计不变量模糊，且原始作者缺席无法确认意图；
- 测试困难，需大量模拟并暴露实现细节，导致测试脆弱，阻碍重构。
识别此类问题通常需要数月甚至数年的时间。虽然资深工程师凭借直觉能敏锐察觉代码异味，但这种基于经验、汗水和长期调试形成的直觉，难以转化为初学者适用的严格规则或食谱。专家往往是规则的制定者而非遵守者。
AI 在代码维护上的局限性
当前的人工智能模型存在根本性缺陷：它们未经过训练以维护代码的语义含义。强化学习依赖于即时可衡量的奖励信号，而代码质量的反馈周期长达数月或数年。此外，AI 主要学习的是新手级别的编码规范，而现实中大多数代码质量堪忧，且无法为“可维护性”定义一个明确的适应度函数。
即使是 SOTA（最先进）模型，在“简化”代码方面的表现也令人担忧。例如，AI 常错误地将函数拆分为实际上无法复用的微小片段，迫使开发者为了理解整体逻辑而不得不深入阅读这些碎片化函数的实现。定义清晰、可复用的函数是一种需要高度掌握的艺术，而大多数开发者在德雷福斯模型中仍处于“高级初学者”阶段，难以胜任此项工作。
责任缺失与技能退化风险
若人类仍能掌控全局并从错误中学习，情况或许尚可接受。然而，趋势显示人们正逐渐依赖 AI 编写甚至阅读代码。由于不再主动做出技术选择，开发者对编码错误的责任感减弱，进而失去了从错误中学习的机会。值得注意的是，AI 本身会犯错，且不具备从错误中自我修正的能力。
LLM 确实是一个强大的工具，并非洪水猛兽。许多开发者已将 AI 融入日常工作，利用其处理繁琐、枯燥的任务，并从中获得效率提升。同事间也在分享使用心得。然而，如同其他技术革命一样，初期的光环可能会褪去，盲目追捧科技新闻的热度也会冷却。
未来展望：负责任的自动化
对于未来的预测充满不确定性，但有一种可能性值得关注：越来越多的公司可能会将“不使用 AI”政策作为竞争优势，并证明这一策略的正确性。
软件行业一直致力于大规模自动化，LLM 并非唯一手段，在某些语境下甚至可能成为一种干扰。例如，与其花费资源让 LLM 重新构建 C/C++ 编译器，不如直接克隆 GCC 或 LLVM，从而免费获得更成熟的解决方案。人类的创造力和需求是无限的，资源应投向更有价值的创新，而非重复造轮子（如简单的 CRUD 应用）。
如果个人和企业不能对其使用的自动化工具保持负责任的态度，后果将是严重的。
