The founder of Spring has returned to the front line to work on an AI framework, stating, "This is the last generation of frameworks that humanity has personally chosen."

Rod Johnson is back on the front line.

He is the creator of Spring, who once almost redefined how enterprise Java applications should be written. More than two decades later, he started a new business and developed an open - source framework called Embabel for enterprise AI agents. He aims to integrate large language models (LLMs) into real - world business systems, enabling them not only to call tools but also to operate within controllable, interpretable, and auditable processes.

Interestingly, this time he is still working on a framework, but he is not optimistic about the future of "frameworks," at least not as optimistic as before. In his view, models will continue to improve, and tools will increasingly make choices for developers. Will Embabel be outpaced by more powerful models? Do enterprises still need such a harness? Will future frameworks be selected by developers or automatically determined by AI tools? These questions all revolve around the statement he made in the interview: This might be the last wave of frameworks manually selected by humans.

If someone else said this, it might just be another exaggerated judgment in the AI era. However, coming from the founder of Spring, it holds a different meaning. Since Rod Johnson was personally involved in the rise of the framework era and witnessed how a framework became the infrastructure for enterprise software development. Now, he has returned to the battlefield but believes that the power of choice is shifting: Developers may not disappear, but the era when developers personally select frameworks, build technology stacks, and determine the system's structure may be coming to an end.

This article is based on the podcast video and edited by InfoQ.

The core viewpoints are as follows:

• If I use TensorFlow for model training, fine - tuning, certain data processing, and ingestion, I will of course use Python. However, enabling the application layer of generative AI is more suitable to be done in the original language of the application. If the application is written in Java, then do it in Java.
• Once you enter a complex application, if you don't maintain architectural supervision, you'll quickly get into a mess. Your agent will happily add new features, but with each new feature added, the design will degrade, and the code will become very poor.
• Developers shouldn't spend a lot of time writing code because you can gain more leverage by focusing on where you can add unique value.
• In principle, every developer should learn a new language every one or two years because it really changes your way of thinking.
• This might already be "the last generation of frameworks actively selected by humans." In the future, more and more technology selections will be made by our tools for us.

The Founder of Spring Returns to the Front Line for Entrepreneurship

Simon: When I looked through your resume, I found that before creating Spring, you had a doctorate in 19th - century Parisian piano music.

Rod: Yes, my first degree was a double major in music and computer science. At that time, I couldn't decide which direction to take. Later, I got a research scholarship in Australia to pursue a doctorate in music and taught music history at the Sydney Conservatorium of Music for two years. However, the urge to write code never stopped. In the mid - 1990s, I even wrote some shareware, and people actually sent me checks.

Later, I realized clearly that if I continued in the music academia, I probably wouldn't be able to afford a house in Sydney in my lifetime. So I made a decision: One of these two things would be a hobby, and the other would be a career - and I got it the wrong way around at that time. However, I hardly touched the piano for the next ten years because my career was too busy.

Simon: So this isn't some strange detour or anything. It's just that you're very creative and enjoy both writing code and music.

Rod: Since I first started writing code in the mid - 1980s, I've almost never stopped programming because I love it. Even though most of the code is now written by AI coding agents for me, I still get the same excitement because I'm still in control and still creating and shaping things. Even if I don't type out every line by hand, as long as the result is the same, it's equally satisfying for me.

Simon: After SpringSource was acquired, you spent many years on board and investment matters and then founded Embabel. What made you think "this is the right time"?

Rod: I think it's because the industry is at a major turning point. When GPT - 3 and later ChatGPT suddenly became truly useful and stopped repeating themselves or getting into strange dead - ends, I immediately realized that it's a difficult problem to use this technology to solve enterprise problems. In fact, two years before that, out of personal interest, I had written a lot of TensorFlow code and dealt with underlying AI technologies a great deal. This naturally evolved into the idea of creating a framework to help solve these problems.

Simon: Regarding enterprises, many teams are now required to abandon Java and rewrite everything in Python. You've publicly said this is wrong and even said "this is the last year of Python's dominance in the AI field." Why?

Rod: To solve a business problem, you must consider the "adjacency" of the problem itself. What are you dealing with? Most likely, you're dealing with databases, enterprise services, and existing codebases. At the same time, you also have to handle a new thing: the LLM. But the LLM doesn't run within your Python process - Python won't be able to perform inference on its own until the end of the universe. The LLM is just a very simple HTTP call. So I've always been confused as to why people think a certain language has a natural advantage when making an extremely simple HTTP call.

In fact, people are gradually realizing this. OpenClaw isn't written in Python. Peter Steinberger used his preferred language. For a large number of enterprise applications, they are obviously written in Java, and the key adjacency lies in the existing business logic and existing enterprise services. So the obvious correct approach is to make a simple HTTP call from your Java stack.

I think the root cause of this confusion is that people don't distinguish between "data science" and "enterprise AI applications." They are two completely different things. Before Embabel, I wrote a lot of Python. Two years ago, I was even more fluent in Python than in Java. If I use TensorFlow for model training, fine - tuning, certain data processing, and ingestion, I will of course use Python. However, enabling the application layer of generative AI is more suitable to be done in the original language of the application. If the application is written in Java, then do it in Java.

Simon: Embabel is written in Kotlin, right?

Rod: The core of Embabel is almost entirely written in Kotlin. However, most of our examples are in Java. We've invested a lot of effort to ensure that it's completely seamless for Java users - as you'd expect, the vast majority of our user base uses Java. You won't see companion objects, `.kt` files, or anything strange. It's like very elegant and fluent Java. So when I work on the core framework, I use Kotlin; when I work on example applications, I use Java. Honestly, the Java - style API is very good. Even when using this framework in Kotlin, the experience is similar to that of other languages.

Simon: And the integration between them is seamless. You can directly switch from Kotlin to Java.

Rod: About thirteen years ago, I used Scala a lot. I like the Scala language, but the fact is that its integration with Java is painful. Every time you deal with a collection, it's a torture. The creators of Kotlin have done an excellent job in Java interoperability. They didn't introduce the problems that Scala had, such as breaking changes and lack of binary compatibility. So, yes, I think Kotlin is a very useful language.

However, I also think it's important to point out that Java has improved a lot. I find it annoying that people like to use Java as a scapegoat. Many people pretend that Java hasn't evolved, but in fact, it has evolved a great deal.

Coding Agents Are Ruining Your Codebase

Simon: You previously mentioned that AI is basically being forced in as a disconnected layer rather than being more deeply integrated into existing systems, which has led to some failure cases. What do you think a real enterprise AI failure case looks like?

Rod: I think the biggest problem is that when senior management issues an "AI - everything" directive, teams blindly start AI projects without a real business case or confirming whether AI is suitable. A major anti - pattern is the idea of "we must use more AI" without ever asking: Why use it? What for? Although I'm very passionate and fascinated by AI, if you can complete a task without using an LLM, you should of course not use it. It's cheaper, more certain, and faster.

So the first thing an organization should do is think about "how do we get from here to there." For example, one of our customers in Australia initially identified a small problem: There was a specific form on their website, and after customers filled it out, it needed manual review to proceed. In 95% of cases, it was actually very simple. Although it was a bit troublesome to handle with regular expressions, it was essentially simple. So they eliminated this friction point and allowed customers to proceed immediately in 95% of scenarios without waiting for manual processing. I think this is a great starting case: Get results on small things first and gradually build trust.

In addition, the "alien stack" problem causes harm in two directions. First, it makes everything technically more difficult. Second, it often hands strategic power to the wrong people - those who don't understand the core business at all and may have never seen any core business applications are leading the strategy. When you want to empower these applications, this approach won't work at all.

Last year, I talked to the chief AI architect of a large Australian company. He was a Python developer. He politely listened to my introduction but wasn't very interested. At the end of the call, he tried to be friendly and said, "I'm sure there's Java somewhere in our company. I'll go and ask." I've never worked at that company, but as an industry insider, I know very well that about 70% of the company's code is written in Java, and the rest is in.NET, and they're gradually phasing out.NET. This person had been in the company for nearly a year but never thought to ask, "By the way, what language is our software written in?" It didn't seem important to him at all.

Simon: There's an increasingly common phenomenon where we, as developers, are experiencing a huge disconnect from the actual code implementation. Because we over - rely on or authorize AI to make too many decisions and outsource too much. A lot of knowledge is actually on the AI side, and we're being abstracted away. How serious do you think this problem is?

Rod: I think a core skill that developers need to master is to work in this new way while retaining control over what really matters. You can use Vibe Coding for some things, such as certain types of UI applications, which are often one - off, and agents are very good at this. But you can't use Vibe Coding to write serious software.

I'm an active user of coding agents. I may write at most 5% of the code, maybe even less, but I firmly hold the control. I've found that from a design perspective, agents make more mistakes than they get things right.

We still need to understand the architecture, know what's going on, and not be overly trusting. Because once you enter a complex application, if you don't maintain architectural supervision, you'll quickly get into a mess. Your agent will happily add new features, but with each new feature added, the design will degrade, and the code will become very poor.

Simon: You mentioned that you only write 5% of the code, and the rest is generated by AI. Did you do this on purpose? Is it because you don't want to write more and want more control over what's written?

Rod: In open - source projects, the proportion of code I write by hand is higher, and I may be more conservative. However, in some of our internal applications, the proportion of code generated by AI is close to 95%. If you read that code, you'd think it was written by me, and the design style is very clear. I'll sit there and look at the diffs, look at the output, and often stop to correct it: "No, you hard - coded this. It should be a strategy. Extract it."

I believe this model can potentially produce better results than pure manual coding or relying solely on coding agents. I write code with a coding agent much faster than I can manually, and the quality is also better. However, if I completely hand everything over to a coding agent, I'm convinced that the quality will decline significantly, and eventually, the speed will also slow down.

The Core of Embabel: A Game NPC Planning Algorithm

Simon: Let's talk about the core component "planner" in Embabel. This is a path - finding algorithm called GOAP (Goal - Oriented - Action - plan), which was originally designed for NPCs in games, right? The key point is that it's deterministic. Other frameworks like LangChain and Crew.ai rely more on the LLM to decide what to do next and how to plan. Why did you choose this algorithm from the game NPC field?

Rod: What I initially considered was the most obvious approach - the state machine. To be fair, LangGraph is deterministic, and you define the state machine in advance. So I also used that method for a while. However, let's take a step back and talk about why we need planning.

Of course, you can just throw a bunch of tools at the model and let an agent loop handle everything. In some scenarios, this is indeed reasonable. However, for automated business processes that require consistency and predictability, this is far from enough because you have no idea in what order the LLM will call the tools you give it, or what parameters it will pass to those tools.

So our idea is to let users break the process into multiple steps. These steps may involve calling one or more LLMs or may be pure code steps. At this level, LangGraph, Crew.ai, and Microsoft Semantic Kernel all do similar things - break the big problem into small steps. This also means that if you use an LLM in a certain step, you can use different models for different needs. For example, you can use a local LLM behind your firewall to handle small and highly sensitive tasks, so that customer data never leaves the enterprise boundary, which has a lot of benefits.

But the question comes back to: How to plan these steps and how to determine the execution order? You can use a state machine, but I found that when I was doing something similar to LangGraph, modifying the state machine, such as adding more states and transitions, was very troublesome. You had to re - wire it to expand it. Second, the state transitions and the types required for each action state are usually orthogonal, which creates problems in the type system.

The GOAP planning method has two very different points. First, it's dynamic, and the planning occurs at runtime. Second, it's fully integrated with the type system. We allow users to create custom conditions, but the ordering of actions is usually determined by the parameter types and return types of Java methods, which means an action will never be called when the required parameters are missing.

GOAP is essentially an A* algorithm. We identify the goal and then see which steps can lead to the goal from the current world state. The goal has pre - conditions, and certain conditions must be met in the world state. Actions also have pre - conditions and post - conditions they promise. Pre - conditions are absolute and hard. Unless the conditions are met, you can't claim that the goal has been achieved, and you can't call an action. Post - conditions are the side - effects that an action promises to produce.

The planner starts from the current world state and finds a path to the goal. It may also tell you "there is no actionable path," which is valuable information in itself. Then it executes the first action, re - plans, and after each action is executed, it checks the world state and re - evaluates how to reach the goal. In most cases, the happy path will work as normal. The post - conditions promised by the action are met, the planner confirms, and then moves on to the next step.

Simon: Is all of this automated?

Rod: Completely automated. Usually, Java developers don't need to understand the internal details of the planner. They just need to define "action methods" to provide input and annotate Java methods. The parameter and return types of the methods provide the planner with information for chained calls. In some cases, you can also define custom conditions to further control the workflow. This means there may be multiple paths to reach the same goal, and the planner can choose the path with the lowest cost because you can assign a cost to each action. The cost can even be dynamic. If an action needs to call a highly loaded system, you can reflect it as a dynamic cost value, so the planner may automatically choose another route.

Simon: Making dynamic decisions at runtime based on the current world state is very interesting. Another benefit is that because it's deterministic, when asked "why was this decision made," you can provide diagnostic information that non - deterministic planners can't?

Rod: We can fully show the entire planning path and