How To Write Great Java Apps With LLMs and Agents

Summary

Adam Bien demonstrates how Java developers can use large language models (LLMs) and coding agents to build maintainable applications. His approach relies not on elaborate prompts, but on combining Java’s established standards with clear architecture, concise instructions, and careful review.

Main ideas

• Java’s standards give LLMs a strong foundation. Java APIs and specifications—including Jakarta APIs, MicroProfile, JDBC, and JPA—are widely available and consistently documented. Since models have encountered these materials during training, developers can often request standard-based code without explaining every API from scratch.
• A consistent architecture makes projects easier for agents to navigate. Bien uses a Boundary-Control-Entity (BCE) structure organized around business components. Predictable packages and responsibilities help an agent focus on the relevant component instead of exploring the entire codebase.
• Readable source code still matters. Bien rejects the idea that generated code is disposable. Source code should communicate business rules and remain understandable to future developers and tools. LLM output needs human review; developers should take ownership of the code rather than trust it blindly.
• Short prompts can work when context is well prepared. A brief request such as “create a speakers BC” can be effective when the project’s architecture and conventions are clear. However, sparse prompts can invite invention or hallucination, so developers should review the result and add context when needed.
• Standards can improve portability. In the demo, standard APIs are presented as a way to reduce reliance on a particular framework and make migration easier. Bien also argues that standards-based work can reduce dependency and security concerns.

Demonstrated workflow and recommendations

Establish context

• Start with an existing project and ask the agent to inspect and explain its structure.
• Use a recognizable architecture, such as BCE, with business components arranged predictably.
• Let the agent discover existing conventions before asking it to make changes.

Give concise, focused tasks

• Ask the agent to create or modify one business component at a time.
• In the conference-management example, the agent generated components for coffees, speakers, sessions, registrations, and attendees.
• Allow the agent to fill in reasonable example details, but review its assumptions—especially when business requirements are unspecified.

Use reusable instructions

Bien’s instructions specify preferred Java conventions and standard APIs. They discourage unwanted patterns, such as generic class names like Service or Manager, unnecessary comments, excessive tests, and avoidable custom exceptions.

Keep these rules concise. The goal is to guide the agent without creating a large prompt that must be repeatedly supplied.

Review and iterate

• Inspect generated code and refine it with follow-up prompts.
• Prefer small, reviewable changes over generating many classes at once.
• If an agent repeatedly makes an unwanted choice, update the instructions to address it.

Use spec-driven development for complex features

For features that require more coordination, Bien recommends asking the agent to draft a specification and then reviewing it. From there, developers can refine a design and implementation plan before generating code and tests.

This process adds overhead for simple features, but can help when requirements are complex or need discussion with product stakeholders.

Use Java for suitable operational scripts

In the demo, an agent creates a Java 25 script to check an application’s health endpoint. Bien reviews the result, adds a timeout, and requests colored logging. His broader point is that inspectable Java scripts can sometimes be preferable to less transparent shell scripts.

Migrate legacy code gradually

• Ask the agent to analyze the system and propose components or a migration plan.
• Check whether its interpretation of the existing code is correct.
• Refactor incrementally rather than attempting a “big bang” rewrite.

Results and claims discussed

• Bien reports that different agents produced broadly similar, though not identical, code when given the same architecture and conventions. He mentions using Claude Code, Mistral, Kiro, and GitHub Copilot during the session.
• He argues that predictable structure and standards reduce the amount of codebase exploration and explanation an agent needs. This can lower token use and make work more consistent across models.
• The session cites a Tencent study in which Java reportedly scored 78.7% on a measure of solving problems without errors, compared with about 59–60% for JavaScript and Python. Bien also discusses possible inference-cost savings from standards and clear structure, quoting estimates during the session. These are presented as his discussion of the topic, not as independently verified results.
• He briefly shows a performance comparison claiming Java is substantially faster than several scripting languages, though this is not central to the live-coding demonstration.

Speakers and sources featured

• Adam Bien — presenter and live-coding demonstrator.
• Unnamed audience members — ask questions during the session.
• Tools and models mentioned or used: Claude Code, Mistral, Kiro, GitHub Copilot, and an Opus model.
• Technical references mentioned: BCE (Boundary-Control-Entity), Java 25, Jakarta and MicroProfile standards and APIs, JDBC, JPA, JAX-RS, JSON-P, and RFC 2119.
• Research cited: A Tencent study comparing programming-language performance on problem-solving tasks.