过去仅仅半年到一年的时间，互联网行业似乎完全被 LLM 翻了一遍，随处可见所谓「天才程序员」的身影。Coding agent 的工作范围由最初的简单机械的重复任务演化到如今的什么都能做而且做得远比一般人好，大家似乎也逐渐习惯了无脑提要求给 LLM 实现然后检查结果（甚至是不检查）的工作流，自己考虑实现编写代码的场景越来越少。
各大头部企业都在裁员，而且势头只增不减。与此同时，许多吃上 AI 红利的新企业或是品牌，开始出现了前所未有的资源和人才需求。各处学校/学院/培训机构都开始向 AI 相关方向发展，围绕其增添了许多新的赛道和发展方向。越来越多的实体甚至是概念在「AI 化」之后仿佛都有了前所未有的增值和发展潜力，吸引着大量客户和投资人，即使它们与 AI 的关系几乎八杆子打不到。
那么如今，在这个「all in coding agent」的时代，人类程序员还需要，还能够做些什么？
或者换个问法——我们，软件开发这个职业，离被取代还远吗？
去年年中，甚至可以再往前几个月算起，在各种 LLM 和 coding agent 风声水起的时候，大家都注意到 —— Web 前端这个行业已经几乎不需要人类了。从那时开始，LLM 就有一种很明显的替代人类开发者的势头，其能力和产出效率完爆一个高级工程师，但需要的成本远比一个高级工程师的工资低，数十倍的低。也是从那时起，各家企业就开始猛猛裁员，软件开发尤其是前端开发的岗位似乎在一夜之间成倍减少，大量企业员工丢了工作，被迫转向其他行业或是疯狂内卷提升自身能力，亦或是带着自己的工作经验重新踏入社会，降低要求和期望以再寻求一份稳定的工作。
Coding agent 仅发展了一两年的时间就重塑了整个软件开发行业 —— 至少从表面上看，确实是重塑了。当年 OpenAI CEO 奥特曼提出的 vibe coding 在现在看来就是一个非常平凡的现象，你 vibe，我 vibe，他/她也 vibe。所有人都在监督 AI 干活，然后美美摸鱼，摸到一半看看 AI 干的怎么样了，骂两句，继续摸鱼。等到 AI 做完一个任务，看两眼代码，然后告诉 AI 提交推送发 PR，然后继续摸鱼或是继续下一个任务，如此往复。
这种做法有个形象的名字「面向结果编程」，即只关注目标和结果是否符合目标，不关注中间的实现细节 —— 这越来越贴近一种产品经理的工作路径，即设计用于满足需求的方案并监督实现它们，但不关注具体过程，只关注这个方案是否有预期的结果。但目前，派发具体的任务和解决一些奇奇怪怪问题仍然是很具有技术性的，就导致这份工作并没有完全被产品经理取代。
不过，从现在来看，似乎被取代也是迟早的事情，按 LLM 以往的发展速度，过不了多久它就可以做到在非技术性的 context 下自行解决所有技术性的问题了。实际上现在也有产品经理自己拿 coding agent 搓了一套系统结果比一伙吃干饭的技术做出来的东西还好用的案例，而我自己现在相比走纯技术路线也在更关注技术之外的东西，因为 LLM 似乎永远可以花费比你自己学技术少得多的成本做出比你好的东西 —— 写代码的技术似乎正在变得越来越廉价，越来越不具有「不可替代性」。
但是，当真如此吗？
以上，都是站在宏观角度上与历史发展对比所得出的结论，当我们单纯从技术和开发的角度去观察这一过程，又会发现端倪：一个软件开发工程师的 vibe coding，和一个不懂代码的产品经理的 vibe coding，真的是同一个 vibe coding 吗？
圈子里有个笑话：
文科生: 豆包豆包，你来帮我写一个程序，我要打败所有理科生。
豆包: 好的，请问你想要用什么语言写呢？
文科生: 用中文吧。
虽然挺抽象，但是它正说明了一个事实 —— 会写代码的人与不会写代码的人在使用 agent 时，其思维模式与提示词可能是完全不同的。正是这种似乎很小的不同，造就了本质上的差距：一个软件开发工程师的 vibe coding，是非常精确的目标导向，精确到去修改某个模块、查找某个地方的某个问题，甚至可以是准确的将某个文件重构到什么形态、使用什么算法/设计模式；而一个产品经理，如果没有相关开发的经验或是知识储备，就只能做到描述产品的原生需求，而剩下的使用什么架构、选用何种数据形态、控制流怎么设计、如何优化调用性能等等问题只能留给 LLM 自行发挥。
而这就是问题的关键 —— 当代的 LLM 能做到在完全没有外部监督和引导的情况下，自发设计出一套高可用性的成熟技术架构吗？很遗憾，答案是：不能。
各种各样的案例都在告诉我们，在纯 vibe coding 的环境下，如果放任 LLM 自己去实现原始需求，它最后到底会端出来多大一坨 —— 很可能是一坨完全不能跑的废料，或是能跑，但也仅限能跑，可维护性灾难的东西。当代的 LLM 仍然倾向于以最直接最有效的方法完成任务，而非考虑整体设计和全局影响。
当下，一套成熟的 vibe coding 工作流仍然是很传统的「设计原型 -> 优化方案 -> 实施方案并在过程中不断检查和发现问题 -> 重复改进或推翻原有方案 -> review 和集成测试 -> 交付」，而期间开发者给出的引导和 review 尤为重要，直接决定了 LLM 到底是不是在正确的方向上做正确的事。结果，LLM 在这其中做的最主要的事情仍然是最机械的写代码，而非灵活的决策，只是随着 coding agent 和 LLM 自身的发展，它能做的事情变得越来越多了，仅此而已。
未完待续
喜欢的话，留下你的评论吧～