只会写代码的人不够用了！Netflix CPTO谈程序员未来十年：会写代码和“理解系统”是两回事

（来源：51CTO技术栈）

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

说这句话的人，是Netflix首席产品与技术官Elizabeth Stone。

最近，她在Lenny's 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时代，公司需要更多具备系统思维的人。

Stone谈AI时代的招聘变化

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

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

换一版更强的模型，问题依然存在。

Agent跑得越快，缺少边界的系统越容易被它放大。

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

落到招聘上，公司会更喜欢能跨过模块边界的人。既能看懂业务，又知道数据怎样流动；既能调用现成平台，也知道什么时候该回到基础设施层处理问题。代码只占其中一部分。

这类开发者未必什么都会写，但他能画出系统地图，也知道一次改动会碰到谁。

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

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

“Each problem you're trying to solve, step out one click.”

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

Stone给出训练系统思维的方法

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

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

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

Agent就会把局部任务做得又快又完整。

它会照着当前仓库里的信息给出一个看似闭合的答案，却不会知道公司其他系统正在发生什么。

开发者的作用，恰好在那张没有被放进上下文的地图上。

给Agent派任务之前，可以先补四件事：上游输入、下游影响、不可触碰的边界，以及验收结果的方式。少写几句漂亮Prompt，多花几分钟把这四项讲清楚，往往更管用。

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

系统思维并不等于每个人都去做“全栈”。

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 don't think the latter is going away.”

AI代码越来越多以后，工程师的工作不会只剩下“验收模型”。

需求边界、架构取舍、可观测性、安全、回滚和长期维护，都在等待人做决定。Agent可以把一次实现压缩到几分钟，但系统欠下的债，最后仍会落到团队身上。

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

相关推荐

AI都会写代码了，软件工程师如何才能避免被商品化？
“行业毒瘤”低代码
半年不写代码，Claude Code之父：3年后写代码的人暴涨100倍
请别造新词了，未来不会有什么Prompt工程师
AI 写了 90% 代码，大厂程序员的煎熬时刻
程序员门槛再被“神器”降低：只要会英文，就能写代码
天网是用COBOL写的？1984年《终结者》竟然用了他的代码
当AI会写代码，新一代学生还要学编程吗？
低代码解放程序员？子弹还得飞一会儿
低代码，抢不动程序员的饭碗

网址: 只会写代码的人不够用了！Netflix CPTO谈程序员未来十年：会写代码和“理解系统”是两回事 https://www.xishuta.cn/newsview151762.html