随着 Claude Code 等 AI 编程工具快速普及，软件工程师的工作方式正在发生明显变化。拥有超过 30 年软件开发经验的资深工程师、现任 Zardot 技术长的 Obie Fernandez 近日发表题为《You’re Already a Meat Proxy》的文章，称超过 80% 的软件开发从业人员可能已经面临职涯淘汰，只是很多人还没有意识到这一点。
Fernandez 曾任 Shopify 首席工程师、Andela 技术长，也是软件开发公司 MagmaLabs 的合伙人及技术书作者。他在文中提到，自己此前与一名在大型成功创业公司任职的朋友见面，对方担任 Staff Engineer，所在公司拥有数百名工程师，却已经连续 6 个月向他抱怨，不知道该如何继续推进工作。
工程师已在用 AI，却仍无法推进工作
Fernandez 要求这名朋友打开工作电脑后发现，桌面上已经开着数十个浏览器标签页，以及多个运行 Claude 的终端窗口。面对「既然已经在使用 AI 工具，为什么还是无法推进工作」的追问，这名工程师表示，自己虽然尝试让 Claude 处理问题，却始终没有获得实质进展。
随后，Fernandez 接手操作，把模型切换成他认为更适合协调开发工作的 Fable，并在完全不熟悉项目架构的情况下，输入了一句很简单的提示词：「这份代码很烂，整个架构都乱七八糟。」朋友当场笑了出来，质疑这样笼统的指令能有什么效果。
按 Fernandez 的说法，AI 很快开始检查代码库，并指出了大量技术债，包括测试覆盖不足、数千行代码组成的巨型对象，以及已经没有用途的代码。经过几次确认后，AI 删除了部分无用代码，并生成了一份草稿 Pull Request（PR）。
不过，这名工程师随即要求他停手，解释称自己不能随意修改公司的代码，所有变更都必须先经过团队讨论、提出计划并取得批准。Fernandez 则回应，既然如此，就让 Claude 先写计划。确认 Claude 已通过 MCP 接入 Jira 后，他要求 AI 把原本的修改整理成 Epic 和 Story。AI 随后创建了 5 个 Epic，正准备继续生成相关工作项时，这名工程师却紧张地按下 ESC 中止操作。
Fernandez 最后的判断是，阻碍对方的未必是技术能力，而是他无法接受自己的工作模式正被 AI 改变。文中援引这名工程师的原话称：「但我想用自己的大脑啊！」
「从 L1 到 L7，每个人都在跟 Claude 对话」
Fernandez 在文章中还引用了另一篇在工程师社群引发讨论的帖子。X 用户 @v0xium 表示，自己加入一家大型企业仅半个月，就对当前 AI 驱动的软件开发模式感到失望。
按照这名工程师的描述，团队里从需求规格、代码、测试、产品需求文档（PRD），到 Jira 工单和报告，几乎所有内容都由 Claude Code 生成。管理层并没有因此减少工作量，反而要求工程师加快交付节奏，部分员工甚至每天工作 12 到 13 小时，主要工作却只是不断确认 AI 生成的内容。
这名工程师写道：「没有人真的在阅读任何东西，从 L1 到 L7 的工程师，每个人都在做同样的事：跟 Claude 对话。」在他看来，整个团队正在失去对技术的理解，也越来越缺少亲手解决问题的成就感。
Fernandez 从这段抱怨中看到的是另一层问题：如果工程师原本的价值只是接收任务、按既定流程执行，再把结果交给下一个人，那么这类工作本来就很容易被自动化替代。
什么是「人肉代理」
Fernandez 把这类角色称为「Meat Proxy」，即「人肉代理」。按他的解释，这指的是组织内部负责转换和传递指令的人类工作者。比如主管决定要做什么，工程师把需求转换成代码；或者中层管理者接收高层指示，再把它转化为下属的具体任务。
在传统软件开发流程中，这类角色具有重要价值，因为把商业需求转换成可执行的软件，往往需要大量人力和专业技术。但 Fernandez 认为，当 AI 已经能够理解需求、编写代码、生成测试、整理文档，甚至直接操作 Jira 时，单纯负责转换指令的岗位就会失去原有的经济价值。
他还表示，许多工程师之所以暂时还保有工作，更多是因为企业组织惯性，AI 带来的效率提升尚未完全反映到人力配置上。Fernandez 在文中写道：「目前的 AI 技术已经足以取代所有人肉代理，只是这种程度的颠覆性改变需要时间。」基于这一判断，他认为超过 80% 的软件开发从业者可能已经面临职涯危机。
他称自己约 75% 至 80% 的代码工作已交给 AI Agent
Fernandez 也披露了自己的工作方式，以说明 AI 对资深工程师生产力的影响。他表示，自己当前主要使用 Ruby on Rails 开发新的企业内部系统。由于系统架构设计良好、测试充分，他并不需要逐行检查 AI 生成的全部代码。
过去几个月里，他甚至已经不再直接监督 Claude Code 的具体编写过程，而是把约 75% 至 80% 的代码工作交给自主 AI Agent 处理。只有在增加重要新功能，或进行大规模架构调整时，他才会深入参与实现细节。
按他的说法，这种做法让他可以把更多时间放在更有价值的决策上，包括理解用户需求、判断应该开发哪些功能，以及思考系统怎样才能真正创造实际效益。
不过，Fernandez 也承认，他与前述朋友所处的工作环境并不相同。对方负责的是涉及客户付款的正式运营系统，任何改动都可能带来实际风险，因此逐行审查 AI 修改内容依然有现实必要。
他认为转向架构岗位也未必安全
对于 AI 带来的职业焦虑，Fernandez 反对一种常见建议，即工程师应转型为软件架构师，因为 AI 永远需要人类负责高阶设计。他指出，自己过去 20 多年的核心专业价值之一，就是系统架构和工程判断，但他预计 AI 未来也会逐步接管这些工作。
他提到，像是澄清需求、识别系统边界、建立测试标准，以及判断新架构是否符合原有系统义务，这些能力未必会一直是人类独有。Fernandez 写道：「在组织图上往上移动一格，并不代表你就能置身于这个过程之外。」
在他看来，真正的差异不在职称高低，而在于个人是否愿意主动发现问题、作出判断，并为最终结果负责。不过他也承认，没有人能保证自己具备绝对不会被 AI 取代的能力，包括他自己。
快速产出代码，不等于创造价值
Fernandez 在文章中还谈到，一部分人只是希望拥有稳定且高薪的工作，下班后可以陪家人、旅行或享受生活。他认为这本身没有问题，但也怀疑软件产业未来是否还能持续为所有人提供这种工作模式。
对于希望维持现有生活方式的人，他建议善用 AI 完成工作要求，再把节省下来的时间投入家庭和其他人生选择。至于希望在 AI 时代创造更多价值的工程师，他认为更重要的是主动寻找值得解决的问题，与真正受问题影响的人交流，再借助 AI 做研究、挑战假设并执行方案。
文章结尾，Fernandez 回顾自己当晚替朋友操作 Claude 的经历。虽然只花了约 20 分钟，就产出一份草稿 PR 和多个 Jira Epic，但这并不能证明这些改动真的改善了什么。按他的说法，AI 可以快速生成大量代码，这件事本身并不等于创造价值。真正重要的，仍然是判断哪些问题值得解决，并确认解决方案是否有效。
Fernandez 最后写道：「你不会因为亲自多打几行代码，就比较不像一个人肉代理。」他认为，在 AI 能力持续提升的情况下，工程师与其执着于保留过去的工作方式，不如重新思考自己真正想要什么，以及怎样利用新技术去实现这些目标。他在文末写道：「你真的想继续使用自己的大脑？不想让大脑退化？那就想清楚自己到底想要什么，然后让 Claude 替你工作。」