AI 时代的基础软件开发:机会、拥抱、驾驭
RobustMQ 正在从内核开始,定义下一代统一消息平台。欢迎关注我们的 GitHub,一起见证这个探索的过程。
最近大家肯定听到了各种AI Coding 的信息。说实话,2025年,AI 已经可以替我们做60%~80%的日常 CRUD 的Coding 工作了。随着26年到来,甚至27、28年,我个人认为,AI 肯定能替代90%,甚至95%的日常Coding工作了。
说实话,个人也很会有点小焦虑。不过咋说呢,我现在的想法是:我需要持续去Coding,保持自己的技术敏感度、竞争力。然后不断的和AI 磨合,去提高我自己的生产效率。
所以对我来说,我还是希望或相信,坚持手撸代码,保持自己技术能力的这一派(- – )。
在25年 Coding 开发 RobustMQ ,我越来越觉得,现在做基础软件和十年前真的不一样了。不只是技术栈在变,整个开发模式都在变。可以说,开发RobustMQ 的过程,是我和 AI 配合在开发的。
我也发现 AI 辅助编程加上越来越多的成熟组件,让这一代基础软件开发者有了很多的优势。所以接下来来分享一些个人的看法。
精力分配的改变
我观察大部分基础软件项目,很多时间不是在开发新功能,而是在重构和解决各种低级问题、隐藏 bug。看 Kafka 的 release notes,大量版本主要在修 bug、重构模块、优化性能。Pulsar 更明显,经常修各种边界情况的问题、并发死锁、数据不一致。
这些问题其实很多是早期代码质量不够导致的。边界条件没考虑全、错误处理不完整、并发安全没验证充分。当时可能是为了赶进度,或者开发者状态不好,或者 code review 没看仔细。问题就这样混进代码库,后期在生产环境慢慢暴露。
AI 改变了这个模式。我写完代码,立即让 AI 检查,它会指出边界条件遗漏、错误处理不当、可能的 panic 点。这些低级问题在早期就被消灭了,不会累积到后期成为技术债。
而且 AI 的检查是稳定的。不会”今天状态好就仔细看,明天累了就马虎”,每次都是同样的标准。该发现的问题不会因为人的疲劳或疏忽而漏掉。
这让我的精力分配发生了根本改变。以前可能 60% 时间在修低级 bug,40% 时间做核心工作。现在可能反过来:20% 时间处理问题,80% 时间做架构设计、性能优化、核心功能。这个改变长期看影响巨大,因为精力花在真正推动项目前进的事情上。
站在成熟轮子的肩膀上
另一个改变是成熟组件越来越多了。RocketMQ 要自己实现 CommitLog 和 ConsumeQueue,处理文件管理、索引维护、并发控制、crash 恢复。这些从零开始写,工作量大,而且容易有 bug。
我用 RocksDB 来实现类似功能,这些问题都已经被 Facebook 解决了。LSM-Tree 的实现、WAL 机制、Compaction 策略、并发控制、Crash 恢复,都是经过多年验证的。我只需要设计好 key 的格式、配置好参数,就能用。省了几万行代码,而且质量比自己写的可靠。
这不只是 RocksDB,io_uring、tokio、各种优秀的 Rust crate,这些都是可以直接用的轮子。上一代开发 Kafka 时,很多东西没有好的开源选择,要自己造。现在生态成熟了,很多基础能力可以复用。
两者的叠加效应
AI 和成熟组件结合起来,效果更明显。
因为用了成熟组件,代码量更少,AI 更容易理解和检查。如果是几十万行自己写的复杂代码,AI 可能理解不了。但如果核心就几万行,调用的是成熟组件,AI 的帮助就很大。
因为有 AI 辅助,可以更快地集成和优化这些组件。想了解 RocksDB 的某个配置、某个优化技巧,问 AI 快速理解,然后应用到项目中。
这两个优势相互增强,让开发效率有了质的提升。我估计现在开发基础软件,可能比十年前快 30-50%,而且代码质量可能更高。
宏观优势被放大
更重要的是,AI 时代让宏观层面的先天优势被放大了。
以前即使你选对了方向,但执行很慢、bug 很多,优势体现不出来。现在 AI 降低了执行门槛,战略选择的重要性就凸显了。
选对语言(Rust 而不是 Java),天生就有性能优势、内存安全、零 GC。
选对架构(统一存储、进程内缓存),天生就简单、快速、易维护。
没有历史包袱(新项目),可以用最佳实践、最新技术,不需要向后兼容。
这些宏观优势,在 AI 辅助下可以更快地转化为实际产品。以前可能”选对了但做不出来”,现在是”选对了就能更快做出来”。
这对新项目是巨大的机会。老项目被技术债拖累,被历史包袱限制,即使有 AI 帮助也改变不了根本问题。新项目可以轻装上阵,在好的基础上用 AI 加速,优势会越来越明显。
但要保持清醒
AI 和成熟组件确实是这一代开发者的时代红利,但不意味着基础软件开发变简单了。
问题的全集没有变少。分布式一致性、性能优化、稳定性验证,这些该难的还是难。AI 只是让你可以把精力集中在这些真正困难的问题上,而不是被低级问题分散。
稳定性还是需要时间验证。代码质量高只是第一步,生产环境的各种极端场景,只有真实用户才能触发。这个时间 AI 省不了。
生态建设还是要靠积累。协议兼容、工具集成、文档完善、社区建设,这些都需要长期投入。
AI 需要驾驭,不是依赖
精力分配发生变化的情况下,自然而然会带来很大的提速。我认为这不是盲目信奉AI,而是现实。但如果唯 AI 论,那是百分百不对的。提速不是一步到达终点。
AI 确实让速度变快了,但它不是全能的,表现好坏完全看你如何驾驭。
我的经验是:不要期待 AI 给你解决问题,而是在你的看守下,AI 能帮你解决问题。区别在于主动权在谁手里。你要清楚知道问题是什么、解决方案的方向、可能的坑在哪里。AI 在这个框架下执行,效果才好。如果你自己都不清楚要做什么,把问题直接扔给 AI,它给的方案可能看起来合理,但实际上不符合你的架构。有没有坑,得自己把握。
AI 的一个巨大优势是它不会走神。我让它检查代码,它每次都会认真扫描每一行。但人会走神,特别是做重复性工作时。review 几千行代码,开始还很仔细,后面就累了。这种走神导致的疏漏会让问题混进代码库,而且人的走神消耗的不只是时间,更是精力。你知道应该仔细但状态不好,这种心理负担是隐形的消耗,很可怕。
AI 帮我们解决了这个问题。检查工作交给它,它不会累、不会走神、每次都认真。我们可以保持精力在核心工作上。这就是为什么我觉得会提速的核心原因。
总结
最后我想说,AI 真的给开发者带来了很多机会,独自完成中大型项目的机会。拥抱它,我觉得它不是开发者的敌人。或者说是不是敌人,是看自己是否能够驾驭它,是否足够努力去拥抱它。需要让自己的能力能够跟上 AI。只有自己的能力跟上了,才能驾驭,才能让自己不被时代抛弃。
如果你对 RobustMQ 感兴趣,欢迎关注我们的公众号获取最新动态,或者直接参与到项目开发中来。让我们一起用代码改变世界!
📞 如何联系我们?
-
🐙 GitHub:https://github.com/robustmq/robustmq
-
🌐 官网:https://robustmq.com/
夜雨聆风
