Spring 创始人Rod Johnson 播客访谈：AI 能写 95% 代码，但架构能力才是开发者的核心壁垒
导读：Spring之父这样说：我用 AI 写了 95% 的代码，但如果你不懂得架构，AI agent 只会让你更快地写出烂代码。
当下， AI 编码工具使用率正在不断增长，为数众多的开发者依赖 AI 生成代码，有些人甚至认为架构设计、技术把控的价值正在弱化。
Spring 之父、Embabel 创始人罗德·约翰逊（Rod Johnson）做客一档播客节目，他结合自身从业经历、对行业趋势的观察以及全新项目实践，对当前开发者的一些问题做了一番阐述。
在与主持人他这样说：AI 可以高效产出代码，但如果开发者缺失架构思维，AI 只会加速产出劣质代码。同时，他还围绕企业 AI 落地、编程语言选型、技术框架演进、开源生态等行业热点，分享了诸多独到的观点。
一、从音乐博士到技术专家
很多人并不了解，缔造了经典 Java 生态的 Rod Johnson，有着一段颇具传奇色彩的跨界过往。
他的本科是在悉尼大学就读，主修音乐与计算机科学双学位，后续他又攻读了19 世纪巴黎钢琴音乐方向博士学位，毕业后，他还在悉尼音乐学院担任过一段音乐史讲师。
即便在音乐领域，他对编程一直保持热爱。
20世纪 90 年代，共享软件正当盛行时期，他独立开发的 Windows 共享软件收获了不少粉丝。在几番现实考量下，他最终选择编程作为职业，音乐转为个人爱好，也从此开启了改变了世界 Java 生态。
现如今，Rod Johnson 是 AI 编码工具的重度使用者，日常工作中约 95% 的代码都由 AI Coding Agent 完成。
但他这样表示，自己始终牢牢掌握设计与架构的主导权，AI 只是提升效率的工具。哪管无需亲手敲写大量代码，创造与把控的过程，依然能带来十足的成就感。
离开 Spring 生态后，他多年投身投资与企业董事会的相关工作，随着大模型技术迎来爆发拐点，他察觉到企业 AI 落地存在大量痛点，于是再度下场创业，推出全新 AI 框架项目 Embabel。
在此之前，他自主学习了 TensorFlow、深耕 AI 底层技术，为新项目积累了充足的技术储备。
二、拒绝盲目更换技术栈，场景才是核心
当下的软件开发行业出现一股风潮：不少公司一刀切地要求技术团队放弃 Java，全面转向 Python 开发 AI 相关应用。
对此， Rod Johnson 明确表示，这种做法完全违背技术选型逻辑。
他这样解释道，大模型的调用本质只是简单的 HTTP 请求，并不会因为编程语言的不同产生特别大的性能差异。对于绝大多数传统企业而言，核心业务系统、数据库服务、业务逻辑基于 Java 构建，强行切换到其它技术栈，只会徒增迁移成本与运维风险。
他也不否定 Python 的价值：在模型训练、数据处理、数据科学等场景中，Python 拥有无可替代的优势；但对接存量企业业务系统、构建线上应用，沿用原有 Java 技术栈才是最优解。
他自研的 Embabel 框架，核心主体使用的是 Kotlin 开发，配套示例则以 Java 为主。在他看来，Kotlin 与 Java 拥有极佳的互操作性，规避了早年 Scala 与 Java 兼容困难的问题；同时 Java 语言多年来持续迭代进化，功能与性能都在不断完善，外界片面唱衰 Java 的观点并不客观。
另外，他还谈到了 TypeScript 的产品价值。
TypeScript 凭借完善的类型系统，大幅提升了前端与 Node.js 服务端的开发质量，但在企业级后端领域，JVM 生态的稳定性、健壮性依旧更胜一筹。结合 AI 编码工具的特性，他还发现一个有趣现象：由于 Kotlin 是一门诞生较晚的现代语言，行业内劣质代码样本少，AI 生成 Kotlin 代码的质量，整体优于 Java 与 Python。
同时他强调，即便 AI 能熟练驾驭各类编程语言，企业也不要为不同业务随意切换语言。可参考微服务发展的历史教训，多语言技术栈会带来极高的维护成本，技术栈稳定、团队可长期维护，远比 “追新” 重要。
他建议开发者要保持终身学习习惯，每一两年掌握一门新语言，以此拓宽技术和架构思维。
三、企业 AI 落地：两大核心误区，架构能力决定最终成败
结合一线实践观察，Rod Johnson 指出，当前企业 AI 落地普遍存在两大致命问题，也是多数 AI 项目走向失败的根源。
第一个误区：为了 “跟风 AI” 而落地 AI，缺乏真实业务场景支撑。
不少企业高层下达 “全业务 AI 化” 指令，团队在没有明确业务目标、没有梳理适配场景的前提下强行上马。事实上，传统方案在速度、成本、确定性上往往优于大模型，能不用 LLM 解决的问题，就没必要强行接入。
他分享了一个优秀的落地案例：澳大利亚一家企业从微小场景切入，将 AI 用于网站表单的自动审核。原本需要人工处理的简单表单审核工作，借助 AI 实现 95% 场景即时反馈，循序渐进落地，既降低风险，也逐步积累团队对 AI 的使用经验。
第二个误区：AI 与核心业务系统割裂，沦为独立 “外挂层”。
他接触过一家大型企业，公司 70% 的系统基于 Java 开发，剩余系统也逐步向 Java 迁移，但团队的首席 AI 架构师只有 Python 背景，甚至从未了解过公司主力技术栈。技术团队与核心业务脱节，最终导致 AI 项目难以深度融合、价值打了大折扣。
针对当下有不少开发者过度依赖 AI 的现状，Johnson发出警示：UI 类临时项目可以依靠 AI 快速开发，但严肃的企业级软件绝对不能放任 AI 自由发挥。
AI 擅长执行编码工作，却根本没有全局架构思维，若开发者完全放权，AI 会不断堆砌功能，一步步侵蚀原有代码设计，最终导致代码库臃肿、架构完全腐化。
他在视频中分享了自己的工作模式：AI 负责绝大部分编码工作，而自己专注架构评审、代码规范把控、设计模式优化。遇到 AI 出现硬编码、设计不合理等问题时，会及时纠正引导。
这种 “人控架构、AI 做执行” 的协作模式，最终产出的代码质量与开发效率，远高于纯人工或纯 AI 开发。
在实际场景使用中，他提到 AI 存在明显短板：
面对全新、小众的复杂测试架构等场景，AI 由于训练样本不足，表现会十分吃力；同时大模型存在注意力衰减问题，即便提前设定规范，也时常出现遗忘规则的情况。
四、用确定性规划，破解 AI 流程不可控难题
作为面向企业 AI 流程自动化的全新框架，他的Embabel 在核心规划引擎上做出了差异化创新。主流 AI 框架大多依靠大模型自主决策执行步骤，流程顺序、参数调用都存在不确定性；而 Embabel 创新性引入游戏 NPC 领域的 GOAP（目标导向行动规划）算法，打造确定性运行逻辑。
GOAP 基于一种称为 A-star 的算法，会根据系统当前状态、行动前置条件与后置结果，在运行时动态规划出抵达目标的最优路径。整个流程具备强确定性、可追溯、可审计的特点：
开发者只需通过注解标记 Java/Kotlin 方法，依靠语言类型系统自动关联执行步骤，无需繁琐配置状态机； 规划器会提前校验前置条件，无法执行的步骤会直接拦截，避免无效运行； 支持动态计算执行成本，当某一节点负载过高时，自动切换备选路径； 全流程可输出日志与事件，每一步决策都可溯源，完美满足企业审计、排查问题的需求。
这种系统设计能够灵活拆分任务：不同步骤可搭配不同大模型，敏感数据相关环节可使用本地私有化部署模型，保障数据安全。同时，将流程规划与 LLM 解耦后，提示词与工具数量大幅精简，不仅降低提示词工程的工作量，也显著提升系统的可预测性。
在谈及当下热门的 MCP 协议，Rod Johnson 给出了极理性的判断：
MCP 推动了 AI 工具生态发展，是优秀的行业催化剂，但并不是 “万能银弹”。对于企业应用而言，直接将现有 Java、Python 业务方法暴露为工具，远比额外对接 MCP 协议更简洁高效。各类 API 规范（OpenAPI、GraphQL 等）已经成熟，额外新增一层协议，反而会增加架构复杂度。
有人发出 “大模型持续进化，框架层是否会被淘汰” 的疑问，他认为不可能。大模型能力变强，和框架、编排层的价值并不冲突。企业业务流程自动化、流程可解释、运行确定性等核心需求长期存在，即便模型不断迭代，用于规范流程、管控逻辑的框架脚手架，依旧不可或缺。
五、开源商业模式：借鉴 Spring ，走 Open Core 路线
作为曾经缔造现象级开源项目的创始人，Rod Johnson 对 Embabel 的开源路线有着清晰的规划。项目主体采用与 Spring 一致的 Apache 开源协议，开放社区协作渠道，鼓励开发者提交 Issue 与代码贡献。
在商业模式上，Embabel 选择Open Core（核心开源、增值商业化） 模式。
纯服务支撑型开源模式在 AI 时代竞争力是有些弱化，因此团队计划以开源框架为基础，向上层延伸打造商业化产品。产品目标群体也不再局限于开发者，更多面向知识工作者，挖掘框架在业务场景中的深层价值。
回想 Spring 历经多次收购依旧保持生命力的原因，他总结出两大关键：
一方面项目早期就建立了庞大的生态与行业惯性，市场地位难以撼动；
另一方面，团队拥有大量全职专职维护人员，各类疑难问题、边缘 Bug 都能得到及时修复，而非单纯依靠社区志愿者。专业的商业团队支撑，是大型开源项目长久运转的重要保障。
六.直面行业热点，提出犀利观点
在视频访谈中，有一段是快问快答时间。我们总结如下：
- JVM 生态最被 Python 领域忽视的价值：不止是性能，更在于沉淀在代码中的
- 关于 MCP 的冷门观点：MCP 是优秀的生态工具，但行业如今陷入 “拿着锤子看什么都是钉子” 的误区，盲目套用反而增加架构负担。
- Java 开发者被要求转 Python：可以用实际代码案例对比两种语言的能力，证明 Java 完全能够胜任 AI 对接类业务。
- 生产项目选 LangGraph 还是 Embabel：Java 技术栈优先选择 Embabel，避免引入异构技术栈带来的风险。
- 新项目选 Java 还是 Kotlin：20 人以内小团队优先 Kotlin；大型团队若成员不熟悉 Kotlin，稳妥选择 Java。
- 日常主力 AI 工具：Claude Desktop，适用场景远比 Claude Code 更加广泛。
- Spring 的遗憾，将在 Embabel 优化：重构日志体系，采用基于事件的日志模式，支持流式监听、自定义日志风格。
- 五年后 Embabel 若消失，原因是什么：最大的可能性是行业彻底放弃人工架构设计，完全交由机器主导技术决策。
结语
AI 重构软件开发流程已经有扩大之势，它解放了开发者重复编码的体力劳动，也进一步放大了架构思维、全局设计、业务理解的价值。
Rod Johnson 在访谈中反复强调：工具可以迭代升级，但人的顶层把控能力，永远是技术项目的核心根基。
对于每一位技术从业者和开发者而言，在沉迷 AI 的编码效率的同时，还要深耕架构能力、更要沉淀业务认知。善用 AI 提效，守住技术内核，才能在技术大潮中牢牢站稳脚跟。
作者：洛逸
本篇文章为 @ 场长 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 微信公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。