那些曾经糟糕的软件工程理念，如今却行得通了
Bad ideas that aren't bad anymore
我在软件行业摸爬滚打十五年，积累的经验曾是我判断方案优劣的准绳。但最近，我依赖的直觉频频失灵，许多过去被视为禁忌的“坏主意”如今却效果惊人。比如，我们取消了同事间的代码审查，转而由工程师直接审查 Claude 生成的代码，效率反而大幅提升；团队也不再强求所有人协同同一任务，而是允许分拆独立工作流，因为 AI 让上下文切换的成本几乎归零。我也开始建议工程师不必在单一技术上钻得太深，因为 AI 已能瞬间调取所有源码知识，真正的价值转向了架构设计、产品思维与用户洞察。这些变化让我意识到，当技术成本被 AI 重构，许多旧规则已不再适用。
上下文切换的成本已大幅下降，因为我们现在在比过去更高的层级上运作。
HN 评论区
68- sn
我是首席工程师。对于生产环境的软件，代码审查依然至关重要。
也许你觉得我没能紧跟“氛围编程”的潮流，或者认为如果我能更好地利用 AI，就不需要代码审查了。我不同意——无论是工程师还是大语言模型（LLM），依然会引入不必要的复杂性，或者选择错误的抽象方式，从而在未来埋下隐患；它们往往忽略各种边界情况，对错误条件的处理也不当。它们会加入一些自认为不错的主意，却偏离了规范。
如果我的公司停止对关键软件进行代码审查，我会辞职。
那些不处于创业冲刺期的工程师，应该致力于利用大语言模型写出更好的代码，而不是更快的代码。只求速度只会制造技术债务，增加长期成本。
- ro_sharp
为什么这么多人认为代码审查主要是出于不信任或是为了挑错？
在我看来，代码审查的核心在于确保共识和理解，这不仅关乎当前的变更，更关乎未来的演进。
- kbiessy
我想谈谈这个列表中我最熟悉的一项。“自建而非购买”是我唯一会质疑的观点。
编写工具的成本确实基本消失了，这点我同意。但拥有它的成本，我觉得并没有太大变化。如果看看我负责的几个小型公司的软件栈，那些自定义工具往往最终造成的伤害最大。没人记得它是自制的，直到 API 调用失败，或者当初开发它的人离职了。我认为维护成本尤其高昂。
花一个下午构建出来的东西，既无法解决长期的维护问题，也无法提供功能层面的知识。我认为通才可以从 AI 中获益良多，但在未来，专家在指导和维护软件方面仍将发挥巨大作用。
- xg15
这些不同例子背后的共同主题似乎是：“以前，我们必须小心地让每位团队成员积累对我们代码库的经验和专业知识，避免形成知识孤岛。现在这些都不重要了，因为每个人都可以直接问 Claude 来解释一切。”
说实话，我对此不太确定。短期内，这确实行得通。但长期来看，这或许就像你拥有了一些极好的书籍，却对该事物毫无动手经验。我们都知道，书本知识与实践经验是两码事。
- ahartmetz
> 引入团队里没人懂的语言或工具 [不再是个坏主意]
好吧，现在我确信这家伙满嘴跑火车。