How AI Really Codes with You: Building Developer-Ready Modes for Bob and Quarkus

A practical field guide to creating modular AI skills, integrating Quarkus Dev Mode, and collaborating effectively with next-generation coding assistants.

If you’ve followed my work for a while, you know I’ve been deeply involved with AI infused application development and even AI assisted coding. One part of that also relates to IBM Project Bob. A new AI development partner built to integrate directly into your coding flow. Over the past months, I’ve had the opportunity to test Bob extensively in real-world scenarios, exploring how it supports everyday development work, from scaffolding projects to refactoring complex codebases.

Bob represents a new kind of IDE assistance, a partnership. One that doesn’t just autocomplete text, but understands your files, executes commands, and reasons about your workflow. It’s not about replacing developers; it’s about accelerating the flow between intention and implementation.

While this article focuses on a conceptual Quarkus-specific mode for Bob, the human principles it builds upon apply universally to AI coding assistants. Clear communication, small iterative steps, and active collaboration are essential whether you’re using Bob, Copilot, or any other AI pair programmer.

Bob will soon become publicly available. You can find more information, and even try the interactive demo I built, on ibm.com/products/bob.

What follows is an experiment with a practical edge: how an AI like Bob could evolve to support Quarkus development natively, and how developers can collaborate effectively with such tools when that future arrives. I am going to build out the “Quarkus Mode” for Bob with you and show you some of the concepts behind this.

Why Quarkus Is the Perfect Candidate for an AI Mode

Modern enterprise Java development demands speed, structure, and repeatability. Quarkus has already transformed the runtime side of that equation through its optimized model. This incorporates fast startup, low memory, and build-time optimization. But productivity challenges still exist in the outer loop: creating projects, managing extensions, wiring configurations, and preparing applications for deployment. While the Quarkus CLI is a great tool that already mitigates a lot, it just isn’t more than a convenient helper.

This is where Bob, or for this matter, any agentic AI, could make a real difference. Quarkus’s opinionated structure, strong CLI conventions, and extension ecosystem make it ideal for intelligent automation.

A Quarkus Developer Mode inside Bob would serve as an expert co-pilot with framework-specific awareness: it would understand how to scaffold entities, manage extensions, and apply best practices without the developer ever leaving the IDE. While this integration officially doesn’t exist today, this article just implements one. :-) And if you are curious, you can build it out alongside with me. I mean, as soon as you get your hands on Bob when it’s released.

Working with AI: The Human Rules Still Apply

Before we design the mode, it’s worth revisiting some rules for human-AI collaboration. They do apply to every assistant, not just IBM’s Bob. I have written about my personal trust issues before. What might have looked like a clear stance against AI assisted coding wasn’t meant to be one. I just think that it takes some ground rules to be successful with this approach. Here are a couple of high level guidelines compiled by a fellow IBM employee Lee Chase and adopted for this blog post.

Be Specific

Natural language is powerful but ambiguous. Instead of “make this better,” say “add pagination to the /products endpoint using Panache.” Precision gives AI direction.

Prioritize Clarity

Describe the environment before asking for help: “This project uses Maven, PostgreSQL, and Hibernate ORM with Panache.” Context turns vague intent into executable action. This is the exact kind of information that belongs into project specific files like AGENTS.md or similar. Take some time to find a setup that works.

Don’t Be Coy

If any assistant misses the mark, correct it directly. Say what needs to change and why. Specific feedback sharpens subsequent outputs. As long it stays in context window. If it happens repeatedly, make sure to pull the learnings into the longer lasting context, se above.

Establish Shared Understanding

For larger tasks, start with a short conversation. Ask the assistant to summarize the plan before it touches your code. And TBH, at this stage, I expect my AI coding partner to have a plan and share it with me before we even start working on it.

Stay Engaged

AI is a fast but literal partner. Watch its progress. Pause, adjust, and guide. Think of it as a junior teammate that never gets tired but will misinterpret instructions.

Keep Changes Small

Iterate through atomic, reviewable edits. Test after each one. This keeps your control tight and debugging simple.

Verify Everything

Even well-formed code can fail at runtime. Always run your Quarkus app, hit the endpoints, check logs, and validate results after every step.

These rules aren’t constraints; they’re enablers. They transform an AI from a tool into a collaborator.

The Vision: A Quarkus Mode for Project Bob

But back to Bob. It’s true power lies in its ability to adapt. Unlike static AI assistants, Bob is built on a mode system that allows developers to define specialized behaviors for specific workflows. Each mode changes how Bob interprets requests, which tools it can use, and how it acts inside your workspace.

You can think of modes as role definitions with boundaries.
A Documentation Writer mode, for example, might only read Markdown files and edit .md or .adoc documents. A Test Engineer mode could specialize in JUnit and coverage analysis while having access to terminal commands. A Review Mode might be read-only for safety.

Why Custom Modes Exist

The concept behind modes is elegant: specialization without risk.
Developers can create modes to:

• Specialize for a framework or workflow (for example, “Quarkus Developer,” “Jakarta EE Reviewer,” or “LangChain4j Integrator”).

• Experiment safely, without breaking other configurations.

• Control permissions, restricting access to sensitive commands or file types.

• Standardize workflows, by sharing common modes across teams.

For this exercise, we’ll start building a Quarkus Developer Mode. A specialized configuration that enables Bob to interact with Quarkus projects intelligently using its live Dev Mode MCP endpoint.

This is not a built-in feature (yet), but it fits perfectly into Bob’s existing architecture for extensibility.

Let’s start with a simple Quarkus project (It is the one line from the getting started guide):

 quarkus create && cd code-with-quarkus

Before we start Bob, there’s more to learn about the modes. Each one is defined by a set of key properties. In YAML (the preferred format), you specify the mode’s slug, name, role definition, available tools, and custom instructions. Together, these tell Bob who it is, what it can do, and what boundaries it must respect.

• slug: the internal identifier (e.g., quarkus-dev).

• name: the display name in the UI (e.g., “Quarkus Developer”).

• roleDefinition: describes Bob’s expertise, tone, and purpose in this mode.

• groups: defines which tool groups (read, edit, browser, command, mcp) are available.

• customInstructions: adds behavioral rules that shape how Bob acts.

• whenToUse (optional): a one-line explanation Bob uses when switching between modes automatically.

Modes can exist globally (in your main configuration) or locally (as project-specific overrides stored in a file called .bobmodes).
This makes it easy to share modes across teams or tailor one per repository.

Let’s open Bob in the code-with-quarkus project and create the .bobmodes file with the following content in the project root.

customModes:
  - slug: quarkus-dev
    name: ⚡ Quarkus Developer
    whenToUse: Use this mode for building and extending Quarkus applications.
    roleDefinition: >-
      You are an expert Java developer specializing in the Quarkus framework.
      Your goal is to accelerate development by managing extensions, scaffolding
      code, and automating common Quarkus tasks. You understand how to use
      the Quarkus Dev Mode MCP endpoint to gather live information about the project.
    customInstructions: |-
      ## Core Mandate: Dev-MCP Integration
      1. Connect to `http://localhost:8080/q/dev-mcp` to understand the live state.
      2. Prefer runtime data from the MCP endpoint over static inspection.
      3. When a user requests a feature, identify necessary Quarkus extensions,
         add them using the project’s wrapper script, wait for Dev Mode to reload,
         and re-query the MCP to confirm activation.
      4. Default to using `rest-jackson` for REST scaffolding.
      5. Promote Dev Services to minimize local configuration.
      6. Always confirm actions before executing build or command operations.
    groups:
      - read
      - edit
      - command
      - browser
      - mcp

This configuration does several things:

1. Defines Bob’s identity in the role definition. It’s now a Quarkus-focused expert.

2. Restricts tools to the essentials: it can read and edit code, run commands, browse docs, and query the MCP API.

3. Adds detailed custom behavior that describes exactly how it should use Quarkus Dev Mode safely and transparently.

If you would add this on a global level to Bob, it could be further tailored on a project specific level. Project level information complements and overrides global configuration.

We also need to add the Quarkus Dev MCP server to Bob’s configuration. Create a file .bob/mcp.json:

{
  “mcpServers”: {
    “quarkus-dev-mode”: {
      “type”: “streamable-http”,
      “url”: “http://localhost:8080/q/dev-mcp”,
      “disabled”: false,
      “alwaysAllow”: [
        “devui-endpoints_getAllEndpoints”,
        “tools_list”,
        “resources_list”,
        “resources_read”,
        “devui-continuous-testing_start”
      ]
    }
  }
}

Adding Rule Packs (Mode-Specific Instructions)

Custom instructions can live directly in YAML, but Bob also supports mode-specific directories for larger or evolving projects.

By placing a directory called .bob/rules-quarkus-dev/ in your repository root, you can organize supplemental instruction files that Bob automatically loads whenever the mode is active. For example:

.bob/
 └── rules-quarkus-dev/
     ├── 01-rest-endpoints.md
     ├── 02-panache-entities.md
     ├── 03-messaging-kafka.md
     └── 04-security-jwt.md

Each file might define conventions, templates, or guidelines.
Bob reads them in alphabetical order and merges their content into its internal context when you activate the mode.
This makes instructions versionable and reviewable which is an essential feature for enterprise teams.

Let’s take a look at an example 01-rest-endpoints.md:

## Skill: Quarkus REST Endpoints

### Purpose
Enable Bob to scaffold and maintain REST endpoints using **Quarkus REST**.

### Overview
Quarkus REST provides a modern, high-performance implementation of Jakarta RESTful Web Services (JAX-RS). It replaces the legacy RESTEasy Reactive extension and integrates tightly with Quarkus Dev Mode for fast reloads and build-time optimization.

### Core Rules
1. Always depend on `io.quarkus:quarkus-rest`.
2. Annotate resource classes with `@Path`, and methods with HTTP verbs such as `@GET`, `@POST`, `@PUT`, and `@DELETE`.
3. Use `@Produces` and `@Consumes` to specify supported media types. Default to `application/json`.
4. Define the global base path via `@ApplicationPath(”/api”)` or the `quarkus.rest.path` configuration property.
5. Prefer `@Produces(MediaType.APPLICATION_JSON)` for REST endpoints unless plain text is explicitly required.
6. Classes must use Jakarta packages (`jakarta.ws.rs.*`), not the old `javax` ones.
7. Always confirm that endpoints are live using Quarkus Dev Mode’s MCP endpoint (`/q/dev-mcp`).
8. When adding REST functionality, **use the `quarkus-rest` extension only**—avoid older RESTEasy or RESTEasy Reactive variants.

### Example Resource

```java
package org.acme.rest;

import jakarta.ws.rs.*;
import jakarta.ws.rs.core.MediaType;

@Path(”/hello”)
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class HelloResource {

    @GET
    public String hello() {
        return “Hello, Quarkus REST!”;
    }

    @POST
    public String echo(String message) {
        return “Received: “ + message;
    }
}

### Notes
- Quarkus REST runs on Vert.x, offering both reactive and blocking I/O models.
- Resources are automatically discovered during build and registered at runtime.
- Use Quarkus Dev Mode (./mvnw quarkus:dev) to live-reload REST resources after edits.
- You can test endpoints using cURL or the built-in Dev UI “REST Endpoints” view.
- Avoid mixing REST frameworks—keep Quarkus REST as the single implementation source.

### Validation Check
After generating or modifying REST resources, Bob should:
- Re-query the /q/dev-mcp endpoint.
- Confirm new endpoints appear in the live application state.
- Verify that the HTTP methods and media types match the defined annotations.

Let’s also add a quote skill 02-qute.md:

## Skill: Qute Templates

### Purpose
Enable Bob to scaffold, update, and validate **Qute templates** for Quarkus applications.

### Overview
Qute is Quarkus’s native templating engine. It minimizes reflection for fast native builds and supports both imperative and reactive rendering. Templates live in `src/main/resources/templates` and are hot-reloaded in Dev Mode.

### Core Rules
1. Always use the extension `io.quarkus:quarkus-qute`. If integrated with REST, make sure to also add `io.quarkus:quarkus-rest-qute`.
2. Templates are stored under `src/main/resources/templates`.
3. In development, Qute automatically reloads templates when files change.
4. Use `.html`, `.txt`, or `.qute` files with expressions and sections.
5. Expressions use `{}` syntax and can include property access, conditionals, or defaults (`{name ?: ‘Guest’}`).
6. Use `{#if}`, `{#for}`, and other **sections** for control flow.
7. Inject templates using `@Inject Template` and render them with `.data()` and `.render()`.
8. Use reactive rendering with `.renderAsync()` or `createMulti()` when applicable.
9. Always escape HTML output unless `@UncheckedTemplate` or safe content is explicitly used.

### Example Resource Integration

```java
package org.acme.qute;

import jakarta.inject.Inject;
import io.quarkus.qute.Template;
import io.quarkus.qute.TemplateInstance;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;

@Path(”/hello”)
public class HelloResource {

    @Inject
    Template hello;

    @GET
    public String get() {
        return hello.data(”name”, “Quarkus”).render();
    }
}
```

Template file: src/main/resources/templates/hello.html

```html
<html>
  <p>Hello {name}!</p>
</html>
```

### Notes
- Qute templates are compiled and cached at build time.
- Use @CheckedTemplate classes for type-safe templates.
- Sections can nest and contain multiple branches ({#if}, {#else}, {/if}).
- Supports asynchronous and streaming rendering for reactive use cases.

### Validation
1. When Bob modifies or generates templates:
2. Confirm file placement under src/main/resources/templates.
3. Ensure correct @Inject Template usage.
4. Re-query the /q/dev-mcp endpoint to verify live reload success.
5. Validate syntax ({}, {#if}, {/if}) and expression completeness.

How Rule Packs Mirror Anthropic’s Skills Model

Each .bob/rules-quarkus-dev/ file acts like a self-contained skill module. Much like the Skills framework in Anthropic’s ecosystem. Both follow the same architectural philosophy: modular intelligence instead of monolithic prompts.

In Anthropic’s model, a skill defines a bounded area of expertise, for example, “Python Refactoring,” “Markdown Editing,” or “API Documentation.” Each one contains clear inputs, expected behaviors, and guardrails. They can be loaded independently, versioned in source control, tested in isolation, and composed dynamically at runtime.

Bob’s rule packs follow the same logic but are designed for developers inside a local workspace.

• Self-contained: Each file defines its own purpose, rules, and examples — for instance, 01-rest-endpoints.md only deals with Quarkus REST scaffolding, while 03-panache-entities.md governs persistence.

• Versionable: Because they live inside .bob/, these rules can be committed, branched, and reviewed like any other code artifact. Teams can evolve their AI guidance alongside their application source.

• Testable: You can simulate Bob’s responses to ensure each rule pack yields consistent results, just as Anthropic’s skills can be verified through unit-like evaluations.

• Shareable: A team can distribute a common rule directory across projects, ensuring that everyone’s AI assistant follows the same engineering standards and framework conventions.

This pattern elevates AI-assisted development from ad-hoc prompting to structured collaboration.

Instead of treating Bob as an opaque box, you define its expertise explicitly, just as Anthropic’s Skill Creator does. The result is a maintainable, auditable layer of organizational intelligence: your Quarkus practices, encoded as reusable skills.

Why YAML Wins Over JSON

While JSON remains supported, YAML is Bob’s preferred configuration format because it’s easier to read, annotate, and maintain.
Teams can add comments, multi-line instructions, and descriptive metadata directly in the configuration.

It’s also safer. Developers can explicitly restrict file edits with regex filters (for instance, only allowing edits to .java or .properties files), reducing the risk of unintended changes.

A Realistic Workflow

Let’s see how the human collaboration rules and the Quarkus Mode technical rules come together in practice.

Start the Quarkus project in dev mode

You start your Quarkus project in Dev Mode:

./mvnw quarkus:dev

This launches the application and exposes the MCP endpoint at /q/dev-mcp.

Start Bob. And select the “Quarkus Developer” Mode

“Create a REST endpoint at /greet that renders a Qute template called greeting.html.”

Following Human Rule 1 (Don’t be vague), you describe both the goal and the expected output. Bob understands you want an endpoint that integrates Qute for templated HTML responses.

Bob Proposes Actions

Bob replies (with something similar to below probably):

I’ll help you create a REST endpoint at /greet that renders a Qute template. Let me start by understanding the current project state and then implement the required functionality.

The user wants me to:

1. Create a REST endpoint at /greet

2. Have it render a Qute template called greeting.html

Based on the rules:

• I need to use the quarkus-rest extension for REST endpoints

• I need to use the quarkus-qute extension for templates

• Templates should be in src/main/resources/templates

• I should inject the template and render it

First, I should check if the necessary extensions are already present by reading the pom.xml file. Then I’ll need to:

1. Ensure quarkus-rest and quarkus-qute extensions are added

2. Create the REST resource with @Path(”/greet”)

3. Create the greeting.html template in src/main/resources/templates

4. Verify the setup works

This aligns with Human Rule 4 (Establish shared understanding) . Bob clarifies its plan before making any changes.

You Review and Approve

You check the proposed to-do-list and confirm:

• Add quarkus-qute extension to pom.xml

• Create GreetResource.java with /greet endpoint

• Create greeting.html template in src/main/resources/templates

• Verify the endpoint works

Following Human Rule 6 (Resist the urge to click), you review the planned changes carefully to ensure the naming and structure fit your conventions.

Bob Executes and Confirms

Bob adds the missing extension to the pom.xml. It then generates the code and template.

Bob Creates the REST Resource

Bob generates a REST resource class that uses Qute, following the REST and Qute rule packs:

package org.acme;

import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import io.quarkus.qute.Template;

@Path(”/greet”)
public class GreetResource {

    @Inject
    Template greeting;

    @GET
    @Produces(MediaType.TEXT_HTML)
    public String greet() {
        return greeting.data(”name”, “Quarkus Developer”).render();
    }
}

And the corresponding Qute template:

<!DOCTYPE html>
<html lang=”en”>
<head>
    <meta charset=”UTF-8”>
    <meta name=”viewport” content=”width=device-width, initial-scale=1.0”>
    <title>Greeting</title>
    <style>
<!-- omitted -->
    </style>
</head>
<body>
    <div class=”greeting-card”>
        <h1>Welcome!</h1>
        <p>Hello, <span class=”highlight”>{name}</span>!</p>
        <p style=”margin-top: 1rem; font-size: 1rem;”>This greeting is powered by Quarkus and Qute templates.</p>
    </div>
</body>
</html>

Bob tests the endpoint

Perfect! Quarkus Dev Mode is now running and I can see:

1. The application started successfully on

http://localhost:8080

1. The installed features include both “qute” and “rest” which confirms our extensions are loaded

2. Live Coding is activated

Now I should test the /greet endpoint to verify it works. I’ll use curl to test it.

You Test Immediately

You open your browser and navigate to http://localhost:8080/greet.

Following Human Rule 10 (Verify thoroughly), you verify that:

• The REST endpoint returns the correct output.

• The Qute template reloads automatically when edited.

Review and Iterate

You could now ask Bob to make the greeting configurable via query parameter. Bob will modify the method.

And you finally test again, confirming that both /greet and /greet?name=Markus render correctly. And so on and so on.

Governance and Continuous Improvement

Rule packs should be managed like source code: versioned, reviewed, and tested.
Teams can maintain a shared repository of Quarkus skills, evolve them as the ecosystem changes, and contribute improvements back.

Because the mode queries the live Dev Mode MCP endpoint, it never goes stale and adapts automatically to the current state of your project.

Toward Agentic Java Development

Quarkus optimized the execution of Java. Project Bob has the potential to optimize its creation.
Together, they outline a future where enterprise Java development is conversational, context-aware, and continuously verifiable.

I’ve spent months working with AI coding assistants and can see where they shine and where they still struggle.
What stands out most is not their precision but how they change how we work.
AI pair programming demands the same discipline and craftsmanship as human teamwork.
You communicate clearly, stay engaged, and never stop verifying.

The Quarkus integration described here doesn’t officially exist and is just an example. But if you’re working with AI assisted coding and have an opportunity to create “skill modules” for your project, do it. It will elevate the results and save you a ton of prompting and time.

(More information about IBM Project Bob, is available at ibm.com/products/bob.)