杀死软件工程师
我们要杀死软件工程师，至少是杀死软件工程师的title。
今天我们产品（Brandon）在领英上写了一篇博客，讲诉的是他的一段经历：
One former banker had built a simple app prototype and was getting real buyer interest. Someone with their own digital marketing agency was using AI to analyze sentiment data at a scale that would have been painful and/or infeasible to do manually. A good friend of mine who worked in GTM strategy used AI to iterate on slides and narrative. An animator/designer had been pushing Claude Code into a complex interactive front-end project.
It was an interesting weekend seeing how much the conversation had developed.
— https://www.linkedin.com/pulse/control-loop-skill-brandon-galang-puqme/
大致意思是，一个银行从业者利用vibe coding 写出了一个解决实际问题的产品，还获得了投资。但从技术角度上看，这个产品只是一个CRUD（增删查改）的原型。
我读了之后，有两点思考：
- 为什么一个非软件开发人员，还能从一个成熟系统里，挖掘出软件尚未解决的问题？-> 哪里还有业务价值的漏网之鱼？谁能发现它？
- 为什么这个产品是基于增删查改的框架的？-> 抽象性思维和框架性思维的价值还在提高
第一个思考点：哪里还有业务价值的漏网之鱼？谁能发现它？
既然它只是一个简单的增删查改，那么为什么在AI来之前，没有一个软件（应用）能捕捉到这个场景的价值呢？
答案显而易见，有一些需求是只有真正在一线业务部门工作的人，才能洞察到的。
软件工程的门槛被AI 扁平化之后，软件行业发展这么多年之后的”漏网之鱼”，正被AI填补起来。这部分的需求和产品，显然是有巨大价值的。
但是这些漏网之鱼跟传统的软件工程没太大关系。传统的软件行业公司，如果要捕捉这些需求，就应该杀死工程师，忘记软件工程那一套说辞，从客户的角度出发，解决客户的困难。
前几天，我在给公司的产品团队推广由Jay 开发出来的Obsidian 插件时，我们发现，最大的门槛就是安装，配置环境变量，配置claude code 窗口和llm key。再跨过这道门槛之前，没人愿意尝试AI，探索AI对他们能有什么影响。
BTW: 我自己也在用这个插件，非常简单的利用了skill，结合KV 的理论来管理你的个人知识库，效果很棒。https://jayjiangct.github.io/knowlery/zh/
工程师，在解决问题的时候，更擅长思考的方向是”如何解决”这个问题，而不是，这是不是这个问题根本所在的问题。所以工程师，或者远离一线业务部门的人，设计出来的产品常常脱离实际，充满了对业务的理想假设，转而在其它方向上一直发力，比如某些刁钻的难题上。
往后，这类工程师要先被杀死，解决不了客户问题，实现不了任何用户价值的产品，会很快死掉。
第二个思考点：抽象性思维和框架性思维的价值还在提高
我们有一个共识，AI现在已经能很轻松的开发一个需求明确的接口。
如果一个复杂的业务，能被高度抽象成增删查改，那么它就很合适被AI实现出来。
重点是，如何把这些业务，抽象成相互隔离的业务接口。能用最简单的API解决的问题，绝对不要引入过于复杂的技术方案。
博客中提到的银行从业者，正是在真的理解业务的基础上，把这个业务抽象成了CRUD 的接口，所以一切行之有效，在这整个故事里，并没有工程师什么事情，这部分的工作，全是AI在执行。
传统软件工程师应该被杀死，尽快的被杀死
我开始痛恨软件工程师的title，因为工程师一点也不懂如何将自己的技能变现，空有一身本领。在解决实际问题前，这些能力都没任何价值。
我们要利用软件产生价值，不需要依赖及其高超的技术，单单是用好现有的工具，就有非常非常多的可能性。
我最近在build 一些自己的产品和页面，结合aws cli，这些产品从域名注册->aws 资源配置 -> 自动化pipeline -> 发布产品上线，真的只需要半天就能搞定，而我已经多年没有使用aws。在我部署多套应用和多个产品之后，我也能很容易的利用claude code + aws cli，对其进行监控和成本管理，比如分时，分量部署。曾经，在一些大公司里，管理这些资源需要专门的部门来规划。
举这个不那么恰当的例子，我想说明，工程师很大一部分的角色功能正在被淡化，被AI顶替，只要我有粗浅的知识，比如，知道这件事该如何做，我不需要了解非常多的技术细节，我也能把它做好。
所谓软件工程师们，往后要做些什么呢？我认为，框架性思维的复利，将会有比以往更大的作用空间，一个有经验的框架师所搭建的产品，它的维护成本会远远比纯粹vibe coding出的产品要低非常非常多。
将来软件团队的理想组成，应该是由一个有丰富经验的AI框架师 + 一个深耕某业务场景的产品 + AI 所完成。所谓的AI框架师，实际上是现在所流行的AI harness engineer。
传统软件工程师们，都应该向AI Harness Engineer 转型，我敢断言，三年后，留存在软件行业的开发人员，只剩下两拨人，首当其冲的是那些能够驾驭AI的开发人员，他们大都是有经验的框架师。另一波人是编程能力非常强的人，能够从AI所生成的代码里找到纰漏的那部分资深程序员。那些平时只是写写增删查改的程序员，将不复存在。
一些乱七八糟，没思路的题外话
还是回到Brandon的博客，他发表的核心观点之一是，一个有效的AI开发的流程，能够让你的产品开发过程变得非常可控。
当我们利用AI 做vibe coding时，一切发生的是那么的快，以至于产品走入那个无法挽回的死胡同，也是非常容易发生的，很多时候就是一念之差。
关于软件开发的迭代速度方面，从前，我们的产品讨论一个月，投入巨大的开发工作，测试工作，很多项目因为沉默成本巨大，而不得不一直被破罐子破摔，成为项目甩不掉的业务债。
在对AI 有效的驾驭的前提之上，现在一个idea 要被验证的速度，远远高于从前，软件从idea 到产生价值的阶段，时间被压缩的极低。
这篇文章只是探讨了，工程师应该开始思考做Harness Engineering。关于Harness Engineering具体该做什么，要做什么，我应该花更多时间来思考后再梳理成另一篇单独的文字。