Java’s age is its AI superpower

Markus Eisele explains that Java’s age helps agentic development in two ways. First, Java has been open source through OpenJDK for essentially its entire history, and its long use solving enterprise problems means large language models contain abundant Java examples. Second, Java is strongly typed, structurally consistent, and governed by recognizable language constructs, making generated code easier for agents to produce reliably. Ryan asks whether Java’s history creates guardrails; Markus says the language, JVM, tooling, and frameworks such as Spring and Quarkus provide a proven, scalable platform.

Ryan asks whether old Java paradigms or long release cycles cause agents to generate outdated code. Markus says he rarely sees that when engineers use context engineering and proper grounding, although historical examples in the training data can include non-idiomatic practices. The bigger problem is not Java itself but legacy systems: projects may be older than their youngest intern, contain ten years of source code, lack current documentation, and include undocumented customer-specific exceptions whose original experts have left. Agents can investigate these systems, but doing so consumes tokens and can produce unstable results.

Markus contrasts brute-force agent loops and vibe coding with what he calls precision engineering. He recalls dropping TypeScript and Tailwind CSS into an agent and receiving an impressive website without understanding how it was built, then asks whether anyone would want a bank developed that way. For regulated or established applications, he prefers surgical changes whose effects can be audited, tested, and explained. He also rejects the idea that the human merely reviews an agent’s final output: the human should observe the steps, guide the workflow, and remain in control throughout.

Ryan asks whether Java’s historically large, infrequent releases left behind disjointed code. Markus says modernization has levels: a customer can simply move to a newer runtime while retaining old constructs, or adopt newer idioms as part of the upgrade. Because enterprise testing is expensive and legacy applications often lack automated tests, many organizations only bump the version to address support and CVE costs. Markus points to OpenRewrite and IBM Bob’s Java modernization workflow as a way to combine static code rewriting with agentic assistance, reducing code and capturing the benefits of newer Java features.

Markus argues that Java specifications give agents a shared domain vocabulary: concepts such as CDI beans and annotations have consistent meanings across implementations, including MicroProfile and Jakarta EE. Quarkus adds an agent-oriented layer through its Quarkus Agent MCP project, which exposes a development-mode application, documentation search, controls, and packaged skills through an MCP server. He says current information and live project access matter because fast-moving frameworks can outpace model training. Markus considers the agent harness more important than the model because it shapes context, exposes tool calls, and determines transparency and control.

Markus says reliable agentic development depends on packaged workflows rather than hoping a prompt or skill will do everything. Bob’s vulnerability workflow consults the CVE database, compares findings against the source, and reports vulnerabilities instead of merely asking an LLM for an opinion. Its JUnit workflow assesses existing tests, proposes an editable testing strategy, can add coverage, and estimates migration effort; some steps run locally without model round trips. Markus’s own process starts with a specification emphasizing nonfunctional requirements, then scaffolding, stability, and architectural guidance. Repository guardrails catch secret leaks, while Bob personas such as a “Grumpy German” help limit blast radius and produce reviewable diffs.