文章批评当前软件行业错误认为AI可以取代软件工程师，指出AI虽能快速生成代码，但无法替代系统设计、规范制定等核心工程能力。行业正盲目裁员并弱化工程专业价值，实则是借AI掩盖商业决策失误。作者认为AI只是让低劣工程更容易，而非简化真正复杂的软件开发工作。

人工智能并未简化软件工程：它只是让劣质工程更容易了

当前软件行业正竭力自我催眠，声称软件工程已不再必要。但我要大声疾呼：这纯属无稽之谈！

大型语言模型确实能编写代码，有时确实节省时间。与其在Stack Overflow上搜索，不如直接输入描述快速生成代码。有时它能准确无误，但更多时候并非如此。然而，整个行业似乎认定软件开发已被简化到不再需要专业知识的程度——既然代码可以按需生成，那难题应该都解决了吧？架构设计、规范制定、严谨验证这些难道都成了过时的老古董？简直荒谬。

在某些企业，这种论调甚至未经审慎探讨就直接影响了决策。大批工程师被裁撤，理由竟是AI进步使得专业技能变得多余。事实上，AI不过是企业用来掩饰错误商业决策或市场压力的最新借口。

构建复杂系统所需的工程纪律正在被全盘抛弃。用AI提示词取代软件工程规范的做法日益盛行。这种趋势让我产生强烈的既视感——在这个行业摸爬滚打四十余年，我见证过太多类似的轮回。工具在变，说辞在变，但结局从未改变。

飞机维修的启示 现代飞机是极端复杂的系统，商用客机包含数百万零件和数千个互连子系统。诊断问题绝非简单执行检查清单，而是需要经验、判断力和对系统实际运行状态的深刻理解。即便拥有先进工具和数字手册，也没有航空公司会认为可以裁撤专业机械师，让登机口工作人员兼任维修。

然而软件行业正在上演类似的荒诞剧。我们真能就此摆脱那些"烦人"的软件开发者吗？

业余与专业的鸿沟 必须明确区分业余爱好与专业开发。个人小项目值得鼓励，许多创新正源于此。但专业软件关乎支付系统、敏感数据、关键基础设施，用户理所当然期待其正确可靠地持续运行——这正是专业工程的基本要求，也是纪律与专业知识不可替代的原因。

代码从来不是难点 软件开发最大的误解就是认为写代码是最困难的部分。决定系统行为、组件交互方式、保持系统可维护性才是真正的工程难题。AI加速代码生产反而可能加剧"规范漂移"（spec drift）——当代码、测试与设计规范逐渐脱节，系统终将变得无人真正理解。

历史重演 1990年代Visual Basic也曾号称"全民编程"，但最终证明：产出软件部件≠构建可靠系统。如今语言模型不过是将门槛从应用开发降到了代码生成层面，但专业工程的需求从未改变。

AI的正确打开方式 语言模型真正的价值在于辅助工程师探索设计、生成草案，而非取代工程纪律。下一代工具的挑战在于：如何在保持对话式创新的同时，不丢失复杂系统所需的严谨性。

专业软件仍需要真正懂系统的工程师。我们可以善用这些工具，但绝不能将其神化。毕竟，工具再强大，也无法替代人类工程师的专业判断。

以下是评论内容的总结，涵盖主要观点和论据，并保持不同观点的平衡性：

1. AI作为效率工具

• 观点：AI提高了开发效率，加速了编码过程，但并未解决工程中的核心难题。
  • 引用：
    "It’s not simpler. It’s faster and cheaper and more consistent in quality. But way more complex." (sunir)
    "AI has mostly helped me ship trivial features that I’d normally have to backburner." (staticassertion)

2. 代码并非难点

• 观点：编码本身并非软件开发中最困难的部分，系统设计和理解需求才是关键。
  • 引用：
    "Coding was never the hard part. Typing syntax into a machine has always been the least interesting part." (avoidsky)
    "Code took time, but it was never the hard part." (staticassertion)

3. AI的局限性

• 观点：AI在复杂或专业性强的任务中表现不佳，尤其是需要深度经验或安全性的场景。
  • 引用：
    "The model was Opus 4.5... it would often put something in there that wasn’t safe." (staticassertion)
    "AI is trained on massive amounts of data... it can not state things it has not seen." (staticassertion)

4. 对工程质量的担忧

• 观点：AI可能助长低质量代码的泛滥，尤其是缺乏经验的开发者过度依赖AI时。
  • 引用：
    "A confident AI and an unskilled human are just a Dunning-Kruger multiplier." (zer00eyz)
    "Juniors relying too heavily on AI will pay the price down the line." (jazz9k)

5. 行业影响与未来展望

• 观点：AI可能改变开发者的角色，但不会完全取代人类工程师。
  • 引用：
    "AI is not going anywhere, just like cars, electricity and airplanes." (water_badger)
    "The engineering role has shifted... Rebuilding that delivery pipeline is the challenge." (jwilliams)

6. 工具的双刃剑效应

• 观点：AI的价值取决于使用者的能力，优秀工程师能更高效，而新手可能更易犯错。
  • 引用：
    "Put a bad driver in an F1 car and you won’t make them a racer." (pdp)
    "Technology was never equaliser. It just divides more." (pdp)

7. 时间与资源的重新分配

• 观点：AI节省的时间可用于更重要的工程或探索性工作。
  • 引用：
    "AI allows to prototype near to anything in short terms which is superb." (artyprof)
    "AI not only enables something you just could not afford doing in the past." (segasai)

关键争议点：

• 支持方：AI加速开发，降低重复劳动成本（如tyleo、arty_prof）。
• 反对方：AI无法替代人类判断，可能引入风险（如staticassertion、rvz）。
• 中立方：AI是工具，效果取决于使用方式（如yubainu、MatrixMan）。

总结：评论普遍认可AI的效率提升，但对其在复杂任务、安全性和行业长期影响上持谨慎态度。核心矛盾集中在AI是否真正“简化”工程，还是仅掩盖了更深层的问题。