AI 生成代码，但工程师负责权衡
Software engineering is about managing complexity
AI 让写代码变得极其廉价，但这恰恰掩盖了软件工程的本质：管理复杂性。写代码只是将想法转化为指令，而构建软件则意味着在无数约束中做出权衡——从同步还是异步处理，到强一致性与最终一致性的取舍。AI 可以生成方案，但无法理解业务背景、团队技能或历史遗留问题。真正的工程判断在于决定哪里该引入复杂性，哪里该保持简单。当代码行变得便宜，理解系统却愈发昂贵，工程师的核心价值不再是敲代码，而是拥有对权衡的掌控力。
工程在很大程度上是一门决定你愿意拥有哪些问题的学科。
HN 评论区
83- zug_zug
关于复杂性的那些讨论完全正确。
不过，我认为像“工程师掌握权衡”这样的说法是在夸大人类工程师实际做的事情。根据我的经验，肯定有一半以上的在职软件工程师根本不会认真分析这类问题：
“考虑到这些约束条件、这个团队、这家企业、这套基础设施、这笔预算、这些风险以及产品的预期演进，今天实现 X 的最佳方式是什么？”
因此，我认为 AI 取代普通工程师的能力比这篇文章承认的还要强；然而，“普通工程”的不足现在将暴露无遗：代码库现在可能在几个月内就变得庞大复杂到难以驾驭，而过去这需要五年时间（在这个时间尺度上，追责实际上是不可能的）。
- cobbal
第一条假设就让我无法认同。人们可以争论 AI 有多大用处，但显然它并非不可或缺，因为几年前我们 somehow 在没有它的情况下也写出了代码。我甚至要说，那时的代码质量更好。
写代码和软件工程这两项任务如果割裂开来，就会损害工程师心智模型的完整性。那些不与代码互动的架构师，总是导致地图与实地不符（map/territory mismatches）。
- a2ff6eeb0
AI 也可以根据你的需求生成架构，并提出必要的澄清问题。
它在系统设计方面目前还比不上写代码，但感觉已经比我大多数同事强了。
我觉得再过几个月，系统架构也会迎来它的 Claude Code 时刻，届时人类将被超越。
- wyum
软件复杂性随着组件的增加呈超线性甚至指数级增长。
工程师确实可以采取一些措施来压低这条曲线——也就是 OP 提到的复杂性管理思路——但只要你在不断往软件里添加东西，复杂性的增长就永远不可能是线性的。
我在 X 上发过一个关于这个的模型/定理：https://x.com/i/status/2027771813346820349
代码生成暴露了验证才是软件工程的核心问题。我认为它一直都是。
定义什么是“正确”本身就很难，更不用说构建一个易于验证的系统，或者花时间去验证了。因此，发布软件并让用户发现 bug 是一种非常高效的策略，因为它分担了负担。但你必须在流失用户和获得足够反馈以发现并修复关键 bug 之间走钢丝。
当我们面对 AI 是否会取代我们工作时，我有一点安慰：世界可能过于复杂，以至于即使是我们能想象到的最大、训练最好的 AI 也无法应对。到了某个阶段，你需要模拟整个世界（或其相当大的一部分），而用算力去做这一切的成本效益，可能还不如利用现实世界（也就是人类）作为验证者。
- softwaredoug
有时候，这些权衡只涉及几行代码中的半打决策。这正是我不愿让 Agent 插手的地方。它能写出正确的代码，你也可以在一定程度上约束它去考虑另一件事。但它容易分心、忽略约束、耍小聪明，那你是要叠加更多复杂性来防止这种情况发生，还是直接看十几行代码来手动修复？