# Enterprise AI Strategy: Java, Determinism, and Agent Control

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-05-05

## Transcript

I think it's completely nonsensical.
The LLM is not running in your Python process.
The universe would end before Python could execute inference.
So the LLM is a very, very simple HTTP call away.
So it's utterly baffling to me that people think any particular language has a natural advantage to make what is an incredibly simple HTTP call.
OpenClaw is not written in Python.
In the case of many enterprise applications, they're obviously written in Java.
The critical adjacencies are existing business logic, existing enterprise services those applications interact with.
And it's quite obvious the correct thing to do is simply make the very simple HTTP calls from your Java stack.
The AI Native Dev is a podcast for developers and engineering leads at the cutting edge of AI and agentic coding.
Join your hosts Guy Pajani and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
This is the AI Native Dev.
Back in November, we hosted the first ever in-person AI Native DevCon in New York.
This June 1st and 2nd, we're bringing it to London.
It's two days built for AI Native developers and engineering teams.
One day full of hands-on workshops and one day full of practical talks on agent skills, context engineering, agent orchestration and enablement platforms, and how teams are actually shipping AI in production.
Join us at the brewery in London near the Barbican for all of that, plus networking, parties, giveaways, and a room full of people building the future of AI native development.
You can also join us from anywhere in the world via the live stream.
As you're listening to this podcast, you get 30% off your ticket with code POD30.
Just head to AI Native DevCon.io and we'll see you in London.
Hello and welcome to another episode of the AI Native Dev Podcast.
And we've got a special episode actually because one of my...
One of my heroes, fellow Java champions, Rod Johnson, creator of Spring, the founder and CEO of Mbabel, joins me here today.
So, Rod, a very special welcome.
Thank you, Simon.
It's good to be here.
Excellent.
And, of course, you're from Australia, Norman, right?
Yes, I now live, again, in Sydney, but I actually lived in London for seven years.
Oh, wow.
So when I created Spring, most of the early years of what became Spring Source, I was in London.
Amazing.
And then I lived in the Bay Area for another few years after that.
Yeah, yeah, because I guess in the...
Early, early, early days, I guess, Spring Source, Interface 21 at one point as well.
It was.
Interface 21 was the first company name.
I remember back then I was at IBM and a number of the folks, Andy Wilkinson and folks like that, kind of like moved over and joined.
And that was, there was an office, I think, close by there.
Was it Romsey Way or something?
Southampton.
Southampton.
It was a strange accident that that office was in Southampton.
Yeah, I can imagine.
I can imagine.
Yeah, we like to think about, you know, liberating people.
So we liberated Andy.
and a few other really good engineers from IBM.
And still there, I know.
Yeah, yeah, yeah.
He's doing great stuff.
I mean, look, one of the amazing things about, I think, the spring story has been the retention of folk for that length of time.
I mean, primarily among them, of course, Jürgen.
Like Jürgen Herler joined the spring project in early 2003.
And I would say he has worked full time on spring since...
probably May 2003.
And Jürgen did well out of the acquisition.
And it is what he wants to do.
And he does it exceptionally well.
I think it's a wonderful thing for the Java community.
Yeah, incredible.
And so for you personally, I was looking a little bit back over your history.
And there was one super interesting kind of backstory that very much surprised me.
But it kind of made me very, very curious.
You, as well as obviously, well, before spring, you have a PhD in 19th century Parisian piano music.
Yes, that is true.
I am a pianist and my first degree was a major in both music and computer science.
And I really couldn't decide which one I wanted to go.
on with.
And then I got a very generous Australian post-graduate research award to do my PhD in music.
So I did that.
And actually I taught at the Sydney Conservatory of Music.
I taught music history for a couple of years.
But I always still had this desire to write code.
So I actually wrote some shareware.
Back in the mid-90s when that was a thing, I wrote some Windows shareware that was moderately successful and people actually wrote checks that arrived in the mail.
It was quite a surprise that people actually sent checks.
And then, you know, I eventually decided that if I stayed a music academic, I couldn't see how I could ever afford a house in Sydney.
And so that's when I decided, okay, one of these should be a hobby.
and one of them should be my career, I've got it the wrong way around.
And then, of course, sadly, I didn't play the piano for 10 years because I was so busy in my career.
So it wasn't a weird detour or anything like that.
It just happened to be you're very creative, whether it's code, whether it's music, and you just enjoyed both.
Yeah, look, I think since I first wrote code probably now in the mid-'80s, I don't think there's ever been very long that's gone when I haven't written code because I just still keep coming back to it and I love it and it's one of the things I find most enjoyable.
And interestingly, even though now obviously I don't write most of my code because coding agents write most of my code, I still get the same buzz because I'm still in control, I'm still creating and shaping something.
So it's just as satisfying to me if I achieve the outcome if I don't.
type, most of the code.
Yeah, amazing.
So post Spring Source, Spring Source were acquired for about 20 odd years or so maybe.
You were doing more on boards, doing investments, things like that.
And then you launched in Babel.
What kind of did you see that made you feel, you know, this is the moment, this is the thing that's worth building right now?
I think it is the fact that we're at such an inflection point.
in the industry.
So it seemed to me as soon as that amazing moment happened when I think it was GPT-3, chat GPT, suddenly became useful.
Suddenly stopped repeating itself and going down a weird rat hole and was clearly useful.
And I found it a fascinating problem of how do we make this useful for business?
And it's a pretty hard problem.
So that was a very strong motivation.
And it, I'd actually been, for my own pleasure, probably in the last two years before that, writing a ton of code, where I'd actually, for a personal project, got into TensorFlow and quite a lot of low-level stuff.
So I was already very interested in the AI space.
And it just naturally morphed into trying to create a framework to help solve these problems.
Interesting.
And I guess when we look at enterprises today, Many teams are being told to almost abandon Java to rewrite in Python.
And I think, you know, you wrote about this, that, you know, this is wrong.
This is the last year of Python dominance in AI.
You're saying that's the wrong weave?
Why would you say that's the wrong weave?
I agree, by the way, but why would you say that's the wrong weave?
I think it's completely nonsensical because I think if you have a business problem, you need to consider the adjacencies of that problem, right?
Like you're solving a business problem.
What are you working with?
You're working probably with a database, enterprise services, an existing code base.
You're also working with something new, which is LLMs.
Well, if you consider those adjacencies, the LLM is not running in your Python process.
I mean, like we literally...
you know, the universe would end before Python could execute inference.
So the LLM is a very, very simple HTTP call away.
So it's utterly baffling to me that people think any particular language has a natural advantage to make what is an incredibly simple HTTP call.
And I think people are gradually getting that.
Like, for example, if you look at OpenClaw.
OpenClaw is not written in Python.
Yeah, there's absolutely...
I guess Peter Steinberger wrote it in the language that he preferred.
So in the case of many enterprise applications, they're obviously written in Java.
The critical adjacencies are existing business logic, existing enterprise services those applications interact with.
And it's quite obvious that the correct thing to do is simply make the...
very simple HTTP calls from your Java stack.
Now, I think one of the reasons people think this is the confusion between data science and AI and business applications, and they're entirely different things.
For example, I had written prior to returning to Java within Babel, I'd written it.
ton of Python.
Actually, believe it or not, probably two years ago, my Python was far more fluent than my Java.
If I were using, as I was earlier than that, if I was using TensorFlow, I would do it in Python.
If I were fine tuning, doing certain kinds of model training, I'd certainly do it in Python.
Certain kinds of data processing and ingestion, I'd do in Python.
So my point is fundamentally that you should in any task, do it in the language that's most appropriate for that task.
These Gen AI enablement of apps, that problem is a task that's much better done in Java where the app is already written than in Python.
Absolutely.
And, of course, in Babel is...
Written in Kotlin, I think, right?
It is nearly all written in Kotlin.
Most of our examples are Java.
And we put a lot of effort into making sure that for Java users, it's completely seamless.
So like the vast majority of our user base, as you'd expect in Java.
And you will not see a companion, a KET.
You won't see anything that's weird.
It's like really nice, fluent.
Java.
So yeah, I find that when I work on the core framework, I'm working in Kotlin.
When I work on example applications, I'm working in Java.
And to be honest, the Java-flavored APIs are so nice that even in Kotlin, like when you're using the framework, it's actually pretty much the same in other languages.
Yeah, yeah, absolutely.
And the integrations between are pretty seamless anyway that you can actually dip from Kotlin straight into Java anyway, right?
Oh, absolutely.
Like, I mean, I think probably maybe a bit over 10 years ago, I spent a lot, actually, no, probably more like 13 years ago, did a lot in Scala.
Yep.
And I loved Scala as a language, but the fact was the integration with Java was painful.
Like every time you had a collection, for example, it was misery.
I think the...
Creators of Kotlin have done an amazing job with Java Interop, and also they don't introduce the problems like the breakage, lack of binary compatibility, et cetera, that Scala had.
So, yeah, I find Kotlin a really nice language to work in.
Though I think it is also important to point out that Java has improved a lot.
You know, I do find it very annoying that people love...
they're Java straw man.
So, you know, a lot of people out there are pretending that Java has not evolved and Java has actually evolved a lot.
I have this argument with Guy Pod every, every day.
He always calls Java a very ancient kind of like tool.
I think he's just trolling me though.
But let's talk a little bit about actually a couple of months ago, maybe actually, gosh, it's probably only a few weeks ago.
I think we were both in Atlanta and you gave a closing keynote for...
DevNexus.
DevNexus, that's right, yeah.
And...
And you talked a little bit about how AI is essentially almost bolted on as a disconnected layer.
And as a result, rather than being integrated more into the existing systems.
And as a result, it causes some of the more failure cases as a result.
Walk us through what you see as like a real enterprise AI failure case from your opinion.
I think the biggest problem is where there is a mandate to AI all the things.
And it comes down from the very top.
And people are doing AI projects without really a business case, without really being sure that AI is appropriate for this.
So I think one of the major anti-patterns is this idea of we must use more AI without like, why?
What for?
Because much as I love and am fascinated by AI, if you can do any single thing without using an LLM, well, of course you do it without using an LLM.
It's way cheaper.
It's more deterministic.
It's faster, right?
There's like every single metric you can think of is going to be better.
So, you know, I think the first thing that organizations need to do is kind of think of how do we get there from here?
So think about, for example, one of our customers in Australia have started by identifying small things where, for example, it was one particular form where if a customer filled in that form on their website, it required a person to evaluate what they'd said.
95% of those cases were really simple things.
They were a little bit too complex to like parse with regular expressions or whatever, but they were pretty simple things.
So, you know, they've been able to remove that friction and give in the 95% case, give their customer instant ability to move forward without waiting on an employer.
And those, I think, are very good examples of where you can start and gradually put runs on the board, build more.
confidence.
Another problem is, as you mentioned, the alien stack problem.
So because that hurts in two ways.
Firstly, technically, it makes everything harder.
And secondly, it often means the wrong people drive the strategy.
So you have people who don't understand the core business, have never seen any of the core business applications who are driving the strategy.
And that really doesn't work when you need to enable those applications.
Like I had a chat sometime last year with the lead AI architect at a very, very large Australian company who was a Python guy, listened politely, wasn't very interested.
And at the end of the call, I guess, trying to be nice, he said, I'm sure we've got Java somewhere I'll ask around.
I've never worked for that organisation, but...
Basically, I'm well aware, as most people would be in the industry in Australia, that about 70% of it is written in Java.
The remainder is .NET, and they're phasing that out in favor of Java.
And this person had been in their job for almost a year.
It had never occurred to them to go and ask, by the way, what do we write our software in?
Apparently not important.
I just don't have a good feeling about how that's going to play out.
And of course, that happens more and more now where we see so much of a disconnect or so much of a disconnection between us as developers and the code, the implementation that we actually write, because there's almost an over-reliance or an over-agency on us using AI that it's making so many of the decisions and we're offloading so much of that.
A lot of the knowledge actually is on the AI side or rather on the implementation side, which we are.
abstracted away from.
How much of a problem do you see that as?
I think it's a fascinating question.
I think one of the skills that developers need to master is working in this new way and retaining the control that matters.
I do believe that you can vibe code things like, you know, some classes of UI apps, sure, they're disposable anyway.
agents are very, very good at that.
You cannot vibe code serious software.
And I am a vigorous user of coding agents, as I would say I probably write at most 5% of my code, maybe less.
But I am very much in control.
And I find that from a design perspective, the agent more often gets it wrong than right.
So, and I know there are different points of view on this.
I believe it is vitally important that we still understand the architecture, that we are still aware of what's going on and are not too trusting.
Because I do think that once you get into complex applications, if you don't maintain that kind of architectural oversight, you will quickly end up with a mess where your agent will happily add a new feature.
But with every new feature, the design degrades and it becomes really nasty.
And your reason for, you mentioned 5% of what is created there is AI generated.
Your reason for that, that's an intentional block there in terms of you don't want to write more because it's a choice that you want to have more control over what's written.
Look, if you read the code...
Well, actually, okay, let's put it this way.
In the open source project, I write more than 5% of the code.
I probably err on the side of being conservative.
But in some of our internal applications, it's more like the 95% is authored.
But if you read that code, you would think I'd written it.
It's like the designs are very, very clearly.
And I will sit there, I'll watch diffs, I'll look at the output, and I will very frequently stop it and say, no, that's wrong.
You've hard-coded this.
That should be a strategy.
Pull it out.
And I believe that that potentially can produce a better result than you can get with a human alone or a coding agent alone.
I would say, for example, if I look at what I write with a coding agent, it's much faster than I could do and it's somewhat better quality than I could do.
You compared it the other way, if I left it all to the coding agent, I believe the quality would be dramatically lower.
And it probably ultimately would end up being slower as well.
Yeah, yeah, super interesting.
I want to talk a little bit about one of the pieces of Mbabel, which is the planner.
And this is super interesting.
So it's a pathfinding algorithm.
Is it GOAT?
GOAP.
GOAP.
Sorry.
Goal-oriented action planning.
That's it.
Goal-oriented action planning.
So it's a pathfinding algorithm that was originally built for NPCs in gaming.
Is that right?
It is.
Amazing.
And the key thing is it's deterministic.
And I think if you look at other frameworks, whether it's Langchain or Crew AI or those types of things, it's ultimately the LLM that effectively...
helps decide what to do next, what the planning aspects are and things like that.
I'd love to talk about why you picked this algorithm from the NPC space.
What did you see there?
I started off thinking about some of the most obvious ways to do it.
One of the most obvious ways to do it is a state machine.
So Lengraph, in fairness to Lengraph, Lengraph is deterministic.
You define a state machine.
ahead of time.
So I started off by using that approach.
But let's step back a little bit first and talk about the motivation for planning.
So obviously you could just give your model a bunch of tools, right?
And let the agentic loop handle things.
And there are cases where that makes sense.
But fundamentally for things like automating a business process in a consistent, predictable way.
That really isn't sufficient because you don't know what order the LLM will invoke the tools you give it in.
You don't know precisely what arguments it will give it to them.
So...
The idea is that we enable users to decompose flows into a number of steps.
Those steps might invoke one or more LLMs or they might just be code steps.
So to that extent, you know, these are things that Langraph does, that Crew AI does, that Microsoft Semantic Kernel does.
I mean, that's a familiar idea and a proven idea that you break things down into smaller steps.
It also means that if you're using LLMs in those steps, you can use different LLMs for different requirements.
means, for example, you could potentially even use a local LLM behind your own firewall for certain things that are small enough for a local LLM to do it and highly sensitive.
So your customer data never goes outside.
So there's a lot of benefits there.
But it brings us back to how do we plan those steps?
How do we decide what order we're going to do things?
So you can do the state machine idea.
But what I found when I was working on something pretty similar to what Lengraph came out with is firstly, Changing a state machine, for example, adding more states and transitions is pretty fiddly, right?
You've got to rewire the thing if you're extending it.
And secondly, you have a problem with respect to typing because your state transitions are generally orthogonal to the type requirements of the individual action states.
So our idea with GOAT planning differs in two ways.
Firstly, it is...
So the planning occurs at runtime.
And secondly, it is totally integrated with the type system.
So we allow people to create custom conditions, but fundamentally the ordering of actions is typically defined by the arguments.
and return types of Java methods, which means that you can never have an action that's invoked when it doesn't have the parameters that are needed for it at the time.
So GOP is essentially, it's an A-star algorithm.
So we identify a goal.
We look at the steps that can get from the current world state to the goal.
We do that by changing actions.
So a goal has preconditions.
So certain conditions in the world state that must be true.
Actions have preconditions and expected post conditions.
So preconditions are absolute.
You cannot declare your goal to be satisfied unless those conditions have been met.
You cannot invoke any action unless those conditions have been met.
But the post conditions of actions are essentially promises that I will have achieved this essentially side effect.
So the planner starts off by identifying a plan from the current world state to the desired goal.
And of course, it may say there is no plan, which is legitimate and good to know.
So it won't do things that don't make sense.
Then it will execute the first action.
It will identify a list of actions that could achieve that goal.
It will execute the first action.
It will now replan.
So it will look at the world state as it stands after the execution of each action and say, okay, how do I get to the goal now?
Like most of the time, the happy path will work.
The action promised that it will have certain, you know, certain things will be true.
After it's executed, the planner checks, yep, looks like the world state's what I expected and it will go to the next step.
And this is entirely automated as well.
This is entirely automated.
So typically, Java developers don't really need to, know about the guts of the planner.
Typically, the way in which they provide inputs to the planner is they define what we call action methods.
So they annotate Java methods with that action and the arguments to those methods and the return types basically give the planner information to perform the chaining.
There are some cases where you also want custom conditions so they can define custom conditions to further control the workflow.
But it means, for example, that there may be more than one route to a goal and it can choose the cheapest route because you can assign cost.
to individual actions.
Cost can even be dynamic.
So if one of your actions involves, say, invoking a system that might be under heavy load, you could actually reflect that in a dynamic cost value for that.
So it might automatically choose a different route.
That's super interesting.
And that's dynamic at runtime.
It can kind of like decide based on the current state of the world.
That's pretty cool.
One of the other things, because it's very deterministic, If you were to ask why was a decision made, what can you provide as some information or a diagnostic about why something happened that a non-deterministic planner wouldn't be able to?
Yes, we can absolutely show you the plan that was formulated, what we saw in the world state that caused us to formulate that plan.
The planner and the whole of Mbabel emits a whole...
lot of events.
So you can also write listeners that will persist these or whatever you want to do with your audit logs.
So yes, you can absolutely explain why it did a thing and ensure that it does the same thing every time.
Of course, once you get inside the action steps, if you're calling an LLM, that may, that's not going to be.
wholly deterministic.
But on the other hand, this enables you to right-size your LLM invocations.
So, you know, if you have, as you unfortunately need to do with a chatbot, like three-page prompt and 30 tools, you're never going to have total predictability.
Whereas if you're doing something with a very small prompt and three tools...
it's going to be highly predictable.
I mean, it's obviously not going to be 100% predictable, but you will find that the amount of time you need to expend on prompt engineering is way, way lower.
So yes, overall, the systems tend to become much more explainable, much more deterministic.
And predictable, yeah, absolutely.
I'd love to talk a little bit about MCPs.
So everyone kind of like...
treats MCPs, or maybe certainly did before, as if they're the golden bullet, they solve agents.
What would you say the gap that most developers haven't seen yet in this space?
I think MCP has played an incredibly important role in enabling a whole ecosystem.
And I think MCP was really a catalyst in getting a much larger number of people to understand just what you can achieve with tools.
However, having said that, I'm kind of a bit of an MCP skeptic.
Okay.
And for a number of reasons.
Firstly, if you are doing what we were talking about earlier where you're AI enabling an enterprise system, why run it through MCP?
So you can with Embabel or Spring AI or Langchain4J, any framework, you can easily expose Java methods as tools.
So you have to ask the question, well, if it's that easy to do, why do I have to jump through this additional hoop?
Especially when you can do things like expose tools on domain objects, where you've actually retrieved the correct domain object based on a repository call or something, and now you're exposing this thing that...
You couldn't easily expose via MCP.
So that's one reason that I think very often, and this is not only true of the Java stack, but it's probably more important in Java.
Your first call, you know, thought for any tool you want to expose is, well, I could just expose it using my stack.
Why don't I expose a Java method or a Python function?
I'm going to totally do that.
Secondly, the reason that I'm a little bit of an MCP skeptic.
is I guess the case for MCP is that it's an API specification specifically designed for agents.
If it's an API specification, we already have things like OpenAPI, Swagger, GraphQL, right?
These things exist.
So why do we need a new one?
And I guess the MCP argument is we need it because it's specifically designed for agents.
And I guess more recently I've started to come to the...
conclusion that the only thing that is perfectly right for any given agent might well be unique to that agent.
So for example, you could have an MCP server that exposes a service, but imagine there's an open API spec that already exists.
You could also connect to that and have your own tools that are shaped using that spec that are shaped as your particular agentic loop.
needs.
So I do think MCP has been a great net benefit for moving the industry forward, but I don't think it's a one size fits all solution.
I think in many cases, it makes sense to work directly with API specifications and plan A should always be just expose the logic from your present stack.
Hey everyone, hope you're enjoying the episode so far.
Our team is working really hard behind the scenes to bring you the best guests so we can have the most informative conversations about agentic development.
Whether that's talking about the latest tools, the most efficient workflows or defining best practices.
But for whatever reason, many of you have yet to subscribe to the channel.
If you're enjoying the podcast and want us to continue to bring you the very best content, please do us a favour and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
I think Carpathie put a tweet out talking about how models are outpacing the products that are built on top of them.
Now, you're building the orchestration layer with Inbabel.
Does that mean you're already behind the models?
It's an interesting question, and certainly if you look at how we're building, coding agents have improved significantly more than I think we would have expected.
There was that leap in late November, December time that was quite dramatic.
I think models are definitely getting better, but I think...
think that many of the fundamental problems still remain.
And if you're automating business processes, the idea of moving, say, planning outside the control of the model to using some deterministic approach, I think that's still...
retains value.
I think explainability still remains as important.
So I do think that even as models improve, the frameworks above them, the agent harnesses, frameworks are still very important.
Good example of that is if you look at, say, Claude Code.
Sure, Sonnet 4.6 is way better than previous models.
But Claude Code is also way better.
Like if you look at, say, Claude Code today versus four or five months ago, it's working in a completely different way that actually makes it more effective.
So I actually don't really see conflict between the models being smart and the harnesses being smart.
I think we need to have advances in both places.
Where I think you will definitely see some case of the models eating the harness is where it doesn't really matter if things are deterministic, where you can just give a model a bunch of tools and it's fine if it's a bit unpredictable.
So I do think there is definitely a space where models will, you know, require less infrastructure around them.
But I think that space is not a space that's particularly relevant to enterprise apps.
Yeah.
Back in...
January of this year, you mentioned that your Claude Code workflow involves a lot of design conversations and kind of like back and forth with Claude Code, which is kind of long planning, I guess.
And you mentioned that after that you code and the results very often are better than handwritten, which I think you mentioned earlier as well.
Now, Claude...
Clawed doesn't understand certain things.
I think you mentioned companion objects were one in one tweet with a couple of interesting examples.
So if you're using Clawed code to build parts of Mbabel and Clawed doesn't fully understand parts of your architecture, how does it feel being inside that loop with the agent at the time, trying to build that out?
Look, I think that it works well because I fully understand the architecture and I often correct it.
I do wonder what will happen if developers increasingly take the easy option of not understanding it.
So, you know, I feel like I'm personally in a very sweet spot.
I completely understand the architecture and code base.
I know the language now very well.
We built on Spring.
Spring, rather well.
So, you know, I actually do know all the parts of the stack really well, and that enables me to effectively take control.
I personally would worry a lot about people who didn't understand that.
You know, I think it is really important to stay in control.
Now, with respect to writing code, I don't believe developers should be spending a lot of their time.
writing code because you can actually get so much more leverage by focusing on the things where you uniquely add value.
That said, does AI ever surprise you in the sense of giving you maybe a design or an architecture suggestion that you may not have thought about that actually kind of triggers you into either going a different direction or maybe trying it out to see if it's better?
Not that often.
However, one of the things that has been useful has been the discussion back and forth.
And, yeah, there's definitely been quite a few times where it has thought of a problem that I hadn't thought of.
So where we're discussing a proposed change and it points out something that I hadn't thought of.
More like a critique.
Yes.
Yeah.
I find that it's better at that than it is at coming up with an original idea.
it's probably not its strong point.
And, you know, overall I'm extremely happy, but there are certain times when I'm frustrated.
The last few days for an internal product, I'm trying to build a pretty elaborate testing infrastructure at every level that has things like testing using real LLMs and a test containers database, test using real LLMs and...
faking all the tools and all these kind of things.
And Claude Code's been doing astonishingly badly.
And I think one of the reasons is that it's just not seen this because this is probably a fairly new form of testing.
Like, for example, the, I think to.
Get maximum autonomy with your coding agents.
You need to be obsessive about tests.
So this is both a more extreme amount of testing that it's seen and also some of the types of testing are probably not things it's seen before.
And it just seems to be really struggling to a surprising extent despite clear directions.
How about have you played much with kind of like skills and context to actually guide it in that sense of trying to allow it to provide suggestions that you would find closer to what you would want?
I've tried a bit with skills also with Claude.md.
I do find, unfortunately, sometimes with the coding agent, as the context gets big, it forgets things.
Like one of the things that is really strange is it keeps wanting to put FQNs in, like, the body of the code which i hate because they prefer inputs and i've got that in my claude.md and like 50 of the time it still forgets yeah so even though that's a that's a mandatory thing that the agent has to read it's not something that's even a progressive kind of learning for it yeah it's just detention falls off yeah yeah um Let's take a sidestep now.
I think it was a Newstack article that I read from you where you were talking about the importance of TypeScript.
I think you said TypeScript was the most important language today.
And that was largely because I think it 2x'd how good a typical JavaScript developer would be.
So given that you think TypeScript today is the most important language, not Java, how can you hold both?
you know, building on the JVM as well as believing TypeScript is the most important.
I think TypeScript is a very clever language.
I think it's interesting if you look at what used to be statically and dynamically typed languages, to some degree they're converging.
So, you know, if you look at most modern Python, it's extensively using typeends.
In fact, the Python type system is actually getting...
reasonably good now.
TypeScript obviously added a layer of typing over JavaScript.
So I think TypeScript is a beautiful language.
I think it's very important.
Would I still say it's the most important?
I think it depends on the class of application.
If I were writing, you know, many kinds of application from scratch, I'd probably use TypeScript for server and On the other hand, if you're looking at enterprise applications, not that many of them are written on Node and not that many of them should be written on Node, right?
Like when you look at the JVM, Java, Kotlin, you get a whole bunch of things that are really valuable for that class of application.
And, you know, that I think TypeScript, nice as the language is, doesn't really add much relevance.
So I think modern Java is definitely better than probably when I made those comments.
Secondly, I think Kotlin is an excellent language for people to consider.
And Kotlin is a language I think it's pretty different from TypeScript, but I would say they're kind of about on a par.
I still miss things like union types.
I love union types.
I could go into this whole rant about how sealed hierarchies are absolutely not as good as union types.
But nevertheless, there's a bunch of things in Kotlin that are better than TypeScript.
So I would say they're on a par.
The other problem with TypeScript is, although they've done a wonderful job...
There is still fundamentally a layer of madness underneath, which you sometimes get at and cannot be concealed.
Whereas, you know, with Kotlin, you get a modern language that sits on top of something that's much more robust and kind of much more predictable underneath.
And do you see any of that?
I mean, I guess with all the advances in AI, do you see any of that changing in, let's say, five years?
I mean, is there much movement happening there around languages enough to...
you know, break those truths?
It's a really interesting question and uncharacteristically for me, I don't know my opinion on it.
I can persuade myself that either languages don't matter or that they do matter.
So firstly, I think a lot of people imagine that the training corpus means the blockbuster languages are going to have a natural advantage and that will be entrenched.
Absolutely is not true.
So I find it interesting that if you think of the three languages for which I use coding agents, so Java, Kotlin, and Python, there is no question which one coding agents do a better job of.
And it's Kotlin.
The reason, yeah, which is absolutely not what you would think.
I'd have put money on Python.
So.
Think about Java and Python.
They're both languages that have literally been around forever and that have evolved quite rapidly in the last few years.
You shouldn't be writing 2019 Java now.
You most certainly shouldn't be writing 2019 Python.
There's just so much training data.
Yeah.
You can obviously say always use var, use the enhanced switch statement, always use type hints in Python.
And because of the sheer weight of that training data, you're kind of fighting it.
So, I mean, I'm not saying it's not good.
It's still very, very good with both Java and Python.
But actually, it has surprised me that Kotlin is definitely better because there's not much Kotlin.
hasn't evolved as much because it started off as a modern language.
And secondly, because, you know, the people who got into it early were probably pretty skilled, there's not a lot of really bad Kotlin out there like there is Java or Python.
So firstly, I don't think it is true that the blockbuster languages will be entrenched because of training data.
Like LLMs are really, really good at anything they've seen a decent amount of and they've seen a decent amount of.
any programming language we've heard of.
But you then get the question of, well, in that case, why wouldn't you write everything in the perfect language for that thing?
So, you know, as we were saying earlier, there are things I absolutely wouldn't do right in Python versus Java.
So why wouldn't LLMs, because they're essentially guru level in every language, why wouldn't they then just choose to write each thing in the ideal language?
Go write this service in Rust, go write this in Go or whatever.
Are there any things that's worth still writing in Go?
Personally, I don't think so.
So the problem with that, is, I guess, something that we saw with the microservices CREZ.
And there are other costs.
So now you're getting a whole bunch of costs in maintenance.
And unless we're willing to totally trust machines, which I've argued we shouldn't do, I don't think that's such a great idea.
The skill issue from just the stack as well as people needing to maintain that.
Yeah, and also what are you going to do from a security perspective?
Yeah.
Your threat landscape just multiplies every single time you introduce a new language or a new library.
That's being reflected across multiple different languages there.
So I guess I probably come down to the idea that at least at this point it probably isn't going to change things that much.
Yeah.
And the reasons that we choose the languages and stacks we do.
probably don't really change that much.
Because when you get them into production and stand behind them in production, that hasn't really changed a lot.
Yeah.
In Babel is open source, I believe, right?
Yes.
It is open source.
And one of the things that you kind of like mentioned was open source needs, or rather companies that are backing open source projects, they need a business model from day one.
What does that look like for In Babel?
So it most likely will be open core.
So I do think that the support model for open source is a very difficult model.
Historically, it's been a difficult model.
I think it's becoming much, much more difficult with coding agents.
So I think there will be products above the framework.
And, well, we're not ready to announce anything yet, but I think it's going to be quite a lot higher than the framework.
So, you know, our current thinking is we will use the framework as a competitive advantage in building products that are potentially not even aimed at software developers.
Yeah.
So products that are aimed more at knowledge workers.
Interesting.
But the framework itself is Apache license as well as Spring.
And we welcome community contributions.
So we have an active Discord, GitHub, issue tracker and the like.
So anyone listening, please come and contribute and join the community.
Amazing.
And of course...
You mentioned Spring.
Spring survived, you know, gosh, VMware, Pivotal, now Broadcom acquisitions.
What's the thing do you feel that made it survive those acquisitions?
Whereas, you know, very often...
many open source projects kind of, they wither or die when acquisitions happen.
Is it just the sheer popularity, the community within the Java ecosystem that kind of helped drive it?
Well, I think Spring, obviously, by the time of the first acquisition in late 2009, Spring was already a monster, right?
I mean, it was already the de facto standard.
And the early adoption and the community that built around it was...
Yeah, so that obviously had an enormous inertia.
However, I think it has helped the fact that there are quite a significant number of really skilled developers who are paid to work full-time on Spring.
And that means that, you know, things that aren't exciting.
get fixed because it's somebody's job to fix them whether they're excited about it or not so i i still firmly believe that open source does really benefit from having a business behind it yeah because you know the things that make spring dependable the fact that it's you know pretty damn robust software and that anything that is found in it that's a serious issue will be fixed really quickly um partly reflects that we're not reliant on um volunteers.
I mean, it's obviously great when there are community contributions, but I do think having that professionalism behind it is important.
Gives it that more complete product style approach of development.
So we'll jump into some rapid fire questions.
What would you say is the most underrated thing about the JVM that the Python world doesn't know it's missing out on?
Well, I think performance, obviously, but actually my more serious answer would be the code written on it.
The business logic, the domain models, incredible value in understanding critical businesses.
Yeah, yeah.
What's an unpopular opinion about AI agents that most developers would push back on?
I think it's probably my relative degree of skepticism about MCP.
It's not that I think MCP is bad.
I just think that MCP has become the one hammer and people are looking everywhere for nails.
Yeah.
What's the one thing you'd tell a Java developer who's been told to learn Python for AI?
I would tell them to read some of my blogs.
I've got a series of blogs on comparing Python examples with Java examples and either show their boss one of those examples or better still, code something up themselves, just demonstrating that the Java code is extremely competitive with the Python code.
Landgraf or Envabel?
You have to pick one for a project that's already in production.
Okay, firstly, is this a Java project or a Python project?
Let's go for a Java project.
It's a Java project, I would definitely pick Inbabel.
Because if otherwise I'd be bringing in the alien stack, so like the risks, Inbabel is currently 0.3.5.
It's pretty close to API stability.
I'd be surprised if anything breaks between now and now.
1.0.
So it will get to 1.0 probably in the next four to six weeks.
So I don't think that's, being perfectly honest, I don't think that's a great risk for someone to adopt.
Whereas if I had a Java project, I would think it's a considerable risk to bring in a completely different stack and then have it to have to talk to my Java business logic.
That to me seems way riskier.
And vice versa, I presume.
Yeah.
And by the time you've finished all of that in Babel, it'll be 1.0 and you'll feel really, really annoyed with yourself.
Brilliant.
Kotlin or Java for a brand new enterprise project starting today?
Depends on the size of the team.
If my gut feeling would be if it's a team of less than 20, I would seriously consider Kotlin.
If it's a larger team and they're not already skilled in Kotlin, I would stick with Java.
I was going to ask these days, I haven't touched Kotlin for a little while actually, but is there still, I mean, a Java developer learning Scarlet, there was a significant kind of like learning curve.
Java to Kotlin these days?
Is there much of a learning curve?
I honestly don't know because I really came to Kotlin having done probably more Python.
Well, I hadn't done Java for a few months before getting back to Kotlin.
But, like, I've just...
done so much in languages other than Java that I wasn't coming from that.
So I honestly don't know.
I would say it's definitely easier than Scala.
There's no question it's easier than Scala, but most things are easier than Scala.
I think it's a pretty easy language to learn.
The other thing that I would say...
is, well, actually two things.
Firstly, I think every developer should try to learn a new language every year or two on principle because I think it improves how you think.
Secondly, it has never been easier to learn a language.
Like LLMs can help you learn any language so quickly.
So I think that the bar has been significantly lowered.
Like I don't own a book on Kotlin.
I've never read a book on Kotlin.
And I think a good way, I think you mentioned it earlier in terms of, you know, having an LLM critique is actually, you actually get better value for your money.
there versus like asking it to create.
And I think also when you're learning a language, asking an LLM to describe what's happening and why things are doing, I think sometimes it's actually better than saying, hey, can you just create this thing and then I'll try and work out why you've done it.
I think the two are similar.
Well, especially if you're an experienced developer.
So when I'm learning a language, I frequently ask the LLM, what is the equivalent of this feature in?
Whatever language I know.
Like, for example, in Python, is there an equivalent of TypeScript type cards?
That kind of thing.
So, you know, I think if you already can explain concepts, LLMs can do an amazing job of mapping those concepts onto a particular language.
What's your favorite AI tool that you use daily that isn't ClaudeCode?
Look, it's probably Claude.
And just having that ability to have a bunch of tools, do competitive research.
Like there's a whole range of things that I use it for.
What's the one thing you'd say you got wrong with Spring that you'd do differently with Embayment?
One thing that's a pretty small thing, but it's fun is the logging.
I wanted to retrofit onto Spring.
the idea of logging coming from events, and it was too late.
Within Babel, we have done that, and it means that it ensures that all the events are complete, right?
You can stream them over SSE, you can listen to them, but it also means we can change your blogging personality so your logs can look like Yoda speak.
So, you know, that was a small thing, but kind of fun.
I would say...
To some degree, the style of Embayble picks up from modern spring with some additional things that are easier to do in Kotlin.
So, for example, we don't use a lot of builders.
You can just do that more elegantly in Kotlin, even for folk to use from Java.
So I've got one last question for you, Rod.
If Embayble doesn't exist in five years, what do you think would have been that killed it?
I have absolutely no idea.
Because in five years' time, like, for example, are people still involved in writing applications or have they gone against my advice and let the machines completely take over?
So, you know, for example, I would say this is absolutely the last wave of frameworks that will be chosen by people.
Increasingly, choices will be made by our tools.
But, look, I think that...
We are in an almost unique environment.
We're five years into the future.
Even a year or two, right?
Yeah.
Awesome.
Actually, in fact, it was Thomas Dromka who on a very recent episode said, anyone who tries to predict anything one to two years out, you're going to be completely off.
And it was a good episode that we brought up on our 100th just recently, where I kind of introduced some of Guy's predictions from.
one to two years ago and we went through them.
So it was all good fun.
But Rod, this has been very enlightening and really fun to chat with you.
So thank you very, very much for making the time for us.
Thank you.
Fun conversation.
Absolutely.
And thanks all for listening and hopefully see you on the next episode.
So tune in for that.
Bye for now.
The AI Native Dev is brought to you by TESL, the package manager for skills and context.
Your hosts are Guy Pajani and me, Simon Maple.
Our producer is Tom Dowler.
The AI Native Dev is not just a podcast, it's a community, and we host monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more, and I hope to see you there.