AI资讯

AI帮写代码量暴涨8倍搞崩CI系统 最后靠AI给出新解法解决

智能摘要

写代码的行为模式和人类根本不是一回事。运行任务量在6个月内暴涨25倍。前后打了三次补丁——加核心、分片、每日强制重启,全都失效。过载。编程带来的冲击,已经从程序员写不写得完这一层,蔓延到了整套软件工程体系的承载能力——当写代码这件事不再受人力节奏约束,最先扛不住的往往是那些按人类习惯设计的流水线。

有一家公司公开的那些内部数据把大家都给震住了, 里头说百分之八十的代码都是由人工智能写出来的, 然后工程师们在季度的时候完成的工作量呢, 是过去四年时间里平均数的八倍之多。

可是真正让人感到要命的地方, 并不是代码写得写不完这种问题, 而是那个持续集成的系统直接被搞得彻底瘫痪掉了, 后面进行了三次的修复工作全都白费了, 没起到任何作用, 最后没别的办法, 只能选择完全推倒重来并且重新进行建设。

八成人力活全交给AI干了

根据该公司内部展示出来的数据情况来看, 全公司百分之八十的代码都是人工智能去写成的, 而且工程师在一个季度里面交付出来的代码数量是达到了二零二一到二零二五年这个平均水平的八倍的, 再就是讲得更夸张一点的话, 就连代码审查还有合并批准这一些这种传统上是由比较资深的工程师来把把控住的环节, 现在也是大量地都落在了人工智能的头上了。

这意味着什么呢? 在过去的情况下, 一个团队里有十个人,需要花费整整一个季度的时间才能完成一定的工作量。而现在, 依靠人工智能再加上几个人, 就能够把这些工作内容全部处理清楚并且消化掉。

工程师的主要职责角色, 已经从原本单纯的编写代码工作, 转变成了监督和使用人工智能工具的状态, 这种变化使得整个产品或者项目的研发节奏被全面地打乱和重构了。

AI写代码的行为跟人类完全是两码事

人工智能有一个非常显著的特点, 那就是它特别偏爱提交粒度极其细小的版本控制请求, 甚至只要改动了一个函数, 它就会立刻单独提取出来进行提交。

相比之下, 人类工程师往往习惯把这些修改攒积成一批变动, 然后再一起打包提交, 但人工智能却并不这样做, 它会保持一种全天候、不间断地持续提交的运行状态, 即便是在凌晨三点的时段也依然在努力执行任务, 完全不存在任何需要休息的概念限制。

更让人没想到的是测试用例的数量。AI生成的测试用例一下子增加了十倍之多, 要求对每一个分支和每一个边界条件都要进行覆盖。如果仅仅看质量的话, 其实并没有什么问题, 但是因为体量完全不一样, 所以原来的持续集成系统本身就没有针对这个数量级进行过设计准备。

CI系统六个月运行量暴涨25倍

CI系统是原来按照人类提交频率来设计的, 一个人一天提三到五次PR, 一个团队一天几十次构建,容量绰绰有余, AI一介入, 提交变成每分钟都在动, CI运行任务量在6个月内暴涨了25倍。

进入项目后期阶段, CI队列里面堆积了数千个任务, 导致每次执行构建操作都需要等待超过四十分钟的时间。当开发者提交代码之后, 接收反馈所耗费的时间被延长到了让人无法忍受的一个程度。这使得整个项目的迭代节奏直接陷入了停滞状态。最终, 研发团队成员除了被动等待之外, 什么也做不了。

打了三次补丁全没救活

第一时间的反应是增加核心数量, 将CI集群的机器扩容为原来的一倍, 在CPU和内存方面大力投入资源。然而这种做法并没有起到任何作用, 因为AI任务的提交速度远远超过了资源扩容的速度, 导致堆积如山的任务队列依然无法处理完毕。

第二次尝试采用的是分片技术, 把整体任务拆解开来, 分配到不同的计算节点上去并行执行。结果却是出现了节点之间锁竞争异常严重的情况, 系统的响应速度反而变得更慢了。

第三次采取的措施是每天都要强制重启CI服务, 目的是为了清理掉那些堆积起来、不再运行的僵尸进程。然而这个过程才跑了两天, 距离下一次计划好的重启还没有到时间就已经过去的时候, 任务队列就又重新堆满了。

这三次所谓的修补工作其实全是只解决了表面现象的治标手段, 因为底层的架构始终没有发生任何改变, 所以如果AI产生的流量继续这么大, 这种压力就永远都会把这个系统给压垮。

推倒重来换成分布式无状态架构

最终的时候, 团队听取了一个提议, 将原先的整套持续集成服务全部推翻, 然后重新构建了一套分布式的且不具备状态的架构模型。

在这个体系里面, 独立的处理节点是不存储任何状态信息的, 任务的调度过程是通过消息队列来进行分发的, 如果出现了某个节点损坏的情况, 可以立即进行替换操作, 完全不存在单点造成的瓶颈问题。

新架构上线之后, CI的进行扩容模式转变为了动态状态, 这种机制能够针对队列的深度状况来实施实时性的节点增加与减少操作。在最繁忙的时间段内, 系统能够在同一时间里运行超过一千个构建任务, 使得反馈周期被压缩到十几分钟之内, 工程师们终于不再需要在CI系统进行前台干等这一现象消失了。

最先扛不住的是按人类习惯设计的流水线

这起事故发出的信号是非常明确的, AI编程对人类的冲击已经从程序员是否能把代码写完这一点, 扩展到了整套软件工程体系究竟能不能承载得住这一状况。当编写代码这件事不再受到人力的节奏去约束的时候, 首先崩溃的不是人的生产能力, 而是那些为了顺应人类的设计习惯所搭建的持续集成、持续交付和代码审查流水线。

请问您的团队目前是否已经在使用人工智能技术来编写代码了? 在持续集成和持续交付这个领域里, 您是否有感觉到实际的工作负荷或者数据的表现情况存在一些不正常的现象呢?

欢迎各位朋友在评论区里面发表自己的观点与看法, 如果觉得内容对您有价值的话, 请点击赞支持一下, 并且把这个信息转发给您身边从事工程开发工作的同事们看一看。

相关文章