The Creator of Spring on Why AI Coding Agents Will Wreck Your Codebase (If You Let Them)

9,023 words · about 36 min to read

0:00 I think it's completely nonsensical the LM is not running in your Python process. the universe would end before Python could execute inference. So the LM 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. open claws not written in Python. in the case of many enterprise applications, they're obviously written in Java.

0:28 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 a genetic coding. Join your hosts, Guy pigeon and me, Simon Maple.

0:56 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 Devon in New York. This June 1st and second, we're bringing it to London. It's two days built for Anna to 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.

1:36 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 Pod 30. Just head to ainativedevcon.io and we'll see you in London.

2:04 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 Embabel, joins me here today. So, Rod, a very a very special welcome. Thank you. Simon, it's good to be here. Excellent. And of course, you're from Australia. Yes. I now live again in Sydney, but actually lived in London for seven years.

2:32 So when I created Spring, most of the early years of what became SpringSource was in London. 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. SpringSource, Interface 21 at one point. It was. Interface 21 was the first company name. Yeah. Back then I was I was at IBM and a number of folks, Andy Wilkinson and like that kind of like moved over and and that was there was an office I think close by there.

3:02 Was it Romsey way, Southampton. Yeah. It was a strange accident that that office was in Southampton. I can imagine. Yeah. We like to think about, you know, liberating people. So we did Andy and a few other really good engineers from IBM. Still there. Yeah. Yeah, yeah, yeah. He's doing great stuff. There's I mean, one of the amazing things about, I think the Spring story has been the retention of folk for that length of time.

3:30 I mean, primarily among them, of course, Jurgen. Like, Jurgen Hurler joined the Spring project in early 2003. And I would say he has worked full time on Spring since probably May 2003. And, you know, Jurgen did well out of the acquisition and it is what he wants to do and he does it exceptionally well. I think, you know, I think it's a wonderful thing for the Java community.

3:57 Yeah. Incredible. And so, you know, for you personally, I was looking a little bit back over your history and there was one super interesting kind of backstory that 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.

4:32 And then I got a very generous Australian Post Government Research Postgraduate 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, you know, I always still had this desire to write code. So I actually wrote some shareware back in the mid 90s when that was the thing.

5:00 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.

5:25 I've got it the wrong way around. And then, of course, sadly, I didn't play the piano for ten 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 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.

5:56 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 were at most of my code, I still get the same buzz because I'm still in control. I'm still creating and shaping something. So, you know, 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. Post Spring source, Spring source were acquired for about 20 odd years or so.

6:28 Maybe you were doing more in on on boards, doing investments, things like that. And then you launched in Embabel. 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 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 three, ChatGPT suddenly, suddenly became useful, suddenly stopped repeating itself and going down a weird rat hole and was clearly useful.

7:02 And I found 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,

Making HTTP Calls Directly From Existing Java Stacks

7:24 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. I guess when we look at enterprises today, many teams are being told to almost abandon Java to rewrite in Python.

1 Highlight · Why Enterprises Should Call LLMs from Java

7:47 And I think, you know, you you wrote about this, that you know, this is wrong. This is this is the last year of Python dominance in AI. Yes. And that's the wrong way. Why would you say that's the wrong way? I agree, by the way. But why would you say that's the wrong way? 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.

8:14 What are you working with? You're working probably with a database, enterprise services and existing code base. You're also working with something new, which is LMS. Well, if you consider those adjacencies, the LM is not running in your Python process. I mean, like we literally the universe would end before Python could execute inference. So the LM is a very, very simple HTTP call away.

8:39 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 open claw, open claws 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.

9:07 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

9:18 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'm I had written prior to returning to Java within Embabel. I'd written a ton of Python.

9:44 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 in that 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 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.

10:17 These genii enablement of apps. That problem is a task that's much better done in Java, where the app is already written than in Python. And of course, in Embabel is written in. I think. It is nearly all written in Kotlin. Most of our examples of Java, and we put a lot of effort into making sure that for Java users, it's completely seamless.

10:42 So like the vast majority of our user base, as you'd expect in jabber, and you will not see a companion, a Kate, you won't see anything. That's weird. It's like really nice, fluent Java. So yeah, I find that in the 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 API is so nice that even in Kotlin, like when you're using the framework, it's actually pretty much the same in other.

11:15 Language, and the integrations between are pretty seamless. Any way that you can actually dip from Kotlin straight into Java anyway, right? Oh, absolutely. Like, I mean, I think probably maybe over ten years ago I spent a lot actually probably more like 13 years ago, did a lot in, Scala. 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.

11:44 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, etc. that Scala had. So yeah, I find 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 their Java straw man.

12:12 So, you know, a lot of people out there are pretending that Java has not evolved and Java is actually evolved a lot. How this argument with guy every, every day, he always calls Java a very ancient, kind of like little.

Avoiding Enterprise AI Antipatterns and Forced Mandates

12:25 I think he's just calling me though. But, but, but let's talk a little bit about actually a couple of months ago maybe actually, of course, you feel it's probably a year, a few weeks ago, I think we were both in Atlanta, and you gave a closing keynote for Nexus. Nexus. That's right. Yeah. And, and and you talked a little bit about how AI is essentially almost bolted on as a disconnected layer. And as a result and, you know, rather than being integrated more into, into the existing systems and as a result, you know, it causes some of the, some of the more the failure cases as a result.

13:00 Walk us through what you see as like a real enterprise AI failure case from from European. 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.

13:27 So I think one of the major Andy 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.

13:54 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, there 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.

14:23 95% of those cases were really simple things that were a little bit too complex to, like, parse with regular expressions or whatever, but they were pretty simple things. So you know that 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 employee. And those, I think a very good examples of where you can start and gradually put runs on the board, build more confidence.

14:52 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 drove 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.

15:22 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, listen 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 organization, 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.

15:55 The remainders. 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 And of course, that happens more and more now where we see so much of a connection, so much of a disconnection between, you know, us as developers and the code, the implementation that we actually write because there's almost an overreliance 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.

16:38 A lot of the knowledge actually is on the is on the AI side,

Maintaining Strict Architectural Oversight Over AI Agents

16:42 or rather on the implementation side, which we are abstracted away from. How much of a problem? Do you 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 some classes of UI apps.

2 Highlight · Why Vibe Coding Fails on Complex Software

17:07 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 right 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.

17:36 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.

18:04 With every new feature, the design degrades and it becomes really nasty code.

18:11 And your reason for that? You mentioned 5% of of you know, what is created there is I 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 wrote more than 5% of the code.

18:38 I probably are 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 defeats, I'll look at the output, and I will very frequently stop it and say, no, that's wrong. You've hardcoded this. That should be a strategy.

19:04 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 if you compared it the other way.

19:30 If I left it all to the coding agent, I believe the quality would be dramatically lower. It would, and it probably ultimately went end up being slower as well.

Replacing State Machines With GOAP for Workflow Planning

19:39 Yeah, yeah. Super interesting. I want to talk a little bit about one of the pieces of Embabel, which is the planner. And this is, this is super interesting. So it's it's a pathfinding algorithm. The goat, the goat goat. 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.

20:04 Yes. And the key thing is it's it's deterministic. Correct. And I think if you look at other frameworks, whether it's Lange chain or AI or those types of things, it's the it's ultimately the LM that effectively helps decide what the the what to do next, what the planning aspects are and things like that. I'd love to talk about why you picked the this algorithm from the NPC space.

20:32 What did you see there? I started off thinking about some of the most obvious ways to do it, and one of the most obvious ways to do it is the state machine. So land graph. In fairness to land graph, land graph is deterministic. You define a state machine ahead of time. So I started off by using that approach. But let's 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.

21:02 And let the 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 LM 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.

21:33 Those steps might invoke one or more llms, or they might just be code steps. So to that extent, these are things that Lang graph does that 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. And that means, for example, you could potentially even use local LLM behind your own firewall for certain things that are small enough for local them to do it.

22:05 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 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 came out with is firstly changing a state machine, for example, adding more states and transitions.

22:31 It's 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.

3 Highlight · Using GOAP Algorithms for Deterministic AI Planning

22:52 Firstly, it is dynamic. So the planning occurs at runtime, and secondly it is totally integrated with the type system. So we allow people to create custom custom conditions. But fundamentally the ordering of actions is typically defined by the 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.

23:28 So go 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 chaining actions. So a goal has preconditions. So certain, you know conditions in the world state that must be true. Actions have preconditions and expected post conditions.

23:53 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.

24:20 And of course, it may say there is no plan which is legitimate and good to know the. 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. We'll 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?

24:46 Like most of the time you're 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 states what I expected and it will go to the next step. And this is entirely automated. This is entirely automated.

25:03 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.

25:31 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 involve, say, invoking a system that might be under heavy load, you could actually reflect that in a dynamic cost value for that.

26:02 So it might automatically choose a different route. That's super interesting. And that's and that's dynamic at runtime. Not 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 did why was the decision made? What can what can you provide as, as, you know, some information or diagnostic about why something happened that non-deterministic planner wouldn't be able to?

26:34 Yes. We can absolutely show you the plan that was formulated, the what we saw in the world state that caused us to formulate that plan. The planner and the whole of In Embabel 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.

27:04 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 invocations. So if you have, as you unfortunately need to do with a bot like three page prompt and 32, you're never going to have total predictability. Whereas if you're doing something with a very small prompt and three tools.

27:35 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. Absolutely. I'd love to talk a little bit about MCC. Yeah. So everyone kind of like treats MCC or maybe certainly did

Questioning the Necessity of the Model Context Protocol

28:04 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 case. 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

4 Highlight · Why Model Context Protocol (MCP) Is Overrated

28:27 larger number of people to understand just what you can achieve with tools. Yeah. However. Having said that, I'm kind of a bit of an MCP skeptic. In for a number of reasons. Firstly. If you are doing what we were talking about earlier, where your AI enabling an enterprise system, why run it through MCP so you can wear them Embabel or Spring AI or Lang chain for j.

28:53 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, you know, repository call or something.

29:18 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 and totally do that?

29:46 Secondly, the reason that I'm a little bit of an MCP skeptic. Is I guess the case for MCP

29:57 is that it's an API specification specifically designed for agents. If it's an API specification, we already have things like open API, 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 the 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.

30:29 So, for example, you could have an MCC 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 is shaped as your particular 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.

30:58 I think in many cases, it makes sense to work directly with API specifications. And, you know, 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 a gentle development, whether that's talking about the latest tools, the most efficient workflows, or defining best practices.

31:27 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 favor 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 Karpathy put a tweet out talking about how models are outpacing the products that are built on top of them.

31:55 Now you're building the orchestration layer with in Embabel. Does that mean you're already behind the models? It's an interesting. Question, and certainly if you look at how we're building, you know, coding agents have planned have improved significantly more than I think we would have expected. Like there was that leap in late November, December time.

32:21 That was quite dramatic. I think models are definitely getting better, but I 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 still retains value. You know, I think explainability still remains as important.

32:49 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 4 or 5 months ago, it's working in a completely different way that actually makes it more effective.

33:18 So I'd actually don't really see I don't really see conflict between the models being smart and the harness is 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.

33:51 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. Back in January of this year, you mentioned that your Claude Cloud workflow involves a lot of design conversations and kind of like back and forth with Claude code, which kind of long planning, I guess.

34:19 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, Paul doesn't understand certain things. I think you mentioned companion objects were 1 in 1 tweet with a couple of interesting, interesting examples. So if you use some Claude code to build parts of Embabel, and Claude 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?

34:52 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 develop is 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.

35:18 I we build on Spring a 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 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 you uniquely add value.

35:59 That said, does does AI ever surprise you in the sense of giving you a 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 one. 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.

36:28 So where we're discussing a proposed change and it points out something that I hadn't thought of. Yes. Yeah, I find that it's better at that than it is at coming up with an original idea. I do think original ideas, 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.

36:57 I'm trying to build a pretty elaborate testing infrastructure at every level that has things like testing, using real alarms and a test containers database test using real llms and faking all the tools and all these kind of things. And Claude Codes 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.

37:36 So this is both a more extreme like amount of testing that it's seen. And also some of the types of testing are probably not things that seen before. And it just seems to be really struggling to a surprising extent. Despite clear directions. How about have you have you played much with kind of like skills and context to actually guide it in, in that sense of trying to allow it to provide suggestions that you would find.

38:06 Closer to what you would want. I 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 FCN in, like the body of the code, which I hate because they prefer inputs.

38:33 And I've got that in my Claude, MD and like 50% of the time it still forgets. 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 attention falls off. Yeah, yeah. Let's take a sidestep now. I think it was a new stack article that I read from you where you were talking about the importance of TypeScript, and I think you said TypeScript was the most important language today.

39:03 And that was largely because I think it too x to the, the how good a typical JavaScript would be. So, so given that you think TypeScript today is the most important language, not Java, how can you hold both? Building on the JVM as well as believing TypeScript as is is the most important? I think TypeScript is a very clever language.

39:29 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 if you look at most modern Python, it's extensively using type ends. In fact the Python type systems actually getting reasonably good. Now. TypeScript obviously added a layer of typing over JavaScript. So I.

39:55 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 a, you know, a, many kinds of application from scratch, I'd probably use TypeScript for server and react. 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?

40:26 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 is the language is doesn't really add much relevance there. So I think modern Java is definitely better than when I'm probably when I made those comments. Secondly, I think Kotlin is an excellent language for people to consider.

40:55 And you know, Kotlin is a language. I think it's pretty different from TypeScript, but I would say they're kind of about on a par that 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.

41:27 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 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.

Programming Language Evolution and Training Data Quality

41:50 Do you see any of that? I mean, I guess with all the advances in AI, do you see any of that changing in that, say, five years? Is there much movement happening there around languages? Enough to, to, to 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.

42:16 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. That 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.

42:47 It's Kotlin. The reason? Yeah. Which is absolutely not what you would think. 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, right? You shouldn't be writing 2019 Java now. You may certainly shouldn't be writing 2019 Python. And there's just so much trading data that is like you can obviously say always use VAR, use the enhanced switch statement, always use type hints in Python.

43:22 And because of this year weight of that training data you're kind of fighting it. So it's I mean I'm not saying it's not good. It's still there 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.

43:52 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 Helms are really, really good at anything they've seen a decent amount of, and they've seen a decent amount of any programing 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?

44:22 So, you know, as we were saying earlier, there are things I absolutely wouldn't do write 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 they may. Are there any things that's worth still running in go? Personally, I don't think so, but, I so the problem with that is, I guess, something that we saw with the microservices craze and there are other costs.

44:57 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. 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? Like. Yeah. Landscape just like multiplies every single time you introduce a new language or a new library that's being reflected across multiple different languages.

45:29 So I'm 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. 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

Sustaining Open Source Projects Through Dedicated Engineering

45:46 and stand behind them in production, that hasn't really changed a lot. In Embabel. Is open source, I believe, right? Yes it is. Yes, yes. And one of the things that you kind of like mentioned was open source needs or rather companies that, you know, are backing open source projects. They need a business model from day one. What does that look like from Embabel? So it most likely will be open core.

46:15 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.

46:48 So, you know, we 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. So products that are aimed more knowledge workers in general. But the framework itself is Apache License, as was Spring. And we welcome community contributions. So we have an active discord, you know, GitHub issue tracker and the like.

47:14 So anyone listening, please, please come and contribute and join the community. And of course mention 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 wither or die when when acquisitions happen.

47:40 Is it just the the sheer popularity, the community within the Java ecosystem that kind of that 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 fact I started in Java. Yeah, 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 if somebody's job to fix them, whether they're excited about it or not.

48:22 So I still firmly believe that open source does really benefit from having a business behind it, because, you know, the things that make Spring dependable, the fact that it's pretty damn robust software, and that anything that is found in it, it's a serious issue will be fixed really quickly, partly reflects that. We're not reliant on volunteers.

48:47 I mean, it's obviously great when there are community contributions, but I do think having that professionalism behind it is important. Complete product style approach of development. Yeah, 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? Well, I think performance obviously, but actually my more serious answer would be the code written on it.

49:16 The business logic, the domain models incredible value in understanding critical businesses. 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.

49:45 What's the one thing you tell a Java developer who's been told to learn Python? I would tell them to read some of my blogs. I've got a series of blogs on comparing, like 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.

50:12 Landgraf or in Embabel, you have to pick one for a project that's already in production. okay. Firstly, is this a Java project or a Python project is a Java project or definitely pick in Embabel, because if otherwise I'd be bringing in the alien stack. So like the risks in Embabel is currently 0.3.5, it's pretty close to API stability.

50:37 I'd be surprised if anything breaks between now and 1.0, so it will get to 1.0 probably in the next 4 to 6 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 have to talk to my Java business logic. That to me seems way riskier. Yeah. And by the time you've finished all of that in Embabel will be 1.0 and you'll feel really, really annoyed with yourself.

51:09 Kotlin or Java for a brand new enterprise project starting today, Ben 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 these days. I haven't touched Colin for a little while actually. But is it? Is there still I mean, a Java developer learning Scala?

51:35 There was a there was a significant kind of like, you know, learning curve. Java to Colin these days, is. That much of a learning curve? I honestly don't know because I really came to Kotlin having done probably more Python. Well, I had done Java for a few months before getting back to Kotlin, but like I, I've just done so much in languages other than Java that I wasn't coming from that.

52:01 So I honestly don't know. I would say it's definitely easier than Scarlet. 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 LMS can help you learn any language so quickly.

52:31 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 that you mentioned it earlier in terms of, you know, having an LLM critique is actually you actually get a better value for your money than versus 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 actually better than saying, hey, can you just create this thing?

52:57 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 I when I'm learning a language, I frequently asked the LM what is the equivalent of this feature in whatever language I know. Like for example, in Python is there an equivalent of TypeScript type codes, 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.

53:29 What's your favorite AI tool that you use daily? Isn't Claude Code. Look, it's probably, Claude desktop. 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 embedding?

53:57 One thing that it's a pretty small thing that it's it's fun is the logging I wanted to retrofit on the Spring, the idea of logging coming from events, and it was too late within Embabel. We have done that, and it means that it ensures that all the events are complete, right? You can stream them over SSH, you can listen to them, but it also means we can change your blogging personality so your logs can look like Yoda spec.

54:26 So, you know, that was a small thing. That kind of fun. I would say to some degree, this style of Embabel picks up from modern Spring with some additional things that are easier to do in Colin. So, for example, we don't use a lot of builders. You can just do that more elegantly in Kotlin, even folk to use from Java. so I've got one last question for you, right?

54:52 If in Embabel doesn't exist in five years, what do you think would have been that killed? 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, for example, I would say this is absolutely the last wave of frameworks that will be chosen by people.

55:20 Increasingly, choices will be made by our tools. But look, I think that we are in an almost unique environment where five years into the future. Even a year or two. Yeah, yeah. Awesome. Actually, in fact, it was Thomas drunk who, on a very recent episode said anyone who tries to predict anything once two years out, you're going to be completely off and is a good episode that we brought up on our 100th just recently, where I kind of introduced some of guy's predictions from 1 or 2 years ago, and we went through them, so it was all good fun.

55:59 But rod, this has been this has been very enlightening and really fun to chat with you. So thank you very, very much for for making the time for us. Thank you. Fun conversation. Absolutely. And thanks 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 the package manager for skills and context. Your hosts are Guy pigeon and me, Simon Maple. Our producer is Tom Dowler. The AI native dev is not just a podcast, it's a community.

56:27 And we host monthly meetups at the Tesla offices in central London. Visit Tesla IO forward slash community to learn more and I hope to see you there.