加载失败
讨论源自一篇观点：AI 并未真正简化软件工程，而是让糟糕的工程实践更容易大规模复制。HN 评论者从多个角度补充事实与假设：有人强调 AI 把专家的产能放大、能在数日完成原型或功能；也有人指出 AI 将“vibe coding”（依赖快速产出与补丁式修复的写法）在规模上放大，产生技术债和脆弱测试（例如仅验证 mock 返回值）。更深层的争论落在规格与安全不变式上——符合 Sussman effect（将软件视为需反复观测的复杂系统）的观点——并有工程师列举 Opus 4.5/4.6 的失败案例与由 LLM/agent 引发的 outage（如 Sketch 团队的报告）。因此讨论横跨技术限制、生产化审查、团队技能与社会经济影响。
多位评论指出 AI 并非重构工程本质，而是放大现有行为：优秀工程师能借助 AI 在数日内把原本需数周的功能做出来，提高产能；同时糟糕的做法也被规模化，例如大量的 null checks 和只验证 mock 返回值的测试，表面通过却脆弱。有人直接总结“AI 是行为的放大器”，导致代码质量出现极化——既有更快的好成果，也有更多可运行但不可维护的垃圾代码。整体观察是效率提升伴随着质量波动而非统一的简化。
评论普遍认为写代码并非最难的事，难点在于定义全局安全性、时序不变式以及保持系统可理解性，这些需要抽象、经验与明确的规格。有人引用 Sussman effect（把软件看成更接近自然科学的复杂系统）来说明很多问题必须通过观测与迭代解决，而不是由工具自动给出正确答案。多条回复指出大多数开发者连何为充分验证都不清楚，AI 即使能生成代码，也不能替你决定“正确”的规范或什么是足够的设计与测试。
评论警告初级开发者过度依赖 AI 会导致基本功退化——复制粘贴模型输出、不了解原理和系统后果会在长期造成严重代价。有人用钉枪（nail gun）比喻并提到 Dunning‑Kruger 效应：自信的无经验者配上强力工具往往产出更糟的结果。多位有经验的工程师指出，除非有人能预见并理解系统改动的每一寸，否则 AI 生成的改动会带来难以捕捉的故障和累积的技术债。
很多人承认 AI 在探索性研究与快速原型上效率极高——有人称能把试验速度放大十倍，快速验证概念。但随后必须进入传统的软件工程流程：工程师要理解 AI 写的代码、修正明显错误并把原型生产化，审查过程往往更像产品化工作而非纯粹编码。评论里也提到 AI 节省了检索时间（比翻 Stack Overflow 更直接），有助把琐碎工作交给工具，从而让人专注高阶设计。
有具体实例说明模型在小众约束与安全判断上会失败：评论者提到使用 Opus 4.5/4.6 时模型会漂移、无法维持重入安全等精细约束，甚至在被质疑时给出不安全建议。亦有人指出由 LLM/agent 生成的代码已经引发线上中断（如 Sketch 团队的 outage 报告），并列举多家采用 AI 的公司也出现过可观察的故障。总体意见是：即便能通过提示得到某些正确产出，模型幻觉、漂移与运维风险仍是把复杂系统完全交给 AI 的严重障碍。
若 AI 真能在短期内提高产能，评论普遍担忧公司会以此为由裁员，短期生产力提升可能导致长期就业收缩。有人直言这可能朝“消灭中产”方向发展，并质问如果唯一目标是减少岗位，社会如何维持消费与生活成本。讨论还提出角色会自然分化：部分人负责快速原型与验证，另一部分资深工程师负责长期维护与架构，这种分工改变了职业路径与组织策略。
vibe coding: 一种以快速产出和实验为主、缺乏系统性理解的编程风格，常表现为临时补丁（如大量 null checks）和依赖 AI/模板生成代码的复制粘贴做法。
LLM (大型语言模型): 基于海量文本训练用于生成代码与文本的模型。它能加速开发和原型，但因把广泛知识压缩到模型权重，常在小众或安全敏感场景出现幻觉或错误且难以保证长期一致性。
Sussman effect: 一种观点：复杂软件系统更像自然科学对象，需要通过观察与反复实验才能理解其行为，因此纯粹自上而下的设计或自动化生成难以保证整体正确性。
agent（AI agent）: 由 LLM 驱动并可调用工具/API 来完成任务的自动化代理系统。评论中指那些自动串联步骤生成大量代码的代理，存在过度自信、不可预测行为和运维风险（即俗称的“agent go brrr”）。