“会写代码和理解系统怎么运行是两回事，后者不会消失。”

说这句话的人，是Netflix首席产品与技术官Elizabeth Stone。最近，她在Lenny's Podcast里聊了AI、岗位变化和工程团队。

聊的都是开发者绕不开的问题：再过5年、10年，程序员还需要理解代码吗？

AI一进团队，第一个乱掉的就是岗位边界

在Stone看来，很多公司现在正处在一段角色混乱期。

产品经理能让AI写出可运行的原型。设计师可以直接改页面。工程师也能顺手做需求判断。

过去分得很清楚的工作，被Agent挤到了一张桌子上。效率确实提高了，责任边界却开始模糊：原型是谁做的？生产代码由谁把关？出了问题又该找谁？

新技术进入组织后，往往会先经历一段“storming phase”。大家都在试，岗位原有的边界被冲开。混乱会比答案先出现。

她并不反对产品和设计人员用AI写代码。用AI做原型、验证交互、把想法尽快跑起来，当然是好事。可一旦原型要接入真实数据、服务真实用户，还要面对性能、安全、监控和长期维护，工程工作才刚刚开始。

AI让更多人跨进了“能做出来”的门槛。但“能稳定运行”依旧是另一回事。中间隔着大量没人愿意截图发到社交平台的工作。

公司开始招“看得懂全局”的开发者

访谈里，Stone给出了非常明确的判断：AI时代，公司需要更多具备系统思维的人。

Agent一旦开始跨系统工作，麻烦很快就会冒出来。

• 它从哪里取数据？
• 它能调用哪些工具，权限开到什么程度？
• 失败后能不能回滚？
• 多个Agent同时修改同一份状态时，谁来处理冲突？

换一版更强的模型，问题依然存在。Agent跑得越快，缺少边界的系统越容易被它放大。

Stone提到，企业需要把常用能力做成“铺好的路”：统一的身份认证、数据访问、日志、质量检查和安全规则。业务团队不必每次从头搭一遍，Agent也不用在各自的临时方案里乱撞。

落到招聘上，公司会更喜欢能跨过模块边界的人。既能看懂业务，又知道数据怎样流动；既能调用现成平台，也知道什么时候该回到基础设施层处理问题。代码只占其中一部分。这类开发者未必什么都会写，但他能画出系统地图，也知道一次改动会碰到谁。

系统思维不是“什么都懂一点”，而是先把问题放大一格

主持人追问：系统思维听起来很好，可具体怎么练？

Stone的回答是：每碰到一个问题，先把视角向外打开。

比如接到一个接口改造任务，先别急着让Agent开工。多想一想：

• 谁在调用这个接口？
• 数据由谁维护？
• 失败会影响哪条链路？
• 其他团队是不是也在解决同一类问题？

再往后预测：这次改动能不能沉淀成公共能力？监控和回滚放在哪里？半年后另一个团队接手时能否看懂？

Agent只会把局部任务做得又快又完整。它会照着当前仓库里的信息给出一个看似闭合的答案，却不会知道公司其他系统正在发生什么。开发者的作用，恰好在那张没有被放进上下文的地图上。

给Agent派任务之前，可以先补四件事：

• 上游输入
• 下游影响
• 不可触碰的边界
• 验收结果的方式

少写几句漂亮Prompt，多花几分钟把这四项讲清楚，往往更管用。

专业能力没过时，拒绝走出边界才危险

系统思维并不等于每个人都去做“全栈”。编码、视频播放、分布式基础设施等领域，依然需要少数掌握深层技术的专家。变化出现在专家与系统的连接处。

过去，一个人可以只会解决自己熟悉的问题，把相邻问题交给另一个团队。Agent把开发链路压缩以后，这种交接会越来越少。

后端开发者需要理解前端怎样消费数据。业务工程师要知道基础设施给了哪些约束。做模型接入的人也得看得懂成本、缓存和安全策略。

相比5年或10年前，团队会减少非常狭窄的岗位，增加能够沿着问题继续学习的人。这里淘汰的并非“专家”，而是只肯守住一小块知识、又不愿意看上下游的工作方式。

对开发者来说，专业深度仍然值钱。只是深度旁边还要多一条横向的线，把你的技术判断接到产品、系统和其他团队上。

AI熟练度已经写进招聘要求

Stone所在的团队没有给每一级员工单独写一套AI要求，而是把AI熟练度覆盖到所有岗位。

她对“熟练”的定义并不是每天调用多少次模型，也不是收藏了多少提示词。它包括三件事：

• 知道AI适合做什么
• 知道它不该碰什么
• 实际用它完成过工作

这项能力已经被纳入了招聘条件。候选人可以在编程面试里使用AI工具，面试官观察的重点也随之变化：你怎样描述问题？如何把任务拆开？遇到错误会检查什么？模型给出的结果你凭什么相信？

以前的面试把“独立写出答案”当作能力证明。允许使用Agent以后，答案来得更快，判断过程反而更容易暴露。一个人会不会读日志、补测试、质疑模型、缩小故障范围，很难靠工具伪装。

企业采用AI后，招聘不会只筛掉“不会用AI”的人。更大的差距会出现在两类使用者之间：一类把模型当答案机，另一类能把它放进可检查、可回退的工程流程里。

新人少敲的代码，要从哪里补回来

AI让入门开发者少写了很多样板代码，也带来了一个麻烦：过去靠反复实现、调试和踩坑积累的手感，可能还没锻炼出来，任务就已经被Agent做完了。

Stone没有因此得出“公司不再需要新人”的结论。她明确说，团队仍在招聘初级人才，需要改变的是培养方式。

新人可以用AI，但必须学会为结果负责。提交到生产环境的代码是否可靠？产品体验是否符合预期？测试是否覆盖风险？这些责任不会一起交给模型。

导师不能只看功能有没有跑起来。代码审查时要让新人解释为什么这样改，失败路径在哪里，日志能不能定位问题，模型生成的抽象是否真的需要。遇到线上故障，也不能只把错误重新丢回聊天框，而要自己完成诊断。

AI提高了入门效率，却可能抬高独立工作的门槛。过去新人可以通过大量低风险任务逐步熟悉系统，现在这些任务最容易被自动化。企业如果不重新设计训练和审查机制，很可能得到一批产出速度很快、却没见过系统为什么会坏的开发者。

可以少写几行，但别把系统交给黑箱

访谈最后，Stone把“写代码”和“理解代码”分开了。

一种语言的语法和API，可以交给工具处理得越来越多。系统为何这样设计？数据怎样穿过不同服务？故障为什么会扩散？产品表现是否符合预期？这些问题仍然需要人来判断。

她的原话很短：“I don't think the latter is going away.”

AI代码越来越多以后，工程师的工作不会只剩下“验收模型”。需求边界、架构取舍、可观测性、安全、回滚和长期维护，都在等待人做决定。Agent可以把一次实现压缩到几分钟，但系统欠下的债，最后仍会落到团队身上。

用不用AI已经不是问题。模型替你写完第一版内容以后，剩下的工作，是看见它没看到的那部分。