DevStar: Quarkus Developer Experience for AI Coding Agents

[phillip-kruger]

Objective:
The main objective of this working group is to make the Dev Experience better for Coding Agents

The Problem:

Currently our Dev tools and Dev Experience effort focus on making life easier for Developers to create apps with Quarkus.
Basically all Dev Tools (Dev*) are designed with Human users in mind. With AI and Coding Agents we need to assess all these tools from the perspective of a non-human (Agent)

The proposed Solution

Refactor the Dev* to be single responsibility. Dev UI has grown to encompass features and client integrations beyond its original scope. We need to break Dev UI up into more reusable pieces. Dev UI, Dev JsonRPC, Dev MCP, Dev Assistant, Dev Shell (future).

As part of this refactoring, the Dev MCP runtime must be clearly separated from the Dev UI runtime so that Dev MCP can operate independently without requiring the full Dev UI web stack. This is essential for enabling external MCP clients (coding agents, IDEs) to interact with Quarkus applications without depending on the browser-based Dev UI.

The current MCP facade (HTTP bridge at /q/dev-mcp) works for simple request/response tool calls but needs to be expanded to support the full MCP protocol, including

• sampling,
• progress notifications,
• logging,
• elicitation.
  This will allow Dev MCP to serve as the primary AI integration point for Quarkus in core.

Chappie will continue to serve as the chat assistant for Quarkus and remain a Quarkiverse extension. However, Dev MCP and Skills will become the primary AI integration layer in Quarkus core, providing a standardized, protocol-driven way for any coding agent or AI tool to interact with running Quarkus applications.

Other Dev* tools that might also need some work: Dev Mode, Continuous Testing. We might not use Continuous Testing at all from the Agent and create specific MCP Method to run tests from an coding agent

Develop an external MCP server for Quarkus application lifecycle, that has access to the Quarkus documentation. The RAG part currently in Chappie should be factored out into a reusable component that can be consumed by both the external MCP server and Chappie itself.

Investigate Skills as a mechanism for providing Quarkus-specific capabilities to coding agents, and determine how they complement Dev MCP tools.

Definition of Done:

• Dev MCP runtime can operate independently of Dev UI runtime
• Dev MCP supports sampling, progress notifications, logging, and elicitation
• An agent can start/stop/query a Quarkus app via the external MCP server
• An agent can access all Dev UI information programmatically (via JsonRPC or MCP)
• An agent can search Quarkus documentation via the standalone MCP server
• Skills investigation completed with clear recommendation on integration approach
• At least one end-to-end demo with a major coding agent (Claude Code, Copilot, Cursor, etc.)
• Documentation on how to use coding agents with Quarkus
• Blog post about this

Scope of Work

• Refactoring Dev UI into separated runtimes (Dev UI, Dev MCP, Dev JsonRPC)
• Expanding the MCP facade to support the full MCP protocol
• External MCP server for lifecycle management and documentation search
• Factoring out RAG/doc-search into a reusable component
• Skills investigation and prototype

Work on updating Chappie to consume the factored-out RAG component is out of scope for this working group.

Organizing the Work

Coordination will be done with GitHub issues.
Work will be in Quarkus core, some work in Quarkiverse (Chappie) and some in a new repo for the external MCP.

Point of Contact:

Phillip Kruger (phillip.kruger@redhat.com) or Zulip (https://quarkusio.zulipchat.com/#user/212324)

Expected Timeline:

The aim is to get all (or at least a big part) of this done for Quarkus 4

Potential Outcomes & Deliverables

• Separated Dev MCP runtime independent of Dev UI
• Full MCP protocol support (sampling, progress, logging, elicitation)
• Refactored RAG documentation component (reusable by Chappie and MCP server)
• External MCP server with lifecycle and doc-search features
• Skills investigation report and prototype
• Examples, documentation and blog

[cescoffier]

What about the separation of the dev UI runtime and Dev MCP runtime?

Also, the MCP "facade" needs a lot more work, it works because our Dev MCP is not really advanced, but I expect Dev MCP to start adding sampling, progress, logging, elicitation... (and to some extent replace ChappieAssistant).

[cescoffier]

@phillip-kruger Here is a slightly rewored proposal:

GitHub Discussion: #53093
Predecessor: Chappie WG #45377
POC: Phillip Kruger
Target: Quarkus 4?

Objective

Decompose and modernize the Quarkus developer tooling runtime (Dev UI, Dev MCP, Dev Shell, Dev Assistant) so that each component can operate independently, without requiring the full vertx-http web stack. This enables AI-powered developer assistance (via MCP) and terminal-based tooling (Dev Shell) to work even when dev mode or the HTTP layer is broken, and lays the foundation for a unified "Dev Star" developer experience across all interaction surfaces.

Quarkus has always been a developer experience champion; live coding, Dev UI, Dev Services, and continuous testing set the standard for Java frameworks. Dev Star extends this effort into the AI era by focusing equally on AI experience (AIx): making Quarkus the easiest framework for coding agents (Claude, Copilot, Gemini, etc.) to work with. By exposing the full power of Quarkus dev mode (configuration, build output, documentation, testing, error diagnostics) through MCP, and by providing agents with the right documentation for the specific extensions and APIs used in the application being built (via RAG over Quarkus Docs), coding agents can understand, build, and debug Quarkus applications as effectively as human developers using the Dev UI. Developer and AI experiences are two sides of the same coin: every improvement to one benefits the other.

The Problem

Today, the entire Quarkus developer tooling stack is tightly coupled to the Dev UI Runtime, which depends on vertx-http. This creates several problems:

1. Fragile dependency chain: Dev MCP and Dev Shell cannot function without the full HTTP stack running. If dev mode is broken (e.g., a compilation error prevents the application from starting), all developer tooling becomes unavailable — precisely when developers need help the most.

2. No fallback for broken applications: There is no lightweight mechanism to provide application lifecycle information, documentation access, or workspace navigation when the Quarkus application cannot start. AI assistants connected via MCP are completely cut off.

3. Monolithic runtime: The Dev UI Runtime bundles WebSocket transport, JsonRPC routing, MCP transport, and shell connectivity into a single unit. Extensions that only need JsonRPC services or MCP tools must still pull in the entire web stack.

4. Limited AI integration surface: The Chappie WG established AI assistance capabilities, but the current architecture does not cleanly separate the AI runtime (Chappie Runtime + RAG over Quarkus Docs) from the transport layer, making it difficult to expose AI assistance through multiple channels (UI, MCP, Shell, stdio).

5. Developer experience gaps: Several core developer workflows (continuous testing, hot reload, exception reporting, example projects, file navigation) have not been re-evaluated in the context of MCP and AI-assisted development. Features like tool filtering/search in MCP are missing.

The Proposed Solution

Architecture Decomposition

Break the current monolithic Dev UI Runtime into four independent runtimes:

Runtime	Transport	Dependency	Purpose
Dev UI Runtime	WebSocket	vertx-http	Browser-based Dev UI (For Human)
Dev JsonRPC Runtime	JsonRPCRouter	CDI	Core routing layer for JsonRPC services; shared by Dev UI and Dev MCP
Dev MCP Runtime	Streamable HTTP	CDI (no vertx-http required)	MCP server for AI agents (e.g., Claude, Copilot)
Dev Shell Runtime	CDI-connected	CDI (no vertx-http required)	Terminal-based developer interaction

The key architectural change is breaking the vertx-http dependency so that Dev MCP and Dev Shell can operate independently. The JsonRPC Router becomes a shared component connected via CDI, enabling extensions to expose JsonRpcService beans that are accessible from any runtime.

Dev Assistant

The Dev Assistant combines:

• Chappie Runtime: AI interaction engine (successor to the Chappie WG)
• Quarkus Docs (RAG): Retrieval-augmented generation over Quarkus documentation

The Dev Assistant connects to the Dev Shell Runtime via CDI, and to the Dev UI Runtime via the existing JsonRPC path. This means AI assistance is available from the browser (Dev UI), the terminal (Dev Shell), and external AI tools (Dev MCP).

Standalone stdio MCP Application

A lightweight, standalone MCP application using stdio transport that provides:

• Application lifecycle information (build status, errors, configuration)
• Quarkus documentation access
• Workspace file navigation

This stdio app operates outside dev mode, ensuring developers can get AI assistance even when the application is completely broken (compilation failures, missing dependencies, misconfiguration). It complements the in-process Dev MCP Runtime.

Reconsider Dev* Features

Re-evaluate existing developer features for the new architecture:

• Dev Mode resilience: What works when dev mode is broken?
• Continuous Testing: Expose test status and controls via MCP tools
• Hot Reload: Trigger and monitor reloads from MCP/Shell
• Example Project: Generate example code via AI assistance
• Exception Reporting : Surface exceptions as MCP resources/tools
• Workspace Navigation : Find files and navigate project structure via MCP
• Tool Filter/Search: Enable discovery and filtering of available MCP tools
• Response Size Optimization: Reduce MCP response payload sizes to minimize context window consumption by coding agents; provide concise, structured responses rather than raw verbose output

Skills Investigation

Investigate the concept of "Skills" (composable, higher-level developer actions built on top of MCP tools). The idea is to allow each extension to ship one or more Skills that describe how the extension is intended to be used, configured, and tested, along with best practices, common pitfalls, and troubleshooting guidance. Rather than requiring an AI agent to discover this knowledge through trial and error, Skills provide it upfront as structured, actionable context.

Success criteria: define what a Skill is, how it differs from a raw MCP tool (tools do things; Skills teach how to do things well), and whether a Skills API adds meaningful value over direct tool composition by AI agents.

Definition of Done

• Dev MCP Runtime responds to the MCP initialize handshake without Dev UI or vertx-http running
• Dev Shell Runtime starts and provides interactive developer commands without vertx-http
• Dev Assistant (Chappie + RAG) is accessible from Dev UI, Dev MCP, and Dev Shell
• Clear design of the RAG pipeline: from documentation to the agent
• Standalone stdio MCP app provides application lifecycle, docs, and workspace tools when dev mode is broken
• Existing JsonRpcService extensions work across all runtimes without modification
• Continuous testing status and controls are available via MCP tools
• Exception information is surfaced as MCP resources
• MCP tool discovery supports filtering and search
• Architecture documented with clear extension author guidance
• Integration tests verify that each runtime operates independently

Scope of Work

In Scope

• Decompose Dev UI Runtime into four independent runtimes (Dev UI, Dev JsonRPC, Dev MCP, Dev Shell)
• Break vertx-http dependency for Dev Shell
• Implement Dev Assistant (Chappie Runtime + Quarkus Docs RAG) connected via CDI
• Build standalone stdio MCP application for broken-dev-mode scenarios
• Re-evaluate continuous testing, hot reload, exception reporting, and workspace navigation for MCP
• Implement MCP tool filtering and search
• Investigate Skills concept and define success criteria
• Documentation for extension authors on the new architecture

Out of Scope

• Production-mode MCP server (this is dev-mode tooling only)
• Dev Shell is not part of this working group, a dedicated working group will be created.
• Third-party AI provider integrations beyond MCP protocol support
• IDE-specific plugins (VS Code, IntelliJ) — these consume MCP, not provide it

Organizing the Work

Communication

• Zulip channel: #wg-dev-star
• GitHub discussion: #53093

Timeline

• Target: Quarkus 4 release cycle

WDYT?

[phillip-kruger]

@cescoffier Dev MCP Runtime (Streamable HTTP) still needs http (so vertx) except if we also refactor that into stdio ? Not sure if that is possible but we can investigate

[phillip-kruger]

Also - Do you want Dev Shell to be part of this Workgroup ? Maybe that should be in a separate one ? (we can still mention it here - just checking so I know the scope)

[phillip-kruger]

Only these two comment - the rest looks perfect.

[cescoffier]

@cescoffier Dev MCP Runtime (Streamable HTTP) still needs http (so vertx) except if we also refactor that into stdio ? Not sure if that is possible but we can investigate

No, I don't know what I was thinking. It is only about Dev Shell, not Dev MCP.

Also - Do you want Dev Shell to be part of this Workgroup? Maybe that should be in a separate one? (We can still mention it here - just checking so I know the scope)

I would do another WG about Dev Shell. I will add it to the out-of-scope list.

[cescoffier]

Working group officially started: WG - Dev Star (view)

[phillip-kruger]

@cescoffier - issues and PRs from https://github.com/quarkusio/quarkus-agent-mcp can be auto added to this workgroup