AI代码生成会如何影响软件生态-夜雨聆风

AI代码生成会如何影响软件生态

我们之前的某篇吐槽似乎获得了预期之外的关注（开源软件大概真的要被AI搞死了）。但感觉就跟我们以前获得关注的文章一样，只是因为戳中了某种情绪，而非因为文中的内容。所以我们这次尝试抛开情绪，沿着这个方向继续思考下去，看看现有的代码生成技术会对当前的软件生态造成什么样的影响。

一、软件生态现状

当前的软件生态大概是这个样子：

(网图侵删)

哎哟…放错了

。是这样：

(https://xkcd.com/2347/)

可以看到上层的软件都是依赖其下层的软件搭建出来的，层层堆叠。这也是软件栈(Stack)这种说法的由来。

让我们先只看最上面的某个部分：

可以把这想象成是某公司内部的软件栈，分别对应后台、中台、前台之类的。

那么图中的空白部分就可以当成是尚未触达和满足的用户需求。

于是这家公司的目标就很明确了：在现有的软件栈的基础上，搭建更多的软件，来覆盖和满足更多的用户需求。

二、代码生成技术现状

当前大模型的代码生成能力训练自刷题（大模型就是屎山），题目就是类似Github上常见的issue，比如改bug和加feature等[1]。

当然可能还有的公司是直接给开源项目自动发PR（开源软件大概真的要被AI搞死了），把项目贡献者当成免费数据标注员白嫖的：

Anthropic 显然清楚，“AI 参与开源贡献”在很多社区依然是敏感话题，所以它的做法不是提高透明度，而是先把身份隐藏起来。在这种前提下，一个更值得追问的问题是：他们内部究竟已经对多少开源代码库造成了多大破坏。

Tina，公众号：InfoQClaude Code 泄露的代码里，处处写着：这家公司人品不行

用前一阵比较火的“蒸馏打工人”的思路来理解的话，就是既然码农们每天的工作就是改bug什么的，那么当大模型“蒸馏”了足够多资深码农的经验以后，是不是就可以自己干活了？

这个思路从交付的角度看确实没问题。因为交付的标准之一就是看bug数是否收敛。既然bug数收敛到了可以交付的标准，那为什么还要在意是不是人类修的bug呢？

只不过所有的事情都可以问一句“那么代价是什么？（but at what cost?)”。这个我们留到后面再说。

三、应用代码生成技术

假设代码生成技术足够成熟了，赛博码农们都是白菜价了，上面提到的那家公司会怎么利用这种技术呢？

首先自然是尝试维护已有系统。不过这方面我们目前看到的例子不多。大概是因为好的系统设计都是相似的，而屎山总是各有各的屎法。并且可能因为模型上下文大小的限制，暂时还不足以装下整座屎山。

所以一开始可能会用在前台里一些全新的小功能上（红框代表AI生成的组件或功能，下同）：

其实能够做到这一步的话已经是很大的进步了。因为此时企业可以用低成本快速验证用户需求和试错。

速度有多快呢？现在就连本地部署的大模型生成速度都有每秒几十token。注意是每秒不是每分钟。这就意味着大模型的打字速度至少比人类高一个数量级。这也意味着能够掌控大模型输出的人就等于是拥有了一把超级键盘。

再下一步可能会觉得，原本中台是为了快速开发前台而搭建的，但如今中台变得越来越臃肿了，加个功能还要等排期，反而成了拖慢前台发开发的因素。有没有可能绕过中台直接开发呢：

沿着这个方向更进一步的话，公司后台依赖的开源/商业的组件是不是也可以不要了：

这也是之前SaaS板块暴跌的逻辑：如果人人都可以自给自足，那么服务商就没有活路了。

而这种从头构建的思路可以一直往软件栈下方延伸：

马斯克甚至还说应该让AI从二进制开始生成软件，大概会是这样

：

只能说很符合其一贯的第一性思维了。

四、能否成功

那么代码生成技术能否让所有人都拥有“软件自由”呢？

从好的方面看，从头构建确实存在着成立的可能。

拿上面中台的例子来说，原本是为了提高前台开发效率的，为什么后来会成为开发效率的阻碍呢？因为可能随着中台对接的部门越来越多，需要考虑的情况也就越来越多，程序越来越臃肿，维护成本也越来越高。最后甚至可能会遇到某种情况打破了系统设计时的假设，结果不得不大改。

而从头构建的话，因为需求明确，所以只需要实现能满足需求的最小功能就行了。说不定就可以把项目规模始终控制在一定的范围内。

那这样的风险又是什么呢？软件开发中有一条Kernighan定律：

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. （调试的难度是初次编写代码的两倍。因此，如果你以尽可能巧妙的方式编写代码，按定义来说，你就不够聪明来调试它。）

Kernighan’s Law

原本讲的是写代码的时候要以简单直白的方式来实现，来降低维护的成本。

放到代码生成的语境中，我们认为就是如果你发现AI生成的代码不够直白，那么你可能就没法维护它。

我们觉得任何软件行业的从业人员都应该把可维护性视为业务支柱，而不应该只看是否满足了交付标准（可能如今交付标准也需要进一步修订了）。毕竟如果哪天软件出了致命的bug，作为责任人的你看不懂AI写的代码，AI在那边不停烧token但还是改不好的时候又要怎么办呢？

所以为了让AI生成的代码可维护的话需要怎么做呢？答案还是传统的软件工程。因为软件工程原本就是为了控制软件的复杂度而生的。

最简单的例子，AI从头构建的代码可能也是一坨，即便是让AI重构以后也是如此，这是由问题的本质复杂性导致的。我们能采取的方法依旧是拆分和复用，确保拆分后的每一块都是可以被理解和维护的：

代码生成的效率足够高的话，可能确实会让人不再为了节约开发时间而去复用了，但复用的意义不仅在于避免重复开发，还在于控制复杂度和理解/维护的成本。

小结

所以听说程序员马上要被AI淘汰了？应该不至于，除非所有的公司都能够接受把自身业务完全建立于AI厂商的设施上。

AI写代码AI审核也是一样的问题，没有可以负责的人类参与的话，就是在赌AI可以自行解决一切的问题。对此我们之前评论过好多次了，这里不再赘述。

让我们耿耿于怀的还是供应链里的薄弱环节：

比方说现在头部厂商的旗舰模型只开放给少数大厂（应该对Anthropic的Claude Mythos感到担心吗），号称是因为这些大厂提供了基础设施所以需要先确保它们这些设施的安全。那图中这种个人或小团队志愿维护的项目又要怎么办？要知道曾经一个小小的left-pad包就让所有大厂的基础设施都瘫痪了一遍。这些模型厂商的行为真的是对社区负责吗？

哎说着情绪好像又上来了，先这样吧。

参考

[1] SWE-Bench Pro

https://labs.scale.com/leaderboard/swe_bench_pro_public