Compiled by Yuqi | Edited by Tina
Rod Johnson is back on the front lines.
He created Spring, once nearly redefining how enterprise Java applications should be written. Over two decades later, he's founded a new startup and built an open-source framework for enterprise AI Agents called Embabel. His aim is to embed Large Language Models (LLMs) into real business systems, enabling them not just to call tools, but to work within controllable, explainable, and auditable processes.
Interestingly, while he's building a framework again, he's no longer as optimistic about the future of frameworks—or at least, not with the same old optimism. In his view, models will continue to improve, and tools will increasingly make choices for developers. Will a stronger model overtake Embabel? Do enterprises still need this type of harness? Will future frameworks be chosen by developers or automatically decided by AI tools? These questions all circle back to the statement he made in an interview: this might be the last wave of frameworks chosen by humans themselves.
Coming from anyone else, this might sound like just another exaggerated prediction in the AI era. But when it comes from the creator of Spring, it carries a different weight. Johnson personally witnessed the rise of the framework era and saw how a framework could become the infrastructure of enterprise software development. Now, returning to the battlefield, he believes the power of choice is shifting: developers may not disappear, but the era where they personally pick frameworks, build tech stacks, and decide a system's skeleton might be coming to an end.
This article is based on a podcast video transcript, edited by InfoQ.
Key takeaways:
If I'm doing model training, fine-tuning, or certain data processing and ingestion with TensorFlow, I'll absolutely use Python. But when it comes to enabling GenAI at the application layer, it's much better done in the application's native language. If the app is written in Java, do it in Java.
Once you get into complex applications, if you don't maintain architectural oversight, you'll quickly end up in a tangled mess. Your agent will happily add new features, but with each one, the design degrades and the code becomes awful.
Developers shouldn't spend a huge amount of time writing code because you can get far greater leverage by focusing on where you uniquely add value.
Every developer should, in principle, learn a new language every year or two, because it genuinely changes how you think.
This may already be the "last generation of frameworks actively chosen by humans." Increasingly, our tools will make technical choices for us.
1. Spring Founder Returns to Frontline Entrepreneurship
Simon: I was looking through your history and found you had a PhD on 19th-century Parisian piano music before you created Spring.
Rod: Yes, my first degree was a double major in music and computer science, and I couldn't decide which direction to go. Later, I got an Australian research scholarship for a music PhD and even taught music history at the Sydney Conservatorium of Music for two years. However, the urge to code never stopped. I wrote shareware in the mid-90s, and people actually sent checks.
Eventually, I soberly realized that if I stayed in music academia, I'd probably never be able to buy a house in Sydney. So I made a decision: one would be a hobby, the other a career—and I had them backwards at the time. But for the next decade, I barely touched the piano because my career was just too busy.
Simon: So it wasn't a strange detour or anything; it just happened that you're creative and enjoy both coding and music.
Rod: Since I first wrote code in the mid-80s, I've almost never stopped programming because I just love it. Even though the vast majority of my code is now written by an AI Coding Agent, I still get the exact same thrill, because the control is still in my hands. I'm still creating and shaping things. Even if I'm not personally typing every line, as long as the outcome is the same, it's equally satisfying.
Simon: After SpringSource was acquired, you spent many years on boards and investing. Then you founded Embabel. What made you think, "This is the moment, the timing is right"?
Rod: I think it's because the industry is at a massive inflection point. When GPT-3 and later ChatGPT suddenly became genuinely practical, no longer repeating themselves or going down strange dead ends, I immediately realized that figuring out how to actually use this technology to solve enterprise problems is a very hard problem. Even two years before that, out of personal interest, I had written quite a bit of TensorFlow code and dealt extensively with low-level AI technology. This naturally evolved into the idea of creating a framework to help solve these problems.
Simon: Speaking of enterprises, many teams are now being ordered to ditch Java and rewrite everything in Python. You've publicly said this is a mistake, and even stated, "This is the last year of Python's dominance in AI." Why?
Rod: When you're solving a business problem, you have to consider the "adjacency" of the problem itself. What are you dealing with? You're likely dealing with databases, enterprise services, and existing codebases. At the same time, you're dealing with a new thing: an LLM. But the LLM isn't running in your Python process—until the heat death of the universe, Python won't be able to perform inference itself. An LLM is just a very simple HTTP call. So, I've always been confused why people think a particular language has a natural advantage in making an incredibly simple HTTP call.
In fact, people are starting to realize this. OpenClaw wasn't written in Python; Peter Steinberger used his preferred language. For a vast number of enterprise applications, which are clearly written in Java, the critical adjacency is with the existing business logic and enterprise services. The obvious right approach is to make a simple HTTP call from your Java stack.
I think the root cause of this confusion is failing to distinguish "data science" from "enterprise AI applications." They're two completely different things. Before Embabel, I wrote a ton of Python; two years ago, my Python was much more fluent than my Java. If I'm doing model training, fine-tuning, or certain data processing and ingestion with TensorFlow, I'll absolutely use Python. But when it comes to enabling GenAI at the application layer, it's much better done in the application's native language. If the app is written in Java, do it in Java.
Simon: Embabel is written in Kotlin, right?
Rod: The Embabel core is almost entirely written in Kotlin. But most of our examples are in Java. We've invested heavily to ensure it's completely seamless for Java users—as you'd expect, the overwhelming majority of our user base is on Java. You won't see companion objects, `.kt` files, or anything weird. It's like very elegant, fluent Java. So when I work on the core framework, I use Kotlin; when I work on sample applications, I use Java. Honestly, the Java-style API is fantastic, and even when using the framework from Kotlin, the experience is similar to other languages.
Simon: And the integration is inherently seamless; you can just jump from Kotlin to Java.
Rod: About thirteen years ago, I used Scala heavily. I really liked Scala as a language, but the fact is, its integration with Java was painful. Every time you dealt with a collection, it was torture. Kotlin's creators did a fantastic job with Java interoperability; they didn't introduce the problems Scala had—breaking changes, lack of binary compatibility, and so on. So, yes, I find Kotlin a very pleasant language to use.
I also think it's important to point out that Java has improved a lot. I find it annoying when people use Java as a straw man to attack. Many people pretend Java hasn't evolved, but Java has, in fact, evolved significantly.
2. Coding Agents Are Destroying Your Codebase
Simon: You've previously talked about AI being forced in as a disconnected layer rather than being deeply integrated into existing systems, leading to some failure cases. What do you see as a genuine enterprise AI failure?
Rod: I think the biggest problem arises when high-level mandates like "AI everything" come down, and teams blindly launch AI projects without a real business case or confirming AI's suitability. A major anti-pattern is the "we need more AI" mindset without ever asking: why? For what? Even though I'm deeply passionate and fascinated by AI, if you can accomplish something without an LLM, you absolutely should. It's cheaper, more deterministic, and faster.
So, the first thing an organization must do is think, "How do we get from here to there?" For example, a client of ours in Australia initially identified a small class of problems: there was a specific form on a website that, once filled out, required manual review before proceeding. 95% of the cases were actually very simple—slightly awkward for regex, but essentially simple. They eliminated that friction point, allowing customers to proceed instantly in 95% of scenarios without waiting for a human. I think that's a fantastic starting case: get results on small things first, and gradually build trust.
Also, regarding the "Alien Stack" problem, it causes harm in two directions. First, technically, it makes everything harder. Second, it often hands strategic power to the wrong people—people who don't understand the core business, who may have never seen any core business application, yet are leading the strategy. When you need to empower these applications, that path is completely unworkable.
Last year, I spoke with the chief AI architect at a large Australian company; he was a Python developer. He listened politely to my introduction but wasn't very interested. At the end of the call, trying to be nice, he said, "I'm sure there's Java somewhere in our company; I'll go back and ask around." I'd never worked there, but as an industry insider, I knew very well that about 70% of that company's code was in Java, and the rest was .NET, which they were phasing out. This person had been there nearly a year and had never thought to ask, "By the way, what language is our software written in?" To him, it seemed irrelevant.
Simon: There's an increasingly common phenomenon: a huge disconnect is growing between us as developers and the code implementation actually being written, because we're over-relying on or delegating to AI, letting it make too many decisions and outsourcing too much. Much of the knowledge now resides with the AI, while we are abstracted away. How serious a problem do you think this is?
Rod: I think a core skill developers need to master is working in this new way while retaining control over what truly matters. You can certainly use Vibe Coding for some things, like certain types of UI applications that are inherently throwaway; agents are very, very good at that. But you cannot use Vibe Coding to write serious software.
I'm an active user of a Coding Agent; I probably write at most 5% of the code, maybe less, but I hold the controls firmly. I find that, from a design perspective, the agent is wrong more often than it's right.
We still need to understand architecture, know what's happening, and not be overly trusting. Because once you get into complex applications, if you don't maintain that architectural oversight, you'll quickly end up in a tangled mess. Your agent will happily add new features, but with each new feature, the design degrades, and the code becomes really bad.
Simon: You mentioned you write only 5% of the code, and the rest is AI-generated. Do you do that intentionally? Is it because you want more control over what's produced than writing more yourself?
Rod: In open-source projects, my hand-written ratio is higher; I might be more conservative. But in some of our internal applications, the AI-generated portion is close to 95%. If you read that code, you'd think I wrote it; the design style is very clear. I sit there looking at diffs and output, and I frequently stop to correct it: "No, you hardcoded this; it should be a strategy here, extract it."
I believe this model can potentially produce better results than either purely manual coding or purely relying on a Coding Agent. I write code far faster with a Coding Agent than manually, and the quality is also better. But if, conversely, I threw everything completely to the Coding Agent, I'm deeply convinced that quality would drop significantly, and ultimately, even speed would decline.
3. The Core of Embabel: From a Game NPC Planning Algorithm
Simon: Let's talk about a core component in Embabel, the "planner." It's a pathfinding algorithm called GOAP (Goal-Oriented Action Planning), originally designed for game NPCs, right? The key is, it's deterministic. Other frameworks like LangChain or Crew.ai rely more on the LLM to decide the next step and plan. Why did you pick this algorithm from the game NPC world?
Rod: The initial approach I considered was certainly the most obvious one—state machines. To be fair, LangGraph is deterministic; you define the state machine upfront. So I used that approach for a while too. But let's step back and talk about why planning is needed.
Of course, you can just throw a bunch of tools at a model and let an agent loop handle everything; in some scenarios, that's perfectly reasonable. But for automating business processes where consistency and predictability are needed, it's far from sufficient because you simply don't know in what order the LLM will call the tools you gave it, or what parameters it will pass to them.
So our idea is to let users break the process into multiple steps. These steps might involve calling one or more LLMs, or they might be pure code steps. At this level, LangGraph, Crew.ai, and Microsoft Semantic Kernel all do similar things—break down a big problem into smaller steps. This also means that if you use an LLM in a step, you can use different models for different needs. For example, you could use a local LLM behind your firewall for tasks that are small enough and highly sensitive, thus ensuring customer data never leaves the enterprise boundary. There are huge benefits here.
But the question comes back to: how do you plan these steps? How do you decide the execution order? You can use state machines, but I found that when I was doing LangGraph-like things, modifying a state machine—adding more states and transitions—was very cumbersome; you had to rewire things to extend it. Secondly, the state transitions and the types required for each action state are often orthogonal, which creates headaches for the type system.
The GOAP planning approach has two very different aspects. First, it's dynamic; planning happens 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 driven by the parameter types and return type of a Java method, meaning an action will never be called when a required parameter is missing.
GOAP is essentially an A* algorithm. We identify a goal and then look at what steps, from the current world state, can lead to that goal. Goals have preconditions—certain conditions in the world state that must be met. Actions also have preconditions and promised post-conditions. Preconditions are absolutely hard: unless the condition is met, you cannot declare the goal achieved, nor can you invoke the action. Post-conditions are the side effects the action promises to produce.
The planner starts from the current world state and finds a path to the goal. It can also tell you, "No actionable path exists," which is valuable information in itself. It then executes the first action and re-plans. After executing each action, it checks the world state and re-evaluates how to reach the goal. Most of the time, the happy path works as usual; the action's promised post-conditions are met, the planner confirms, and moves on to the next step.
Simon: Is this all automated?
Rod: Completely automated. Typically, a Java developer doesn't need to understand the planner's internal details. They just define "action methods" to provide inputs, annotate Java methods, and the method's parameters and return type give the planner the information for chaining calls. In some cases, you can also define custom conditions to further control the workflow. This means there may be multiple paths to the same goal, and the planner can choose the path with the lowest cost, because you can assign a cost to each action. Costs can even be dynamic; if an action needs to call a heavily loaded system, you can reflect that as a dynamic cost value, and the planner might then automatically choose another route.
Simon: Making dynamic decisions at runtime based on the current world state is very interesting. Another benefit, since it's deterministic, is that when asked, "Why was this decision made?" you can provide diagnostic information that a non-deterministic planner can't offer?
Rod: We can show the full path of the plan and how the observed world state led us to formulate that plan. The planner and the whole of Embabel emit a large number of events. You can write listeners to persist this information or use it for audit logs. So you can fully explain why it did something and also ensure it does the exact same thing every time.
Of course, once inside an action step, if you call an LLM, that part won't be completely deterministic. But this allows you to call the LLM "judiciously." If you're working like a chatbot with a three-page prompt and 30 tools, you can never achieve total predictability. But if you use a small prompt with three tools to accomplish one thing, predictability becomes very high. It won't be 100% certain, but you'll find the time spent on prompt engineering drops dramatically. So overall, the system becomes much more explainable, deterministic, and predictable.
4. Why the Skepticism Towards MCP
Simon: Everyone seems to treat MCP as a silver bullet, as if it can solve all of an Agent's problems. What gap do you think most developers haven't seen in this space?
Rod: I think MCP has played an extremely important role in enabling the ecosystem. It's been a catalyst, making more people aware of what you can achieve with tools. However, I hold a skeptical view of MCP for a few reasons.
First, if you're doing "AI-enabling enterprise systems," why would you run through MCP? You can use Embabel, Spring AI, or LangChain4J—any framework can easily expose a Java method as a tool. So you have to ask: if it's so easy to do, why jump through an extra hoop? Especially when you can expose tools on domain objects, where you first retrieve the correct domain object via a repository call and then expose methods on that object, which is something MCP doesn't do as easily. So very often, your first thought in exposing any tool should be: "Can I just expose it directly from my tech stack?" "Why don't I just directly expose a Java method or a Python function?" You can totally do that.
Secondly, MCP's selling point is that it's "an API specification designed specifically for Agents." But if it's an API specification, we already have OpenAPI, Swagger, GraphQL—why do we need a new one? MCP's argument is "because it's designed specifically for Agents." But I've recently come to the conclusion that the only thing perfectly suited for a specific agent is likely unique to that agent. For instance, you could have an MCP server to expose a service, but if an OpenAPI spec already exists, you could also connect to that spec and then shape your own tools based on the needs of your specific agent loop.
I think MCP has made a huge contribution to moving the industry forward, but it's not a one-size-fits-all solution. In many scenarios, using existing API specifications directly makes more sense, and the first approach should always be: expose logic directly from your current tech stack.
Simon: I remember Karpathy tweeting something along the lines of models are running ahead of the products being built on top of them. You're building the orchestration layer at Embabel. Does that mean you are, in a sense, already behind the models?
Rod: That's an interesting question. Of course, if you look at how we build software now, the planning capabilities of coding agents have improved far more significantly than I originally expected. Around late November, December last year, there was a truly dramatic leap. I think models are certainly getting better, but I also think many fundamental problems remain. If you're automating a business process, moving the planning outside the model's control and using some deterministic method—I think that still has value. Explainability remains important. So I genuinely believe that even as models continue to advance, the frameworks, agent harnesses, and various frameworks on top of them will remain very important.
A good example is Claude Code. Of course, Sonnet 4.6 is drastically better than previous models. But Claude Code itself is drastically better, too. If you compare Claude Code today to Claude Code four or five months ago, it works in a completely different way, and that difference genuinely makes it more effective. So I don't think there's a conflict between models getting smarter and harnesses getting smarter. I think we need to push forward in both places simultaneously.
I think you will see some scenarios where the model "eats the harness"—in places where determinism isn't that important. You can just give the model a bunch of tools, and even if it's a bit unpredictable, it's okay. So I do think there's a space where models will need less peripheral infrastructure. But I think that space isn't particularly relevant to enterprise applications.
5. AI is Good at Criticism, Not Originality
Simon: Back in January, you mentioned your Claude Code workflow involves a lot of design conversations: back-and-forth discussions with Claude Code, long planning sessions, and then coding starts, often producing better results than hand-writing. But Claude doesn't understand some things, like companion objects. So when you're building Embabel with Claude Code and Claude doesn't fully grasp parts of your architecture, how does that feel?
Rod: I think it works very well because I fully understand the architecture and I constantly correct it. I do wonder what happens if developers increasingly choose the easy path of not understanding the architecture. I'm in a very privileged position: I completely understand the architecture in the codebase, I'm very fluent in Kotlin, we build on Spring, and I know Spring well. I'm actually very familiar with every part of the tech stack, which enables me to effectively steer the ship. I would personally be very worried for those who don't understand these things. Keeping control is very important. I think developers shouldn't spend a huge amount of time writing code because you can get far greater leverage by focusing on where you uniquely add value.
Simon: Has AI ever surprised you, perhaps with a design or architectural suggestion you hadn't considered, that made you pivot in a completely different direction?
Rod: Not often. However, one thing that has been consistently useful is the back-and-forth discussion. There have definitely been multiple times when it thought of an issue I hadn't. For example, during a discussion about a proposed change, it pointed out something that hadn't occurred to me. It's better at criticism than at generating novel ideas.
Overall, I'm very satisfied, but there are moments of frustration. Over the past few days, I've been trying to build a fairly complex test infrastructure for an internal product, testing against real LLMs inside test containers, faking all the tools, etc., and Claude Code performed terribly. I think one reason is that it's probably never seen this scenario before; it might be a fairly novel form of testing.
To get the maximum autonomy out of your Coding Agent, you need to be obsessive about testing. And what I hit this time was both a more extreme volume of testing than it had seen, and certain types of testing it likely hadn't encountered before. Despite explicit instructions, it seemed surprisingly to struggle.
Simon: Have you tried guiding it using skills and context to help it offer suggestions closer to what you want?
Rod: I've tried configuring the Coding Agent's behavior using Skills and claude.md, but somewhat unfortunately, as the context grows larger, the Coding Agent starts forgetting things. There's one particularly odd phenomenon: it keeps wanting to write fully qualified names in the code body, which I really dislike; I much prefer using imports. I've written this preference into the claude.md configuration file, but it still forgets about 50% of the time.
Simon: Even if it's a mandatory instruction the Agent is supposed to read, it's not capable of incremental learning.
Rod: Right, the attention simply decays.
6. The Language Wars
Simon: I recall you once said TypeScript was the most important language today because it could double the level of an average JavaScript developer. Given you think TypeScript is more important than Java, how do you reconcile insisting on building on the JVM while believing TypeScript is the most important language?
Rod: TypeScript is a very clever language. It's interesting to see how the old static vs. dynamic typing divide is now somewhat converging. Modern Python heavily uses type hints, and Python's type system is quite decent now; TypeScript obviously adds a layer of types onto JavaScript.
TypeScript is a beautiful language, and it is genuinely important. But would I still say it's the most important? That depends on the application type. If I were writing many types of apps from scratch, I'd likely use TypeScript for both server-side and React. But look at enterprise applications; not many are written in Node, and they shouldn't be written in Node. On the JVM, Java and Kotlin give you a host of things that are immensely valuable for that class of application. TypeScript, however beautiful, doesn't help with that.
So I think, first, modern Java is certainly much better than when I made those statements; second, Kotlin is an outstanding language worth serious consideration. Kotlin and TypeScript are roughly on par. I still miss union types—I could argue at length that sealed hierarchies are absolutely inferior to union types—but Kotlin has plenty of areas where it's stronger than TypeScript. Another problem with TypeScript is that, despite them doing a great job, there's still a layer of madness underneath that you occasionally bump into, which can't be hidden. Kotlin is a modern language built on a more robust, predictable foundation.
Simon: Do you think AI advances will change this language landscape in five years? Is there enough change to overturn these established realities?
Rod: I don't know what my view is; I can persuade myself that languages don't matter, and I can also persuade myself that they do.
First, the picture many people imagine—that training corpora will give popular languages a natural advantage, and then that advantage will be locked in—is absolutely wrong. The three languages I use a Coding Agent with are Java, Kotlin, and Python, and without question, the language the Coding Agent performs best in is Kotlin, which completely defies your expectations.
Think about it: Java and Python have both existed for a long time and have evolved very fast in recent years. You shouldn't be writing 2019 Java, and you certainly shouldn't be writing 2019 Python. There's so much training data that you can say, "Always use value types," "Always use enhanced switch statements," "Always use type hints in Python," but precisely because the training data volume is so vast, you're actually fighting against it. I'm not saying they're bad; Java and Python are still very good.
But Kotlin is better, which really surprised me, because Kotlin's corpus isn't large. First, Kotlin itself hasn't evolved that much because it was a modern language from the start. Second, early Kotlin adopters were very likely highly skilled people, so there isn't that much bad Kotlin code out there, unlike with Java or Python.
So, I don't believe popular languages become locked in due to training data. LLMs are incredibly good at anything they've seen enough of, and they've seen a huge amount of every programming language we've heard of. But this then raises the question: if so, why don't you write everything in the perfect language? As we said before, there are things I'd never write in Python but would write in Java. If an LLM is a master-level expert in every language, why not pick the most ideal language for each service? Use Rust for this service, Go for that one. (Though I don't think there's anything left worth writing in Go now.)
The problem is, it's like the microservices mania we once saw—there are other costs. You'd now be introducing an enormous maintenance overhead, unless we're willing to completely trust our machines. But I don't think we should do that; I don't think that's a good idea.
Simon: And there's the skill issue. The diversity of tech stacks alone, and the need for people to maintain them, is headache enough. Plus security—every new language or library you introduce multiplies the threat surface area, and these risks spread across languages.
Rod: At least for now, the fundamental reasons we choose languages and tech stacks likely won't change much. Because when you push them into production and vouch for them, those fundamental things haven't changed.
7. Open Source Survival Rules
Simon: You've previously mentioned that a company behind an open-source project needs a business model from day one. What does that look like for Embabel?
Rod: The most likely model is open core. I think a pure open-source support model has always been very difficult, and with Coding Agents, it will be far harder. So I think there will be products built on a layer above the framework. Our current thinking is to use the framework as a competitive advantage to build products that might not even target software developers, but rather a broader set of knowledge workers. The framework itself is Apache-licensed, the same as Spring. We welcome community contributions; we have an active Discord, GitHub, and issue tracker, and we welcome anyone interested to contribute and join the community.
Simon: Spring has gone through acquisitions by VMware, Pivotal, and now Broadcom. What do you think allowed it to survive these acquisitions? Many open-source projects wither or die after being acquired.
Rod: I think by the time that first acquisition happened at the end of 2009, Spring was already a behemoth; it was already the de facto standard. The early adoption rate and the community built around it clearly had immense inertia.
But what helped was that a significant number of highly skilled developers were employed full-time to work on Spring. That meant less exciting things also got fixed because it was part of someone's job, whether they were interested or not. I still firmly believe open source genuinely benefits from having commercial backing behind it. What made Spring reliable—the fact it's very robust, any serious problem gets fixed quickly—partly reflects that we don't depend on volunteers. Community contributions are, of course, great, but I think that professionalism behind it is crucial; it gives that complete product-style development approach.
8. "This is the Last Wave of Frameworks People Choose"
Simon: What do you think is the most underrated thing about the JVM? What does the Python world have no idea it's missing?
Rod: Performance is certainly one aspect. But the more serious answer is: the code running on it—the business logic, the domain models—holds an incalculable value for understanding the key business.
Simon: Do you have an unpopular opinion about AI Agents?
Rod: I hold a relatively skeptical view of MCP. It's not that I think MCP is bad, but I think people have made MCP the "universal hammer" and are now treating everything like a nail.
Simon: If a Java developer is told by their boss, "Go learn Python, because AI needs Python," what advice would you give them?
Rod: I'd tell them to go read my blog. I wrote a series of articles comparing Python and Java implementations on exactly the same tasks—file processing, API calls, data pipelines. The results are very clear: Java code is completely competitive with Python in performance, readability, and ecosystem maturity. You can simply forward one of those articles to your boss, or even better, write a snippet yourself. Very often, you'll find Java's code competitiveness is actually not bad at all.
Simon: For a project already running in production online, would you choose LangGraph or Embabel?
Rod: Is it a Java project or a Python project? If it's a Java project, I'd definitely choose Embabel. Otherwise, you're forcefully wedging an "Alien Stack" into your system. Embabel is now at 0.3.5; it's actually very close to API stability. I'd be surprised if there were any major breaking changes from now to 1.0; I estimate it's about four to six weeks away from 1.0.
So honestly, I don't see adopting Embabel now as a high-risk move. Conversely, if I had a Java project and had to introduce a completely different tech stack and then hook it up to my existing Java business logic, I'd see that as far riskier. By the time you've wrestled all that into place, Embabel might already be at 1.0, and you'll just be kicking yourself, thinking, "Why on earth did I do it that way?"
Simon: Launching a brand-new enterprise project today: Kotlin or Java?
Rod: It depends on the team size. If the team is fewer than 20 people, I'd seriously consider Kotlin. If the team is larger and they aren't already familiar with Kotlin, I'd probably stick with Java.
Simon: Back in the day, the learning curve for a Java developer moving to Scala was fairly steep. Is Java to Kotlin still that difficult?
Rod: Honestly, I'm not entirely sure, because when I picked up Kotlin, I'd already written a lot of other languages, particularly Python. I did write Java for a few months, but then went back to Kotlin. So I'm not someone coming from a "pure Java background." I can say definitively, though: Kotlin is absolutely easier to learn than Scala. Kotlin itself is quite an easy language to pick up.
And there are two more things I've always believed in. First, I think every developer should, in principle, learn a new language every year or two, because it genuinely changes how you think. Second, the barrier to learning a new language is unprecedentedly low now. An LLM can help you pick up any language incredibly quickly, so the overall threshold has been massively lowered. For example, I never read a Kotlin tutorial book.
Simon: You just mentioned using an LLM to critique code, which can sometimes be more valuable than having it "directly generate." I've felt the same, especially when learning a new language. Asking the LLM to explain "why it's written this way here" or "what's the mechanism behind it" is often far more effective than just saying, "Help me generate a piece of code." Otherwise, you're just left guessing about the result: "Why did it write it that way?"
Rod: Especially for experienced developers. When I'm learning a new language, I often ask the LLM, "Does this language have an equivalent implementation for a certain feature?" For instance, I'd ask: is there something like a TypeScript type guard in Python? If you already understand these concepts, the LLM is particularly good at mapping those concepts across to another language.
Simon: What's your favorite AI tool that you use every day, besides Claude Code?
Rod: Most likely, it's still Claude Desktop. Mainly because it lets me invoke a bunch of tools simultaneously for competitive research; I handle a lot of things with it.
Simon: Regarding Spring, is there anything you later felt you did wrong? If you had to redo it, would you do anything differently in Embabel?
Rod: There's a minor but, I think, quite interesting point. For years, I wanted to retrofit Spring with an "event-based logging mechanism," but by then, it was too late; the architecture couldn't be easily changed. However, in Embabel, we designed it that way from the start. The benefit is: all events are complete. You can stream them out over SSH, you can listen, you can subscribe. And what's even more fun is that we can even modify your "logging personality," for example, making all your logs output in the tone of Master Yoda.
To some extent, Embabel's overall style is built on the experience of modern Spring, but with some additions that are easier to implement in Kotlin. For instance, we hardly use the builder pattern, because Kotlin can express these things more elegantly, even when the result is ultimately for Java users.
Simon: If Embabel doesn't exist in five years, what do you think killed it?
Rod: I have absolutely no idea whether Embabel will still exist in five years. In five years, will people still be writing applications by hand? Or did they, against my advice, let the machines take over completely? I'd even go so far as to say: this may already be the "last generation of frameworks actively chosen by humans." Increasingly, our tools will make technical choices for us. But honestly, we are in an almost unique era. Forget five years; a prediction even one or two years out could be wrong.
Original Interview Video Link:
https://www.youtube.com/watch?v=UcvxYltiS7E
Disclaimer: This article is a translation and adaptation by InfoQ and does not represent the platform's views. Unauthorized reproduction is prohibited.