黑客 vs. 软件工程师：对代理范式的批判

在不断演进的技术领域中，“软件工程师”的定义正在发生变化。对某些人来说，这是一个代表专业声望的头衔；而对另一些人来说，这只是一个企业标签，日益使从业者远离编写代码的实际手艺。

一位资深开发者的最新一篇挑衅性文章探讨了这种身份危机，认为行业向“代理范式”（agentic paradigm）——即 AI agents 编写并管理代码——的冲刺，并非工程学的演进，而是一种背离。

这种紧张关系凸显了一个根本性的分歧：一方是视编程为需要可复现性和推理能力的严谨手艺的人，另一方是优先考虑速度、KPI 和概率性输出而非结构完整性的企业趋势。

手艺的侵蚀

辩论的核心在于“黑客行为”（hacking，在原始的、探索性的意义上）与当前许多企业环境中实践的“软件工程”之间的区别。原文作者认为，尽管他们在几十年前被贴上了“优秀黑客”的标签，但他们从未真正认同自己是软件工程师——尤其是当这个术语开始与缺乏严谨性联系在一起时。

代码中的真正手艺体现在对以下方面的承诺：

• 可读性与可理解性： 确保代码不仅是功能性的，而且对其他人类是可理解的。
• 确定性输出： 相信机器应该针对相同的输入产生相同的输出，从而避免非确定性 AI 生成带来的“流沙”效应。
• 结构完整性： 专注于 Inversion-of-Control、隔离测试，并避免“god objects”或那些为了短期便利而牺牲长期可维护性的混乱实现。

当这些价值观为了“完成任务”而被忽视时，结果往往是一个脆弱且难以推理的系统。作者指出，在许多现代工作场所，担心查询性能或显式接口被视为一种不必要的干扰，而非高质量工作的核心要求。

“代理范式”与 AI 护城河

行业目前正在推动“代理用户流”（agentic user flows）以及将 AI agents 集成到软件开发生命周期（SDLC）的每一个步骤中。其承诺是，手动编写代码最终将变得像 COBOL 一样过时。然而，这种转型引发了重大的技术和哲学担忧。

一个主要的批判点在于接口的性质。用自然语言文本框取代结构化选项，往往会在原本需要精确度的地方引入歧义。此外，依赖具有概率性质的 LLMs 来编写确定性软件，创造了一个根本性的悖论。

除了技术层面，还有一个关于“思维护城河”的更深层次的系统性担忧。随着 AI 领导者讨论“廉价到无法计量的智能”，存在一种风险，即行业并非在增强人类智能，而是在用一个黑盒工具取代解决问题的认知过程。这种转变伴随着关于知识产权窃取和用于训练这些模型的规模化剥削的伦理问题。

社区观点

对这些观点的反应是两极分化的，反映了开发者社区更广泛的分歧。

黑客身份的辩护

一些开发者在“黑客”标签中找到了慰藉，将其视为对他们与技术关系的一种更诚实的描述。对他们来说，编程的乐趣在于重新利用工具并从构建的过程中学习，而不是在企业层级结构中充当“机器中的一颗螺丝钉”。

务实的反驳

相反，有人认为作者的立场是“悲伤贴”（grief-posting）或对完美的理想主义追求。从这个角度来看，客户并不关心 TDD (Test-Driven Development)、SOLID 原则或“优美”的代码；他们关心的是快速交付功能性产品。对于这些务实主义者来说，AI 的概率性本质是一种为了提高速度而值得做的权衡。

专业的定义

关于“工程师”的法律和专业定义出现了一个有趣的侧面。在加拿大等地区，“工程师”是一个受保护的头衔，具有法律责任。这突显了湾区对该术语的随意使用，在那里，该角色的职责很少能反映出传统工程学科中的专业问责制。

结论：黑客如何定位？

随着行业向由 AI agents 主导的未来迈进，人类开发者的角色正在被重新定义。AI 产品工程师可能会更多地接触 AI 自动化，但对于那些“直接上手”（rawdog）代码的人——即确保数字世界基础保持稳定和有理据的内核开发者和库作者——仍然存在着关键需求。

无论一个人称自己为软件工程师还是黑客，核心冲突依然存在：我们是重视思考的过程和手艺的严谨性，还是满足于让机器管理复杂性，而我们只负责管理 KPI？