Dwarkesh在播客里提了个有意思的观点：软件工程可能是唯一一份AI能获得完整工作上下文的职业，因为代码库里什么都有。Dario似乎没能给出令人信服的解释，说明为什么自动化其他工作会同样容易。
这就引出一个略带讽刺的可能：程序员可能是第一批把自己写失业的人，而其他人只是日常工作中无聊的部分被自动化了。
但这个观点立刻遭到了大量反驳。
代码库真的包含了全部上下文吗？实际上远远不够。生产系统依赖基础设施、用户行为模式、SLA、预算约束等大量外部信息。很多技术上完全正确的改动一上线就炸了，就是因为缺失了系统全貌。
还有那些决定"为什么这样写"而不是"怎么写"的上下文：需求在Slack里临时改了，团队口头约定的规范，某个字段是从供应商那份名叫SOURCE_OF_TRUTH_Q4_v3的表格继承来的，而且必须是v3因为v2被实习生搞砸了。代码里有语法，但没有意图。
更关键的区别可能不是上下文完整性，而是验证闭环。你运行代码，几秒钟内就知道对不对。医生没法"编译"一个诊断，律师没法对合同跑单元测试。软件之所以先被自动化，是因为反馈是即时的。
那其他职业呢？
有人指出，律师和会计的上下文理论上也可获取，AI能比任何人更快更深地检索全部案例法。销售工作如果把每通电话都录下来转成文字，配合邮件记录和公开数据，理论上也能复制一个初级销售的工作流程。
区别在于知识的结构化程度。代码天然是结构化的、版本控制的、为机器解析而生的。而大多数工作的上下文散落在邮件、会议、Slack对话、不成文规则里，没有任何一样是机器可读的。这个差距会缩小，但需要时间。
一个务实的视角是：AI不需要完美的上下文才能替代劳动力，只需要"足够"的上下文就能产生经济价值。而且每年都有更多工作流变得机器可读。与其想"哪些工作会被取代"，不如想"哪些工作流会被压缩"。压缩掉40%到60%的工作量，可能就足以重新定价整个职位了。
另一个有意思的动态是：当各行业开始为AI建立技术文档时，员工会意识到自己正在为取代自己做准备。这种张力会如何演化，值得观察。
延伸思考：
Dwarkesh的论点优雅但脆弱。它把一个连续光谱上的问题二值化了——好像上下文要么"完整可得"要么"不可得"。现实是：
每个职业都有一个上下文可编码性的光谱，软件工程确实在最有利的一端，但即便在这一端，代码库也远非"完整上下文"。真正让软件工程率先被自动化的，是上下文可编码性和验证闭环紧密度的双重优势。
而对其他职业来说，瓶颈不在于"上下文能不能数字化"（当然能，给它时间），而在于验证闭环能不能被构建。你可以把所有法律文书数字化，但如果你无法在秒级验证一份合同的质量，AI就很难形成有效的自主工作循环。
最终，这不是一个"软件工程师先失业还是后失业"的问题。这是一个关于每个职业中，哪些工作流同时满足"上下文可编码"和"结果可快速验证"这两个条件的问题。满足的部分会被迅速压缩，不满足的部分会顽强地留存——直到有人找到办法构建新的验证闭环，或者直到AI强大到不再需要验证闭环。
后者才是真正值得担忧的时刻。但那已经是另一个层次的讨论了。
x.com/buccocapital/status/2022782677523345670