别自称手工程序员，那是对工程师的贬低
Don't call yourself an artisanal programmer
我注意到软件行业正在经历一场危险的术语重构：那些拒绝使用 LLM、坚持手动编写可靠代码的人，被贴上“手工程序员”的标签，仿佛这是一种不务正业的爱好；而依赖 AI 生成代码的“vibecoding”却被视为唯一理性的工程实践。这种二分法不仅混淆了概念，更在潜意识中剥夺了严谨开发者的工程师身份。真正的工程精神在于对细节的把控和对可靠性的追求，而非盲目追求速度。我们不应接受这种反智的叙事，而应重新夺回“软件工程师”的定义权，让 AI-free software engineering 在公共讨论中占据应有的位置，捍卫我们作为专业人士的尊严与价值。
软件工程师是真正的工程师，但许多编写软件的人并没有在做软件工程师的工作。
HN 评论区
58- cortesoft
奇怪的是，我原本以为这两个词的定义应该是反过来的……在我看来，工匠（craftsman）是那些重质量轻数量、致力于让每件作品都精美耐用的人；而工程师（engineer）则更关注生产力、公差和效率。工匠能做出质量更好的东西，但无法像工程师和工厂流水线那样实现规模化，尽管大规模生产往往是以牺牲质量为代价来换取数量。
- jlamberts
工程的核心在于在一系列约束条件下创造出能实现特定目的的东西。这其中就包括认识到“在所有情况下都 100% 正确/可靠”是一个不切实际的目标，因为实现时间和成本本身就是约束条件之一。
优秀的工程师会承认这种鲁棒性与成本之间的权衡，并据此行事。例如，如果你正在开发安全关键型系统或非常基础的系统（如操作系统、医疗技术等），你应该极度偏向鲁棒性。如果不是这种情况，这种做法很容易沦为过度设计。工程师的工作就是为他们正在构建的事物，在“成本 - 正确性”曲线上找到那个合适的平衡点。
这一直如此，大语言模型（LLMs）只是改变了方程中的某些部分。例如，编写代码的瓶颈已远不如以前那么严重，因此“我们可以先写个一次性实现试试看行不行”突然在经济上变得可行。事实证明，在实践中，许多东西并不需要像我们某些人曾经认为的那样正确。
我们依然可以享受制作高质量事物的过程，但这往往属于工艺（artisanship）的范畴，而非工程。
- barrkel
很大一部分工程工作，是用不可靠的组件构建出可靠的系统。
你需要构建 safeguards（防护措施）、冗余、纵深防御和恢复系统。你需要建立系统模型并证明其特性。
软件本质上是自动化。LLMs 使得软件本身的构建过程也能实现自动化。它们比人类更快、更便宜，但也更不可靠。（人类本身也是不可靠的！）
当下的直接挑战在于，如何在大范围内、长期地、可靠地构建出可靠的软件。这是一个工程挑战，我们要跨越这道坎，唯一的办法就是去尝试。过程会很艰难，会出现技术上的寒武纪大爆发，大多数方法都会失败，随着模型质量和能力的提升，更多方法将无法生存。但我们会找到解决办法的。
手工打造事物，就像在智能体编程（agentic coding）时代之前那样，也可以算是工程，但它不是这个时代的核心挑战，很快它就会变成一种爱好，或者某种奢侈品。你绝不会想要手写软件，就像你不会想要手工制造的汽车一样。它将不具备机器制造软件所具有的精度、性能或可靠性。
- tibbar
我更喜欢用“受过经典训练的程序员”这个说法。:-)
- spawrks
代码所做的事情和代码本身之间，难道没有区别吗？我见过真正精美的软件，其代码虽难以阅读却行之有效；我也见过代码本身极其优美、技术上令人惊叹，却毫无实质产出的软件。软件就像木工活，它涵盖了各个层面的用心程度和最终的产品成果。