一种语言的语法和API可以交给工具处理得越来越多。系统为何这样设计数据怎样穿过不同服务故障为什么会扩散产品表现是否符合预期这些问题仍然需要人来判断。“会写代码和理解系统怎么运行是两回事后者不会消失。”说这句话的人是Netflix首席产品与技术官Elizabeth Stone。最近她在Lennys Podcast里聊了AI、岗位变化和工程团队。主持人问了一个开发者绕不开的问题再过5年、10年程序员还需要理解代码吗Stone在意的是另一层能力系统出了问题你能不能判断哪里不对Agent交出一堆代码你知不知道它是否值得上线业务、数据、权限和基础设施缠在一起时你能不能找到真正需要动的那一层。AI写代码的速度越来越快公司挑人的尺子也在跟着变。以下内容根据访谈翻译整理。AI进入团队最先乱掉的是岗位边界在Stone看来很多公司现在正处在一段角色混乱期。产品经理能让AI写出可运行的原型设计师可以直接改页面工程师也能顺手做需求判断。过去分得很清楚的工作被Agent挤到了一张桌子上。效率确实提高了责任边界却开始模糊原型是谁做的生产代码由谁把关出了问题又该找谁Stone新技术进入组织后往往会先经历一段“storming phase”。大家都在试岗位原有的边界被冲开混乱会比答案先出现。她并不反对产品和设计人员用AI写代码。用AI做原型、验证交互、把想法尽快跑起来当然是好事。可一旦原型要接入真实数据、服务真实用户还要面对性能、安全、监控和长期维护工程工作才刚刚开始。AI让更多人跨进了“能做出来”的门槛。“能稳定运行”依旧是另一回事中间隔着大量没人愿意截图发到社交平台的工作。公司开始招“看得懂全局”的开发者访谈里Stone给出了非常明确的判断“We need more systems thinkers in a world with AI.”AI时代公司需要更多具备系统思维的人。公司开始找系统思维Agent一旦开始跨系统工作麻烦很快就会冒出来。它从哪里取数据它能调用哪些工具权限开到什么程度失败后能不能回滚多个Agent同时修改同一份状态时谁来处理冲突换一版更强的模型问题依然存在。Agent跑得越快缺少边界的系统越容易被它放大。Stone提到企业需要把常用能力做成“铺好的路”统一的身份认证、数据访问、日志、质量检查和安全规则。业务团队不必每次从头搭一遍Agent也不用在各自的临时方案里乱撞。落到招聘上公司会更喜欢能跨过模块边界的人。既能看懂业务又知道数据怎样流动既能调用现成平台也知道什么时候该回到基础设施层处理问题。代码只占其中一部分。这类开发者未必什么都会写但他能画出系统地图也知道一次改动会碰到谁。系统思维不是“什么都懂一点”先把问题放大一格主持人追问系统思维听起来很好可具体怎么练“Each problem youre trying to solve, step out one click.”Stone每碰到一个问题先把视角向外打开。Stone给出训练系统思维的方法比如接到一个接口改造任务先别急着让Agent开工。多想一想谁在调用这个接口数据由谁维护失败会影响哪条链路其他团队是不是也在解决同一类问题。再往后预测这次改动能不能沉淀成公共能力监控和回滚放在哪里半年后另一个团队接手时能否看懂。Agent就会把局部任务做得又快又完整。它会照着当前仓库里的信息给出一个看似闭合的答案却不会知道公司其他系统正在发生什么。开发者的作用恰好在那张没有被放进上下文的地图上。给Agent派任务之前可以先补四件事上游输入、下游影响、不可触碰的边界以及验收结果的方式。少写几句漂亮Prompt多花几分钟把这四项讲清楚往往更管用。专业能力没过时拒绝走出边界才危险系统思维并不等于每个人都去做“全栈”。Stone编码、视频播放、分布式基础设施等领域依然需要少数掌握深层技术的专家。变化出现在专家与系统的连接处。Stone谈专家与通才的变化过去一个人可以只会解决自己熟悉的问题把相邻问题交给另一个团队。Agent把开发链路压缩以后这种交接会越来越少。后端开发者需要理解前端怎样消费数据业务工程师要知道基础设施给了哪些约束做模型接入的人也得看得懂成本、缓存和安全策略。Stone相比5年或10年前团队会减少非常狭窄的岗位增加能够沿着问题继续学习的人。这里淘汰的并非“专家”而是只肯守住一小块知识、又不愿意看上下游的工作方式。对开发者来说专业深度仍然值钱。只是深度旁边还要多一条横向的线把你的技术判断接到产品、系统和其他团队上。AI熟练度已经写进招聘要求Stone所在的团队没有给每一级员工单独写一套AI要求而是把AI熟练度覆盖到所有岗位。她对“熟练”的定义并不是每天调用多少次模型也不是收藏了多少提示词。它包括三件事知道AI适合做什么知道它不该碰什么实际用它完成过工作。Stone谈AI熟练度与招聘要求这项能力已经被纳入了招聘条件。候选人可以在编程面试里使用AI工具面试官观察的重点也随之变化你怎样描述问题如何把任务拆开遇到错误会检查什么模型给出的结果你凭什么相信。以前的面试把“独立写出答案”当作能力证明。允许使用Agent以后答案来得更快判断过程反而更容易暴露。一个人会不会读日志、补测试、质疑模型、缩小故障范围很难靠工具伪装。企业采用AI后招聘不会只筛掉“不会用AI”的人。更大的差距会出现在两类使用者之间一类把模型当答案机另一类能把它放进可检查、可回退的工程流程里。新人少敲的代码要从哪里补回来AI让入门开发者少写了很多样板代码也带来了一个麻烦过去靠反复实现、调试和踩坑积累的手感可能还没锻炼出来任务就已经被Agent做完了。Stone没有因此得出“公司不再需要新人”的结论。她明确说团队仍在招聘初级人才需要改变的是培养方式。Stone谈代码质量和结果责任新人可以用AI但必须学会为结果负责。提交到生产环境的代码是否可靠产品体验是否符合预期测试是否覆盖风险这些责任不会一起交给模型。导师不能只看功能有没有跑起来。代码审查时要让新人解释为什么这样改失败路径在哪里日志能不能定位问题模型生成的抽象是否真的需要。遇到线上故障也不能只把错误重新丢回聊天框而要自己完成诊断。AI提高了入门效率却可能抬高独立工作的门槛。过去新人可以通过大量低风险任务逐步熟悉系统现在这些任务最容易被自动化。企业如果不重新设计训练和审查机制很可能得到一批产出速度很快、却没见过系统为什么会坏的开发者。可以少写几行但别把系统交给黑箱访谈最后Stone把“写代码”和“理解代码”分开了。Stone谈未来5到10年的工程能力一种语言的语法和API可以交给工具处理得越来越多。系统为何这样设计数据怎样穿过不同服务故障为什么会扩散产品表现是否符合预期这些问题仍然需要人来判断。她的原话很短“I dont think the latter is going away.”AI代码越来越多以后工程师的工作不会只剩下“验收模型”。需求边界、架构取舍、可观测性、安全、回滚和长期维护都在等待人做决定。Agent可以把一次实现压缩到几分钟但系统欠下的债最后仍会落到团队身上。用不用AI已经不是问题。模型替你写完第一版内容以后剩下的工作是看见它没看到的那部分。