Designing Framework-Aware AI Coding Modes for Java Projects

#java #ai #developer

Modern AI coding assistants are getting better at generating code, but they still struggle with one core problem: they rarely understand the framework they are working in at runtime.

For Java teams building production systems with Quarkus, this gap shows up quickly. Extensions drive behavior. Dev Mode changes how code is reloaded. Runtime state matters more than static files. A generic AI assistant can autocomplete syntax, but it cannot reliably make architectural decisions without context.

This article explores a concrete solution: designing a framework-aware AI mode for Quarkus, using IBM Bob as the reference platform. The ideas apply beyond Bob. The principles are relevant for anyone integrating AI assistants into serious Java development workflows.

The Core Problem: AI Without Framework Context

Quarkus optimizes the inner development loop through Dev Mode, hot reload, and extension-driven capabilities. At the same time, most AI assistants operate as stateless text generators. They inspect files but do not understand:

Which extensions are installed
What endpoints are currently active
How configuration profiles affect behavior
Whether the application is running in Dev Mode

This leads to predictable failures. The AI generates code that assumes missing extensions, uses deprecated APIs, or bypasses Quarkus conventions. Developers are forced back into manual correction, negating much of the productivity gain.

The architectural question is not how to generate more code, but how to anchor AI behavior to the live framework state.

Custom Modes as the Architectural Boundary

IBM Bob approaches this problem through custom modes. A mode is not a prompt template. It is a constrained operational role with explicit permissions, tooling access, and behavioral rules.

A custom mode defines:

What the assistant is allowed to do (read, edit, execute commands, browse, query MCP)
How it should behave when the mode is active
What domain expertise it should apply

For Quarkus, this opens the door to a dedicated Quarkus Developer Mode. The mode does not try to be generic. It encodes framework-specific assumptions and workflows.

At a minimum, such a mode must:

Detect the project build tool
Prefer Quarkus REST over legacy stacks
Respect Dev Mode and hot reload semantics
Treat extensions as first-class architectural signals

This is a safer design than attempting to infer intent from free-form prompts.

Runtime Awareness Through Quarkus Dev MCP

Static inspection is not enough. Quarkus exposes live runtime metadata in Dev Mode through the Dev MCP endpoint at /q/dev-mcp.

A framework-aware AI mode can query this endpoint to determine:

Which extensions are currently active
Which REST endpoints are registered
Whether recent changes were picked up by hot reload

This shifts the assistant from guesswork to verification. Instead of assuming a capability exists, the mode can confirm it. Instead of generating code blindly, it can validate outcomes.

This is a key architectural difference. The AI no longer operates only on source code. It operates against the running system.

Modular Rule Sets as Skills

Framework knowledge should not live in a single monolithic prompt. Bob supports mode-specific rule directories, which act as modular skill definitions.

For a Quarkus mode, this might include:

REST endpoint conventions
Qute template integration
Persistence patterns
Messaging patterns

Each rule set is self-contained, versionable, and reviewable. This mirrors Anthropic’s Skills model: bounded capabilities that can be tested and shared independently.

The practical benefit is governance. Teams can evolve AI behavior alongside their codebase, rather than relying on undocumented prompt behavior.

A Concrete Workflow: REST + Qute

Consider a simple task: expose a REST endpoint that renders a Qute template.

The developer starts Quarkus in Dev Mode.
The Quarkus mode connects to /q/dev-mcp and discovers active extensions.
The developer requests a REST endpoint that renders HTML.
The mode verifies that quarkus-rest is present and that quarkus-qute is not.
The mode proposes adding Qute before generating any code.
After hot reload, the mode generates a REST resource and a Qute template.
The mode confirms the endpoint is live via MCP.

At every step, control remains with the developer. The AI proposes actions, not irreversible changes. Verification is built into the workflow.

What This Solves and What It Does Not

This approach does not turn AI into an autonomous system builder. It deliberately avoids that. Instead, it creates a framework-aware assistant that operates within well-defined boundaries.

What it improves:

Reduction of context switching
Faster scaffolding aligned with framework conventions
Fewer invalid assumptions about runtime capabilities

What it does not remove:

Architectural responsibility
Code review
Testing and validation

This balance is intentional. AI accelerates execution, not decision-making.

Production Notes

Keep custom modes narrow and opinionated
Use runtime verification wherever possible
Store rule sets in version control
Treat AI-generated code like any other contribution

Framework-aware AI is most effective when it is predictable.

Try It Yourself

If you want to experiment with this approach, IBM Bob is available to try for free.

You can explore custom modes, project-specific rules, and AI-assisted workflows without committing to anything.

Learn more and sign up here:

https://www.ibm.com/products/bob