32万粉编程大佬：我受够了AI炒作！

一位拥有32万粉丝的资深软件开发YouTuber（ArjanCodes频道）最近发布了一期引发广泛讨论的视频，直言自己"受够了AI炒作"。他并非反对AI，而是对行业中弥漫的浮躁氛围和对软件开发本质的误解提出了深刻批评。这些观点值得每一位开发者认真思考。

快速发布 ≠ 软件开发的全部

社交媒体上充斥着这样的帖子：有人搭建了一整个AI Agent团队——工程师、测试员、项目经理一应俱全，然后在一小时内发布完整应用，十分钟内交付新功能。仿佛软件开发就是一场"谁发布得最快、最多，谁就赢"的竞赛。

但事实真的如此吗？

这位博主指出，对于初创公司来说，快速开发MVP、验证想法确实至关重要。MVP（最小可行产品）的概念源自精益创业方法论，由埃里克·莱斯在《精益创业》中系统阐述，其核心逻辑是用最低成本验证商业假设，快速获得市场反馈。这套方法论在初创公司语境下极为有效，但它的前提是：失败的代价可控，迭代的空间充足。但这只是软件开发的一小部分。大多数软件运行在大型企业内部，承担着各种关键业务，不能随意变更。

大型企业的软件系统往往承载着截然不同的约束条件——合规要求（如金融行业的巴塞尔协议、医疗行业的HIPAA法规）、遗留系统集成、数据治理责任以及SLA（服务等级协议）承诺。这些约束使得"快速发布"不仅是工程问题，更是法律和商业风险问题。

如果你在银行或保险公司工作，"快速发布"不是美德，而是鲁莽。可能暴露机密、泄露客户数据、误删重要信息、损坏关键后端系统——这些都可能带来数百万的损失和一堆诉讼。大公司不在乎发布速度，他们在乎的是最小化风险。

这就是第一个问题：你不能把对独立开发者、小团队或AI创业公司有效的方法论，盲目套用到成熟的大型企业上。两者的需求截然不同。

写代码只是软件开发的冰山一角

当前AI炒作的第二个问题在于，它默认"软件开发 = 写代码"。

当然，我们确实写代码。但坦白说，这只是我们实际工作的一小部分。根据卡内基梅隆大学软件工程研究所的研究，在大型软件项目中，编码工作通常只占总工作量的15%~20%，其余时间分配给需求分析、系统设计、测试验证、文档编写和项目协调。这与建筑行业的"冰山模型"高度吻合——可见的建造施工只是整个工程的表层，地基勘探、结构设计、材料选型等隐性工作才决定了建筑的质量与寿命。

一个软件开发者日常要做的事情远比写代码复杂得多：

• 设计与架构：思考系统的整体结构
• 需求沟通：与利益相关方反复讨论，搞清楚到底要做什么
• 编写测试：确保系统的可靠性
• 创造性解决问题：为复杂问题找到优雅的方案
• 安全性设计：让系统默认就是安全的
• 用户体验思考：如何让系统更简洁、更好用
• 可持续性：确保今天的工作不需要明天重做

AI工具目前能够显著加速的，恰恰是那15%~20%的编码部分，而对架构设计、需求沟通等隐性工作的支持仍然十分有限。

博主直言："我把写代码本身视为一种事后工作。如果你事先把事情想清楚了，写代码并不是最难的部分。"

他用了一个精妙的比喻：这就像说你有一把电动螺丝刀就是木匠了。用机器把螺丝拧进木头确实很方便，但你能搭建屋顶吗？你能砌一面墙吗？拧螺丝是最简单的部分。

责任不可委托给AI

有人会说："这只是AI目前的水平，几年后它也能做架构设计和系统思考了。"

博主对此提出了一个更深层的反驳：如果你没有商业经验，你可能以为经营企业就是"委派任务"。如果是这样，那AI确实可以取代所有人。但事实并非如此。

经营企业不是委派任务（delegating tasks），而是委派责任（delegating responsibilities）。

这一洞察触及了一个深层的法律与组织管理问题。在现行法律框架下，AI系统不具备法律人格（Legal Personhood），无法成为责任主体。无论是欧盟的《AI法案》（EU AI Act）还是美国的相关监管框架，都明确要求人类对AI系统的输出承担最终责任。这意味着，即便AI生成了有缺陷的代码并导致系统故障，法律追责的对象依然是使用该工具的开发者或其所在组织。

作为软件开发者，你不仅仅是在执行任务，你要为结果负责。如果你用AI发布了一个严重损害公司利益的功能，AI不会为此负责——你会。你的老板会追究你的责任，你会被解雇。这一点不会改变。

总得有人来承担责任、决定该做什么、检查是否做对了。"责任不可委托性"是AI工具与人类员工之间最根本的结构性差异，也是为什么"AI取代开发者"的叙事在企业治理层面存在根本性漏洞。

基本功才是开发者的核心竞争力

那么，成为一名成功的软件开发者，到底需要什么技能？

博主的答案很简洁：你需要掌握基本功。

只有掌握了基本功，你才能真正为事情负责。就像建房子需要懂木工的基本原理一样，构建软件需要懂软件设计与开发的基本原理。内聚性（Cohesion）、耦合度（Coupling）、抽象（Abstraction）——这些基础设计原则，以及如何将它们实际应用到真实项目中，才是真正重要的东西。

这三个概念是软件工程领域数十年积累的设计智慧。内聚性描述模块内部各元素的关联程度，高内聚意味着一个模块只做一件事并做好它；耦合度描述模块之间的依赖程度，低耦合意味着修改一个模块不会引发连锁反应——这两个概念由拉里·康斯坦丁在1960年代提出，至今仍是评估代码质量的黄金标准。抽象则是管理复杂性的根本手段，通过隐藏实现细节、暴露必要接口，让开发者能够在不同层次上思考问题。这些原则不依赖于任何特定编程语言或框架，是跨越技术代际的底层认知能力。AI可以生成符合这些原则的代码，但判断生成结果是否真正符合这些原则，仍需要开发者具备扎实的理论基础。

这也是他不在频道上过多讨论AI Agent的原因——因为那主要与"写代码"相关，而写代码并不是他认为最有价值的部分。他明确表示不会把频道变成"GPT-5要碾压Gemini"之类的AI炒作频道，而是继续专注于教授那些让你成为优秀开发者的基本功。

理性看待AI：好工具不等于好开发者

值得强调的是，这位博主并不反对AI。他自己也在日常工作中大量使用AI工具。他的核心观点可以概括为一句话：

"用AI提高生产力，让它帮你写代码。但别忘了，你才是负责人。你需要掌握基本功，那才是真正重要的。"

这个观点在当下尤为珍贵。当整个行业都在狂热地追逐AI Agent、Vibe Coding、一键生成应用等概念时——其中Vibe Coding是2024年前后由OpenAI联合创始人安德烈·卡帕西提出的编程范式，其核心是开发者用自然语言描述意图、完全依赖AI生成代码，甚至不阅读、不理解生成的代码内容——我们需要有人站出来提醒：这种方式在个人项目中或许高效，但生成的代码可能包含安全漏洞、性能瓶颈或难以维护的技术债务，而缺乏基本功的开发者往往无从察觉。

技术工具会不断迭代，但对软件设计的深刻理解、对系统架构的全局思考、对业务需求的准确把握——这些"基本功"才是开发者安身立命的根本。当Vibe Coding让"写代码"的门槛趋近于零，真正稀缺的反而是理解代码、评估代码、为代码后果负责的能力。

螺丝刀越来越好用，但世界永远需要真正的木匠。

核心要点

• 快速发布不等于好的软件开发，大型企业更关注风险最小化而非速度
• 写代码只是软件开发的一小部分（约15%~20%），架构设计、需求沟通、创造性解决问题才是核心
• 企业委派的是责任而非任务，AI在现行法律框架下不具备法律人格，无法替代人类承担责任这一关键角色
• 掌握内聚性、耦合度、抽象等软件设计基本功，才是开发者的核心竞争力
• AI是提高生产力的好工具，但不应被炒作为软件开发团队的完全替代品