AI 让弱工程师的危害变小AI makes weak engineers less harmful
软件工程能力分布呈强长尾特征，顶尖工程师产出远超平均水平，而最弱的工程师则常带来净负面影响。AI 工具通过自动化重复性任务、提供代码审查和建议，显著降低了弱工程师造成的错误和延误。文章认为，AI 并非取代人类工程师，而是通过赋能，使弱工程师能贡献更多，同时减轻团队负担。
和其他类型的解谜活动一样，软件工程能力也呈现出强烈的长尾分布。最优秀的工程师产出远超平均水平，而最差的工程师往往不仅毫无贡献，反而会制造问题，让同事不得不耗费时间解决。正因如此，许多科技公司选择组建小而高薪的团队，而非由普通工程师组成的大团队，而且目前看来这种策略确实奏效。
在大型科技公司中，高效运作的关键往往在于管理这种能力差异：设法让最有能力的人负责你希望成功的项目，同时把能力最弱的人排除在外。例如，如果你是一个项目的技术负责人，就必须确保最关键的部分由不会搞砸的人来负责——无论是直接分配任务，还是安排能“随时监督”你担心出问题的工程师。
Claude Code 改变了这一局面。前沿大语言模型虽然缺乏优秀工程师的品味和对系统的熟悉度，但它们显著提升了低水平工程师的下限。如今你看到的拉取请求，最差也就是一个标准的 LLM 生成的 PR：在某些方面出错，另一些地方令人困惑，但至少逐行来看是功能正常的，而且不会明显错误到连不了解代码库的人都能一眼看出问题。这已经是巨大的进步！
你可以亲自验证这一点。如果你故意在与编码代理合作时制造明显错误（比如用非用户专属的键缓存用户数据、编写可能永不终止的无限循环，或泄漏未关闭的文件），会发现代理会强烈抵制这些低级错误。当然，它仍可能遗漏那些需要理解整个代码库上下文的微妙错误。
现在与效率最低的工程师合作，有时就像通过 Slack 与 Claude Opus 或 Codex 这样的实例交流一样。偶尔甚至就是如此：你的同事只是把你的消息粘贴进 Claude Code，再把回复粘贴回来。这很烦人，但比起直接和这类工程师共事，体验已经好太多了。毕竟，你可能本来就在和各种 LLM 实例打交道。Slack 界面虽不理想——不像直接使用 Claude Code 那样能即时响应，也看不到代理的思考过程，有时甚至要等上几小时或几天——但总体上仍有帮助。多投入算力总比少投入强。
当然，对那位工程师而言，这种情况并不理想，因为他们几乎学不到东西，远不如自己做出（哪怕糟糕）的决定来得有益。对公司来说也不是好事——他们付着人类员工的薪水，却只换来一个 Copilot 订阅（很可能还要额外付费购买）。在搞清楚 AI 为工程师带来了多少价值之后，我怀疑接下来会转向研究：工程师能为 AI 带来什么价值？而那些无法创造价值的工程师，恐怕最终会面临失业。
你不能像对待普通 Claude 那样通过 Slack 与 Claude 交流。如果你习惯粗暴地对待大语言模型（比如辱骂它们，或者表现得非常敷衍），就必须改变沟通方式。毕竟，即使你是在和 LLM 交互，人类也会阅读你的消息。不礼貌毫无意义。但如果你像我一样，对模型使用“请”和“谢谢”，那么你可以把使用 LLM 的同事当作另一个 Copilot 窗口或 Codex 标签页来对待。这远比把他们当成无意识的破坏者要好得多。
并非所有净负工程师都会这样使用 AI 工具。许多人坚信自己关于如何构建优质软件的错误观点，或对 AI 普遍不信任，或认为过度依赖 LLM 并不是提升的有效途径。但强大的工程师绝不会这样使用 AI 工具。即使他们偶尔偷懒或粗心，一个有能力的工程师也具备足够的判断力来发现明显的 AI 生成错误。因此，工程师群体中“围绕 Claude Code 形成薄薄一层外壳”的现象，仅限于那些认为这种方式能改善其工作产出的工程师类型。
如果你喜欢这篇文章，欢迎订阅我的邮件更新以获取新帖通知，或在 Hacker News 上分享它。
这里有一篇相关预告文章，包含与此文相同的标签。
工程师确实会因为编写简单代码而获得晋升。这是软件工程师圈子里的一个常见笑话：编写过度复杂、难以维护的代码反而能带来职位安全。毕竟，如果整个系统只有你能维护，公司就无法解雇你。还有一种说法是“没人会因为简洁性获得晋升”——换句话说，那些交付了过度复杂垃圾代码的工程师反而会被提拔，因为他们的成果在不懂技术的管理者眼中显得更具“技术含量”。继续阅读全文……
需要完整排版与评论请前往来源站点阅读。