技术工作的商品化失败
把软件开发变成流水线式商品的尝试，始终会撞上复杂系统、不断变化的需求以及创造性问题求解这一现实。评论者指出，许多底层任务和工具（从邮件合并到云基础设施）已经成功标准化，但这主要只是把剩余工作推到了更高层，而在那一层，领域理解、判断力和清晰需求显得更加重要。于是便形成了紧张关系：管理者追求可预测性和即插即用方案，而从业者则认为，把程序员、数据工作，甚至医疗实践当作可互换的工厂劳动力，往往只会带来脆弱的系统、失败的项目，以及隐藏起来的“杂务”，而不是真正的效率。
技术工作的商品化的范围与边界
- 许多评论者同意某些“技术工作”已经成功商品化：邮件合并、基础记账、简单网站、所见即所得编辑、托管电子邮件等。
- 共识是，剩余的工作与其说是连接各个库，不如说更多关乎需求、设计和领域理解，而这些更难标准化。
- 一些人认为，商品化的低垂果实大多已经摘完；进一步抽象只会把问题推到更高层，并增加对专家的需求。
杂务、复杂性与新角色
- 有人预期自动化会减少杂务；也有人认为，杂务总量大致保持不变甚至增长，只是转移到了新层次（DevOps、SRE、Cloud*、数据角色、大型组织中的人工运维）。
- 新技术既自动化了旧任务，也制造了新的例行任务和集成负担。
低代码、SaaS 与 SQL 抽象的怀疑
- 对那些声称“无需编程”的工具持强烈怀疑，尤其是 SQL 抽象层和 BI 拖拽式工具。
- 常见模式是：抽象在简单场景下有用，但在非标准需求上会泄漏复杂性，迫使专家回到底层技术。
- 一些人指出，某些 SaaS 产品至今并未解决真实客户问题，而是把早期采用者的用例当作免费的研发。
AI 工具与学习
- AI 编程工具常被拿来与低代码类比：它们可以生成样板代码，但并不能消除对问题界定和集成的需求。
- 有几位评论者表示，AI 生成的代码会引用不存在的包，或轻描淡写地掩盖困难部分。
- 还有人担心，AI 的广泛使用可能通过鼓励“复制答案”而非理解，削弱初级开发者的学习。
工厂 vs. 手艺：流程之争
- 一派强调编程是一门类似定制木工的手艺：最好通过学徒制学习，不适合完全按泰勒主义“工厂化”处理。
- 另一派指出，软件工作的某些部分是可重复的，应当像生产一样系统化、标准化并加以管理。
- Phoenix Project / Scrum / Agile 实践引发激烈争论：有人认为它们是对可重复工作的有用轻量结构；也有人把它们看作去人性化、表演化的官僚主义，忽视了大多数开发在本质上具有探索性。
管理、工具与组织性债务
- 一个反复出现的主题是：领导层把复杂的软件和组织问题当作购买电器来处理（Workday、EMR、CRM、ServiceNow），低估了定制、维护和领域建模的难度。
- 组织结构本身被描述为一种技术债务，任何工具都无法修复；业务预期与软件现实之间的不一致推动了许多失败。