Python didn’t become the lingua franca of artificial intelligence by accident. I’ve argued that Python’s dominance in AI isn’t due to blazing performance or fancy features, but because it offers the shortest distance from idea to working code. It’s an accessible, general-purpose language that “everyone knows,” perhaps not as a first programming language but often as a second. No wonder Python has surged in popularity alongside AI’s rise. Python lowers the bar to experimentation, which is critical in the fast-moving AI field.

But Python hasn’t cornered the market on AI applications, and it shouldn’t, argues Rod Johnson, the creator of the popular Spring framework. Yes, if you’re already using Python to build agents, “it would be hard to justify jumping to [Java]” to capture some of the advantages (like being type safe). But if you’re already building with Java, using something like the Java-based Embabel agent framework “would be a no-brainer.” This is yet another reminder that the key to unlocking data value is about enabling the people and tech stack you already own, rather than chasing after “mystical data scientists” and complicated data architectures.

It’s always about people

It’s easy to get caught up in technology wars—Python versus Java versus NextBigLanguage—but the hardest part of AI isn’t the tools, it’s the people. Domain knowledge, skills, and adoption matter more than picking the “perfect” programming language. If you want AI to succeed in your organization, you must meet developers and domain experts where they are.

This seems obvious, yet too often our instinct is to throw shiny new tech at the problem and hope people adapt. A better approach is to empower people with tech they already know. In practice, that could mean using Excel for analytics because far more employees are comfortable with Excel than with a specialized data science tool. It could mean using SQL for AI-powered queries because SQL is already ubiquitous among your staff. And yes, it could mean sticking with a programming language your team has expertise in, rather than mandating a switch to what’s “hot.”

This principle extends beyond programming languages to the entire technology stack. Gartner projects that, by 2028, 80% of generative AI business applications will be built on existing data management platforms rather than on brand-new “AI-first” stacks. In plainer terms, most companies will inject AI into their current technology stacks, rather than adopt new ones. As Johnson suggests, if your developers are used to Java it would be a “no-brainer” to use Java for agents.

What about Python?

This “hot take” may not be particularly popular. After all, there’s a prevailing notion that if you’re doing anything with generative AI (say, an AutoGPT-style agent that uses large language models to perform tasks), you have to do it in Python. After all, the open-source examples, the popular libraries, and the online tutorials are almost all Python-based. Python’s ecosystem for AI is indeed rich. But does that mean a Java or C# developer is out of luck when building an AI agent? Not at all. In fact, forcing Python onto developers who are proficient in another language can be counterproductive.

Rod Johnson has had a profound impact on enterprise computing through his work with Spring. More recently, he started Embabel, a framework for writing agentic flows on the JVM. In a recent post on Medium, Johnson took a sample AI agent workflow from a Python project (CrewAI) and reimplemented it in Java, using Embabel. His verdict: You can build better agents in Java than in Python, and the JVM is superior to Python for real-world generative AI applications.

Bold claim! Or is it simply an example of an inveterate Java guy finding ways to say Java is better?

It could be either (or both), but Johnson does demonstrate that his Java agent was type-safe, more extensible, and easier to maintain than the Python equivalent would be. Java’s strong typing means that prompts and data passed between tasks are all checked by the compiler, avoiding a whole class of runtime errors (like typos in prompt keys or mismatched data formats) that a Python script might only catch when it crashed. He also showed how integrating with enterprise features (like a database of previously seen contacts, via Java Persistence API in Spring Data) was straightforward in Java, an indication of how enterprise Java tools can enhance an AI agent with persistence, transactions, etc., out of the box.

Is Java better?

Now, does this mean Java is “better” than Python for AI agents across the board? No. It all depends on where you’re coming from. Johnson himself acknowledges a critical nuance: “If you were on Python, it would be hard to justify jumping to another stack…. If you were already on the JVM, however, Embabel would be a no-brainer. Bringing in a new (Python) stack for an inferior solution would make no sense at all.” This is precisely the point. If you’re already invested in one ecosystem, switching to another (just because it’s trendy) is usually a losing proposition. A Python team should probably stick with Python rather than rewrite everything in Java—the marginal gains may not justify it. Conversely, a Java team has little reason to abandon all their hard-earned expertise and existing code to start anew in Python, especially now that libraries like Embabel prove they can do cutting-edge AI in Java.

The right language is the one your team knows and your systems are built on. It’s as simple—and as difficult—as that.

Besides, it’s not like Python is a silver bullet free of complexity. Yes, it’s easy to write a quick script, but taking that script to a robust application at scale can introduce challenges: dependency management, environment issues, performance tuning, you name it. I’ve noted before that learning Python’s syntax is the easy part; wrangling its packaging, conflicting libraries, and scaling quirks is harder. If your organization has already solved those kinds of problems in a different ecosystem (say, a tuned Java devops pipeline), you might not want to incur the same learning debt in Python unless you have to.

In Python’s favor, of course, is the vast trove of AI-specific packages. Sometimes that alone can justify its use for a particular project. But increasingly we’re seeing those AI capabilities become accessible from other languages too, via APIs or new libraries in JavaScript, Java, etc. The gap is closing. The bottom line is you have options, and you should choose with pragmatism, not dogma.

No time to dither

Pragmatism will almost immediately pay off. AI capabilities are growing on an exponential curve. As one AI researcher recently pointed out, “2026 will be a pivotal year for the widespread integration of AI into the economy.” So, if you have a capable team and a solid technology stack, use that to start exploring AI solutions today. The opportunity cost of delay is huge when the field is moving this quickly. You’ll move faster by building on what you have.

AI is a means to an end, not an end in itself. We don’t get extra credit for using a more fashionable programming language to achieve those ends. What matters is delivering value: better business outcomes, improved products, automated workflows. And the surest way to do that is to choose the tools that let your team iterate quickly, leverage their hard-won expertise, and integrate with the systems you have.