卡兹克这篇文章,有点放大FDE们的能力了。
事实上大部分FDE并不具备管理大型项目的能力,也没有相关经验,可能也包括卡兹克自己。
企业对FDE的定位,现在主要还是非全栈FDE,就是那种没法独立从零搭出一套完整系统的人,而非那种既懂架构又能落地的全栈型。
大多企业对非全栈FDE的岗位需求,其实就两样。
一是售前加项目经理,二是AI培训老师。
而这两项工作其实是割裂的,甚至互相矛盾,本质上属于两个岗位。
做第一项的,企业对他的潜在预期其实是一个懂业务的CTO。既要有系统架构师的程序能力,也要有CPO的产品能力。
这对偏年轻化、大型项目经验不足的FDE们来说,未免太强人所难了。所以往往按第一项岗位需求招进来的,做着做着就莫名其妙成了专职培训师,或者被边缘化了。
这就不得不说企业里一个重大的权力:定需求。
有这个权力的人,不但有汇报权,也有权支配整个公司的开发资源。这一般是CTO和CPO的活儿。
而一个FDE招进来,本身就肩负着"优化效率和人员支出"的责任,还要介入定需求——天生就是抢别人饭碗、争开发部门最大话语权的。
所以如果他的能力(加上AI)做不到对原有负责人们的碾压,或者输在办公室政治,那只有靠边站。
这其实不完全是FDE个人能力的问题,也是企业权力结构的问题。
成熟的体系是有解法的。Palantir用的是Delta加Echo的双人模式,Delta负责技术搭建,Echo负责组织对齐和摆平各方利益。也就是说权力博弈是被显性拆开处理的,不是让一个FDE靠自己去宫斗。
大多数公司没这套机制,FDE只能单打独斗。这大概也解释了,为什么文中的FDE那么狼狈。
全栈FDE处境会好一些,但门槛其实很高。
我认识的很多以前做运营、售前、设计这类非产品非开发岗的人,在用agent独立完成几个项目并上线之后,往往自信心爆棚,觉得开发不过如此。
但他们往往都欠缺了一项关键能力:从宏观到微观,把一整个复杂项目加载进自己大脑的能力。
以前做一个项目,一次次的需求评审、做取舍、改需求、uiue设计、前后端开发、改需求、测试、改需求、上线,然后每次迭代还要再来一遍。
几个月甚至以年计算去做一个项目,把里面的每一个细节都刻成了肌肉记忆。所以好多pm换工作之后,往往不受控制地做出和原来产品很相似的东西。
现在agent开发把这一切都缩短了。需求不明确,让AI去明确成需求文档,我只需要审核就行了,一宿就可以把需求文档定下来让AI去coding。
但因为需求定得太快,coding到一半的时候,如果有别的工作转移了注意力,很多细节就可能开始记不清了。然后面对程序返回的报错,忽然想不出要改需求还是改代码。
如果FDE没有把一个完整项目加载成肌肉记忆的经验,可能一开始就习惯了靠对AI输出yes or no,用大力烧token出奇迹的方式作出想要的东西。
小项目还行。但一旦到了一定量级,一切就会开始失控,要解决问题所烧的token也会指数级增长。
像sap这种项目,连"会用它"都能成为一个高薪职业。它的复杂度从来不只是在写代码,更多是在业务流程、跨部门博弈、合规和长期运维。
之前一个从未接触过开发工作的朋友,和我炫耀他独立vibe coding了一个项目。我问他用了多少token,然后找了一个以前相似项目的prd文档传上去跑了一下,最后用的token不足他二十分之一,第一次运行就没有报错。
差别就是有没有把完整项目装进大脑的那点经验。
所以AI时代的来临给了很多人机会,但也强迫他们去学更多的东西。FDE们现在以格格不入的方式,挤进本就越来越卷的职场,天生就是不进则退的。
也许不久后某天真能成了气候,但也可能很快迎来"小白靠和AI聊天就能做出sap"的时代。
和许多职业一样,生长到短暂灿烂、绽放之后凋零