root 发布的文章

从IT精英->IT民工,其实也不是什么笑话,真实地反应了程序员这一领域的变化

早期编程需要打孔,汇编时代程序员需要处理寄存器、堆栈以及调用等问题,C/C++时代需要考虑内存释放于泄漏的问题,到了PHP跟Java时代,基本上你只要逻辑能整明白,在企业场景编程基本上没有什么困难,你所需要的库跟工具都有封装好的包,开发者唯一的难点在于如何使用这些工具结合业务逻辑。

到了vue、reactjs时代,前端进一步工程化,更进一步降低了大型前端项目的开发难度。

从程序员的角度来讲,已经没什么困难需要被解决了,之前很多问题都被造轮子的高阶程序猿给解决了。

很多人说高并发很难搞,实际上大部分公司并没有什么高并发,高并发在大部分公司只不过是一个屠龙技,另外高并发本身也就是一个经验问题,当你做过很多场景之后,发现也没什么困难需要去解决,甚至诞生出来golang这种自带协程跟高并发解决方案的语言,更进一步降低了并发编程的门槛,而且现代软件工程大多都是服务化部署,有成熟的伸缩解决方案,需要被解决的高并发问题越来越少。

另外还有一些 小众领域,编译器、操作系统、底层驱动、图形,你真去了解过后,其实你深入去探究也就那么回事,无非就是一个时间积累跟调包经验的问题,并没有什么真正的困难,你说有对个体来说啥护城河呢?可能唯一的优势在于萝卜坑少,没什么新人,老人一般比较稳,但是这些领域提供的就业岗位又极少,失业很大程度上可能就再难找,甚至大部分人连萝卜坑在哪里都不知道。

剩下的无非是一些大型软件工程项目复杂度把控的问题,这些问题都由高级别的架构师负责,轮不到资深开发来解决,而且大部分项目的业务复杂度完全到不了需要请架构师的那一步,基本上几个资深开发一合计这项目架构工作就完事了。

另外国内大部分软件工程项目也一直是猪突式开发,能用就行,基本上没有任何可维护性设计,老板也没为这个东西发工资,大部分老板要的就是快。更何况 人力如此廉价,实在不行,招应届生来吃屎就是了,屎山哪天实在爆炸了,招人重写就行,人嘛,太便宜了,现在年轻人6块钱一小时进厂打螺丝,你觉得你一个老码农又能贵到哪里去?

市场供需不平衡的时候,你还能喝口汤或者吃口肉,10年前iOS会画个页面,就能拿1万,现在大把大把应届生把前端全撸明白了,可能连外包工作机会都找不到,这就是市场的力量,个体做出什么努力在这个环境下都不会有出路,学技术,不如学语言直接润,甚至语言可能都不需要学,过几年搭配离线LLM 直接硬件实时翻译,语言也不一定需要学习了。

我们再来看后LLM时代,AI编程工具对程序员的冲击,很多人说LLM做不了复杂的东西,目前的情况确实如此,在长上下文场景,LLM很容易产生幻觉,并不会根据你的指令进行工作,但这并不重要,甚至根本不是一个需要被解决的问题,AI编程工具只要在小的上下文里面达到90%的可用性,就能替代一大批程序员的工作,因为大部分程序员的工作都是在不断的重复,并没有什么本质上的创新,这也是当前LLM为什么流行的根本原因,因为LLM太适合重复了。

另外大部分公司真的有什么复杂的东西么?一个商城产品展示页面,产品展示的div不需要开发一个功能从页面边缘飞到用户鼠标旁边并且翻转180度,这说明什么?大部分软件的功能页面以及业务逻辑,基本上都是趋同设计的,LLM只要把这些趋同设计领域的代码背下来,最后撺掇着给程序员一个差不多的解决方案即可,然后程序员只要根据这个半成品修修补补就能完工出活,这意味着大量的页面以及业务逻辑代码都可以用AI进行生成,原本2-3个人事情,只需要1个人就能完成,这个冲击在当前就业市场是十分巨大的。

后LLM时代下的程序员的知识技能将变得非常廉价,准备好迎接冲击吧。

答案是否定的。

这些竞赛在LLM出现后,已经没有任何意义,编程竞赛都是有套路的,他考验的是你能不能在现有算法知识库中,以规定时间内找到复杂度合适的算法来解决问题,出题的人肯定是知道算法答案的,LLM只要暴力搜索,并发量达到一定程度,总能弄出一个正确答案出来的,人类的问题在于人脑搜索并验证的速度太慢了,这些竞赛并不考验人对复杂性的处理,与现代软件工程师的要求完全相悖的。

而且这些竞赛的算法代码最终的实现的代码行数都不会太多,因为是竞赛,代码量会控制在1000行以内,其本身的代码复杂度并不会高,而且很多都是套路题,递归回溯这些都写了千百遍了,对于新手来讲,处理这些点是有复杂性的,但是对于老手来讲,基本上就是信手拈来,很多复杂性对于老手已经不存在了,根本难题在于在大脑里面搜索找到 符合时间复杂度要求的算法。
老码农大多不喜欢做算法题的根源就在于此,甚至我觉得在LLM出现以后,做任算法题都是在浪费生命,在码农几乎不需要的知识库里面检索一种可行的答案简直就是对软件开发者的一种侮辱,类似翻转二叉树等问题。


码农包括码架师 要处理的是现实世界的问题,它包含了太多的随机性跟不确定性,光是一个仓库出入库以及报表管理流程,1000家企业就有1000家运行逻辑规则,大多时候不是企业去适应你这一套软件业务规则,除非你达到世界级的体量,你说我们的标准就是业务流程操作标准,即使强如SAP,也大量入驻企业,给企业做定制,买方是大爷,强推自己的标准只会吃瘪。

C端软件消费的目标群体是大众,就算是一坨屎大众也都吃了,推荐算法就算很垃圾,也不会存在个人用户逼逼几句让做算法推荐码农给你个人化定制适配一套,而企业内代码的逻辑是完全相反的,软件工程师需要去适配各种乱七八糟的业务规则,甚至非标流程。


而现实中的业务代码跟编程跟这个竞赛完全是两回事,大量的企业代码库极其庞大,业务模块的边界性是极度失控的,代码库里面夹杂着大量无效信息,bug,以及各种业务规则的随意性,而且还有大量的随机复制,它的信息熵其实是极大的,而且有效信息熵占比极少,甚至以修改了一个地方,会在遥远的另一个模块里面引发大量的bug,这也是为什么软件工程师只要工作了多年,基本上对代码修改抱有慎之又慎的态度。

这其中又包含了软件系统本身业务要求带来的复杂性,以及编程人员管理失控带来的附加复杂性,类似随意的代码复制,模块业务规则大量耦合,等等一系列的问题,
现代软件工程并不要求你解一个难题,因为穷举导致计算复杂度过高而搞不定问题的时候,你就去算法库里面找就是了,而且这些需要算法实现来降低计算复杂度的问题,都有专门的部门来处理,他们也有自己专用的套路跟算法库来解决这些问题。


而且早就有大佬都说了,拿不准就穷举,其实跟LLM有一定的相似性,LLM也是拿不准就穷举,只不过它穷举的办法是把知识库里面的所有算法模式给你匹配一遍,而人类的拿不准就穷举只能是蒙特卡洛树搜索。
我个人觉得编程达到AGI的一个标志性,就是能把上千万行代码的狗屎业务系统代码能梳理得井井有条,且这一过程完全不需要人工介入,并且达到原先的效果且包含bug,因为很多东西就是靠bug运行的,你改了它反而会引发更多的问题。


最后,LLM的能力高低 应该是以其能处理复杂度多高且无法轻易验证的事情为准,而不是以其在轻易验证的领域中应对复杂度极低的问题为准。

LLM只是一个模式匹配工具

  • 如果你这个问题领域已经有很多方案以及程序的代码,LLM是一个很好的工具,它能提供大量成熟的开源代码碎片给你抄
  • 动态分析调试的能力欠缺,Agent整合各种工具的能力依旧欠缺,毕竟很多工具是面向GUI的

未来的思考

  • 面向企业级内部的应用开发框架会深度整合AI,例如很多b端项目,没有复杂的页面逻辑跟页面交互,大量开发工作在于整合业务逻辑形成逻辑闭环的系统,AI将大量在这些领域发挥作用,因为这些领域本质上没有什么技术问题,核心的问题在于业务需求的理解,甚至LLM会整理出一套闭环的系统体系,非专业程序的工作人员也可以根据自己的对业务的理解,通过自然语言构建自己的系统模块原型,最后交付给专业程序猿来整理或者调试
  • 低代码将彻底退出历史舞台