回到手写代码：分析软件工程中的 AI 采用与回退趋势

AI 速度与系统理解力之间的张力

虽然大语言模型 (LLM) 编程助手已变得无处不在，但软件工程界的一部分从业者正在积极限制或回退使用 AI，以优先考虑心理模型和代码质量。这种转变的主要驱动力在于人们意识到，代码生成的速度并不总是与解决问题的速度或最终产品的稳定性相关联。

AI 生成代码的认知成本

对于许多开发者来说，推导解决方案并构建心理模型是软件工程中最关键的部分。依赖 AI 生成实现代码可能会使开发者与逻辑脱节，从而导致若干系统性问题：

• 失去心流状态： 自动建议可能会中断将脑中的愿景转化为代码的认知流过程。
• 掩盖架构问题： 当 AI 通过快速生成让一项艰巨的任务显得轻而易举时，开发者可能会忽视潜在的系统缺陷，而如果这些代码是手动编写的，这些缺陷本会显而易见。
• 技能侵蚀： 手写代码正日益被视为维持语法熟练度和应对技术面试准备的必要实践。

"having derived the code and built a mental model is something like 90% of the work, the code artefact being 10%... once I have this model / vision in my mind, I’m streaming it from my mind into reality via code and having code suggestions pop up breaks that flow state for me."

AI 驱动的技术债务与功能膨胀

在初创公司环境中，使用 AI 生成代码的便利性可能导致“功能膨胀”和架构纪律的缺失。在早期开发周期中快速迭代的能力可能会创建一个过于复杂而难以管理，或过于不稳定而无法用于生产环境的代码库。

一些组织正在考虑在不使用 AI 的情况下重写核心功能，以确保系统保持简单、易懂且变更速度较慢。这种方法将 AI 视为快速原型设计的工具，但将其视为核心架构稳定性的负担。

AI 使用的战略与经济约束

某些行业和公司规模决定了对 AI 采用采取更保守的态度：

• 深科技与高风险环境： 在专业领域，完全理解每一行代码是安全性和可靠性的前提条件。在某些情况下，客户可能会将 AI 生成代码的存在视为交易失败的决定性因素。
• 企业回退： 一些报告表明，大型实体（如 Ford, IBM, 和 Commonwealth Bank of Australia）已经缩减了与 AI 相关的招聘或计划，尽管其动机涵盖了从经济重组到质量控制的范围。
• “Vibe Coding” 的崩溃： 有传闻称，某些部门（例如 AWS 的 AI 部门内部）采用了“vibe coding”方法——优先考虑快速、AI 驱动的迭代，而非严谨的工程实践——结果在软件因缺乏稳定性而面临拆解或失败时，遭遇了挫折。

反方观点：AI 作为一种进化工具

相反，许多工程师认为，禁止 AI 相当于禁止 IDEs, 编译器, 或 Stack Overflow。他们认为，AI 仅仅是将复杂度从开发者身上转移的下一步，类似于垃圾回收机制取代了手动内存管理。

从这个角度来看，生产力增益是不可否认的，效率与摩擦之间的冲突是由于缺乏成熟的模式和设计原则。支持者认为，AI 最好的使用场景不在于核心逻辑，而是在边缘领域：安全检查、性能审计和测试生成。

AI 使用模式总结

Approach	Primary Motivation	Typical Use Case
Full Adoption	Maximum velocity and token-maxing KPIs	Rapid prototyping, commoditized UI, boilerplate
Selective Use	Balancing speed with deep understanding	Review, test generation, periphery checks
Manual Core	Architectural stability and client trust	Core technology, deep-tech systems, complex spatial reasoning
Complete Avoidance	Risk mitigation and skill preservation	High-security systems, interview preparation