Then we shipped Agent Mode, and RAG fell off a cliff.

Users would ask conceptual questions like "which slides discuss MCP?" or "where do we explain the indexing pipeline?" and the agent would ignore the rich semantic context we had just injected. Instead, it reached for search_files — a regex grep — and returned nonsense. The semantic context had become wallpaper: present, but unseen.

The tool bias problem​

Agent-mode LLMs are trained to prefer tools over passive context. When both a <SemanticContext> block and a search_files tool are available, the model almost always chooses the tool. It's not being lazy; it's doing exactly what the agent loop incentivises. The problem is that regex grep is terrible for conceptual queries. "Authentication flow" doesn't match auth.*flow in any file — but it embeds close to the actual auth code.

We tried making the tool descriptions more persuasive. We tried bigger models. Smaller models still defaulted to grep. The only reliable fix was to stop fighting the bias and lean into it: if the model wants a tool, give it a tool.

From injection to orchestration​

The semantic_search tool (task-221, refined in task-222) does exactly what the passive injection did — embed the query, search ChromaDB, return the top-K chunks — but exposes it through the agent tool loop instead of prepending it to the prompt.

The key design decision was mutual exclusion: when Agent mode is on, passive injection is completely suppressed. The LLM sees the index only through the tool. This avoids three problems at once:

1. Token waste — no duplicate context in the prompt
2. Contradictory sources — the LLM can't get confused by injected chunks that differ from tool-retrieved ones
3. Tool bias — the model has no choice but to use the tool if it wants semantic retrieval

Of course, the agent still has search_files for exact-string lookups, list_files for browsing, and the PSI tools for symbol navigation. The point isn't to replace those. It's to give the agent an orchestration layer: semantic search for meaning, grep for literals, PSI for symbols.

Query expansion and the meta-query trap​

Conceptual queries have a second problem: they embed like conversational boilerplate. Ask "where do we discuss authentication?" and the embedding lands near chit-chat, not near AuthenticationService.java.

Our answer was optional query expansion via ExpandingQueryTransformer. The query is paraphrased into multiple variants, each searched independently, and the results fused with Reciprocal Rank Fusion (RRF, k=60). A single meta-query becomes a small retrieval ensemble. It's overkill for "find the User class" and essential for "where do we explain the indexing pipeline?"

The nudge that smaller models need​

Even with the tool registered, we noticed smaller models still sometimes defaulted to search_files for conceptual queries. Tool descriptions alone weren't enough. So when Agent mode + RAG are both enabled, DevoxxGenie now injects a dedicated <RAG_INSTRUCTION> system-prompt fragment:

Prefer semantic_search for conceptual queries (e.g. "which slides discuss X", "where do we explain Y").

This lives outside the tool schema, in the system prompt itself, where smaller models are more likely to honour it. It's a small patch, but it meaningfully improved tool selection on models like Qwen 2.5 and Gemma.

Error handling as a first-class concern​

One subtle requirement: the tool must fail gracefully. If ChromaDB is unreachable, throwing an exception breaks the agent loop. Instead, SemanticSearchToolExecutor returns a descriptive error string:

Error: ChromaDB is not available. Docker container may not be running.

The agent reads this, understands the index is down, and falls back to search_files or PSI tools. No modal dialogs, no stack traces in the chat window. Because semantic_search is classified as a read-only tool, it's also auto-approved — no approval friction on every call.

The user-control layer​

Not everyone wants the agent to have semantic search. We kept the control granular: semantic_search appears in Settings → Agent Mode → Built-in Tools as an individual checkbox, independent of the master RAG switch. You can keep passive injection active for chat mode while excluding the tool from the agent's toolbox, or vice versa.

Architecture in three layers​

The implementation is thin by design — it reuses the existing RAG stack rather than building a parallel one:

Registration happens in BuiltInToolProvider: the tool is added only when ragEnabled is true. Suppression of passive injection lives in MessageCreationService.shouldInjectPassiveRagContext(). The <RAG_INSTRUCTION> fragment is injected by ChatMemoryManager. Each concern is separated, so the feature can be disabled or extended without touching the core RAG pipeline.

A third retrieval tier: web_search​

semantic_search covers your local codebase. search_files covers exact strings. But sometimes the right answer isn't in the project at all — it's in a library changelog, a Stack Overflow thread, or a vendor API reference. That's the gap the new web_search tool fills (task-223).

When web_search is enabled in Settings → Agent Mode → Built-in Tools, the agent gains access to live web search backed by whichever provider you've already configured in Settings → Web Search: Tavily or Google Custom Search. No new API key management — it reuses the keys you've already set up for the /search slash command.

The tool returns raw structured results — title, URL, and snippet — so the agent can reason over the sources directly:

Found 3 results for "langchain4j ChromaDB 0.6 migration":

1. LangChain4j 0.37 release notes
   URL: https://github.com/langchain4j/langchain4j/releases/tag/0.37.0
   ChromaDB store updated to API v2 (0.6.x). Collection creation now uses ...

2. ...

The tool picks the provider automatically: Tavily is tried first if its key is present; Google Custom Search is used as the fallback. If neither is configured, the tool returns a descriptive error string — the agent degrades gracefully, just like semantic_search does when ChromaDB is unreachable.

When a result looks worth reading in full, the agent can follow up with fetch_page, which fetches the complete content of a webpage given a URL — making web_search → fetch_page a natural two-step pattern for retrieving and reading external documentation.

Like its sibling tools, web_search is classified as read-only and is therefore auto-approved — no per-call confirmation dialog when auto-approve read-only is on.

The three-tier retrieval stack​

With all three tools enabled, the agent now has a complete retrieval stack:

The LLM decides which tier to invoke based on the query. Conceptual questions about your own code go to semantic_search. Grep-style lookups go to search_files. Anything that requires up-to-date external knowledge goes to web_search.

What changed, what didn't​

The RAG pipeline itself is unchanged. It still indexes via Ollama's nomic-embed-text, still stores vectors in ChromaDB v0.6.2, still filters low-content chunks at index time, still debounces re-indexing on save. What changed is the interface surface: from prompt injection to tool contract — and now, a third tool tier that reaches beyond the local project entirely.

If you're already using RAG in chat mode, nothing breaks. If you turn on Agent mode, the same index becomes queryable on demand. And if you want the gory setup details — Docker, Ollama, indexing, configuration — the RAG docs have you covered.

Install: JetBrains Marketplace · GitHub

The big difference: Commands are typed by you, Skills are picked by the model. And because Skills live in the same directories that Claude Code, Codex and Gemini's .agents-aware tools already use, the same file can teach all four assistants the same playbook.

Commands: the slash-command you already know​

Commands are a pre-LLM text substitution macro. You type /explain, DevoxxGenie expands the stored template (optionally substituting $ARGUMENT), and the resulting prompt is sent to the model. The model never sees the /explain; it just sees the expanded text.

That makes Commands ideal for things you trigger consciously and repeatedly:

You add your own in Settings → Tools → DevoxxGenie → Commands. Everything happens locally, with no tool call and no agent loop required.

See the full reference in the Commands docs.

Skills: capabilities the LLM activates itself​

Skills flip the workflow around. Instead of you typing a slash, you drop a SKILL.md file into one of the well-known skill directories. DevoxxGenie scans those directories, hands a one-line index to the LLM in the system prompt, and the model decides, based on what you're asking, whether to call activate_skill("…") to pull in the full body of the skill mid-conversation.

A minimal skill looks like this:

~/.claude/skills/refactor-helper/SKILL.md

---
name: refactor-helper
description: Guides a safe, step-by-step refactoring workflow with tests
---

# Refactor Helper

When the user asks for a refactor:

1. Read the target file and its references.
2. Sketch the refactor as a diff before applying it.
3. Run the project's tests after each step.
4. Stop and report if any test fails.

The model sees only the name/description pair until it decides the skill is relevant. Then it calls activate_skill("refactor-helper"), gets the full Markdown body streamed back as a tool result, and continues the conversation with those instructions in context.

One file, four assistants: Claude, Codex, Gemini, DevoxxGenie​

The real win is portability. DevoxxGenie scans six directories for skills, in increasing priority order:

Two rules govern collisions: project beats user, and within the same scope .devoxxgenie beats .claude beats .agents. The screenshot above shows the Settings panel listing exactly that mix: subtask, ralph-runners, conference-scheduler, review, start-task, git-commit-push-pr, all loaded from ~/.claude/skills/ and <project>/.claude/skills/, instantly visible to DevoxxGenie too.

This is the whole point: keep a curated library of skills in ~/.claude/skills/, get them everywhere. Override one per-project in <project>/.devoxxgenie/skills/ when you need a team-specific variant.

Under the hood: Langchain4j's Skills API​

Skills support in DevoxxGenie is a thin layer on top of the langchain4j-skills module, the same Java framework that already powers the plugin's chat, agent and MCP integrations.

// build.gradle.kts
implementation("dev.langchain4j:langchain4j-skills:1.14.0-beta24")

The whole pipeline is three building blocks:

1. Load SKILL.md files from disk​

import dev.langchain4j.skills.FileSystemSkill;
import dev.langchain4j.skills.FileSystemSkillLoader;

List<FileSystemSkill> skills = FileSystemSkillLoader.loadSkills(dir);

DevoxxGenie does this for each of the six directories above, merging the results into a single map and letting higher-priority sources overwrite lower ones (with a warning logged on collision).

2. Wrap them in a Skills instance​

import dev.langchain4j.skills.Skill;
import dev.langchain4j.skills.Skills;

Skills skills = Skills.from(activeSkills);

// One-line index for the system prompt (the LLM sees only this)
String fragment = skills.formatAvailableSkills();

The fragment is appended to the system prompt under a heading like "You have access to the following skills", so the model knows what's on the menu before the first user message.

3. Expose the activation tool to the agent loop​

import dev.langchain4j.service.tool.ToolProvider;

// AgentToolProviderFactory.java
Skills skills = SkillRegistry.getInstance(project).buildSkills();
if (skills != null) {
    providers.add(skills.toolProvider());     // adds activate_skill tool
    log.info("Skills tool provider included in agent tool chain");
}

skills.toolProvider() returns a Langchain4j ToolProvider exposing the activate_skill tool (plus an optional read_skill_resource helper). It is added alongside DevoxxGenie's built-in agent tools (read_file, write_file, run_command, parallel_explore and so on) and any MCP tool providers, then composed and wrapped with the existing approval and loop-tracking layers.

That's the full integration. The rest is wiring: a project-scoped SkillRegistry, a settings panel to enable/disable individual skills, and the small system-prompt augmentation that tells the model "these exist, here's how to activate them".

When to reach for which​

Use Commands for the things you trigger consciously, every day: "explain this", "write tests for this". Use Skills for repeatable agent behaviours that the model should reach for on its own: code-review checklists, framework-specific recipes, deployment runbooks, your team's commit-message conventions.

Try it out​

1. Drop a SKILL.md into ~/.claude/skills/<name>/ (or any of the other five locations).
2. In DevoxxGenie open Settings → Tools → DevoxxGenie → Skills, hit Reload, and confirm the skill shows up in the table.
3. Enable Agent Mode, pick a tool-capable model, and ask a question that matches the skill's description. The model will activate it on its own.

Full reference: Skills docs · Commands docs · Agent Mode.

Install: JetBrains Marketplace · GitHub

With DevoxxGenie's refreshed Exo integration, you can. Pool the memory of multiple Apple Silicon Macs into a single inference cluster and run models that would never fit on one machine. No subscription. No token budget. Just electricity.

Why Run Local?​

Cloud LLM providers charge per token, and those costs add up fast during agentic coding sessions where the model reads, writes, and re-reads files across dozens of tool calls. A single Agent Mode session can easily burn through thousands of input and output tokens.

Running locally flips the economics:

• Zero marginal cost: Once the hardware is on your desk, every token is free.
• Full data privacy: Your source code never leaves your network.
• No rate limits: No throttling, no quota exhaustion mid-session.
• Higher quantisation: Cloud providers typically serve heavily quantised models. With enough cluster RAM you can run Q6 or Q8 variants for noticeably better reasoning and code quality.

Big Models, Small Cluster​

A single M4 Max MacBook with 128 GB of unified memory can already run a lot. But the truly large models, the ones that rival cloud APIs in quality, need more. That's where Exo comes in.

Exo automatically discovers nearby Apple Silicon devices and distributes model layers across them using pipeline or tensor parallelism. Connect two Macs with a Thunderbolt cable and you've doubled your available memory.

Example setups:

All using the MLX backend, optimised for Apple Silicon.

A MiniMax M2.5 instance fully loaded and ready for chat across a two-node cluster.

Getting Started​

1. Install Exo on every device​

Download the latest DMG and launch it. Exo runs in the background and exposes a web dashboard at http://localhost:52415.

2. Connect your Macs​

Plug in a Thunderbolt cable for the fastest interconnect. Exo also works over regular networking, but Thunderbolt gives you significantly lower latency, especially important for tensor parallelism.

3. Download a model​

Open the Exo dashboard and pick a model. Start with something modest (Llama 3.3 70B Q4 at ~39 GB) to verify your cluster, then go bigger.

4. Point DevoxxGenie at Exo​

In Settings > DevoxxGenie > Large Language Models, enable Exo and set the URL to http://localhost:52415/v1/. Select Exo as your provider in the chat panel, choose your model, and start coding.

DevoxxGenie handles the rest: it previews placements, creates an optimal instance across your cluster, waits for warmup, and notifies you when everything is ready.

DevoxxGenie shows a progress bar while the model instance loads across your cluster.

The Exo cluster panel in DevoxxGenie shows connected nodes, memory usage, GPU stats, and the active model instance.

Works with Agent Mode​

The best part: Exo models work seamlessly with DevoxxGenie's Agent Mode. The LLM gets full access to built-in tools like file reading, writing, editing, searching, and command execution, all running through your local cluster.

Pair a powerful local model with Agent Mode and you have an autonomous coding assistant that:

• Costs nothing per token
• Keeps your code on your hardware
• Runs as many tool calls as you need without worrying about API bills

The Bottom Line​

You don't need a cloud subscription to use frontier-class LLMs for coding. A couple of Apple Silicon Macs, a Thunderbolt cable, and Exo give you a private AI cluster that rivals cloud APIs, at the cost of electricity.

Check out the full Exo documentation for setup details, supported models, sharding strategies, and troubleshooting tips.

Happy (local) coding!

With v0.9.17, DevoxxGenie integrates three best-in-class open-source security scanners directly as LLM agent tools. Your AI assistant can now scan your project on demand, interpret the results in context, explain each finding, suggest remediations, and automatically create prioritised backlog tasks — all from a single prompt.

Three Scanners, One Agent​

DevoxxGenie adds support for three complementary scanners that together cover the most common security risk categories:

Each scanner runs as a native binary on your machine — DevoxxGenie does not bundle or auto-download them, and nothing is sent to a remote service. Install them once via Homebrew (or your package manager of choice) and they're ready to go:

brew install gitleaks opengrep trivy

Scanning as an Agent Tool​

When Agent Mode is active and Security Scanning is enabled, the LLM gains four new tools:

• run_gitleaks_scan — detect hardcoded secrets
• run_opengrep_scan — SAST code security analysis
• run_trivy_scan — SCA dependency vulnerability scan
• run_security_scan — run all enabled scanners at once

You don't need to remember tool names. Just ask in plain language:

"Run a full security scan on this project and tell me what you find."

"Check my dependencies for known CVEs."

"Scan for hardcoded secrets and create backlog tasks for everything you find."

The agent invokes the scanner, reads the JSON output, and gives you a human-readable summary — with context about why each finding matters and how to fix it. Because the LLM sees your code alongside the findings, it can point you directly to the problematic line and suggest a concrete remediation.

From Finding to Backlog Task in One Step​

Security scan results are only useful if they get acted on. DevoxxGenie bridges the gap between finding and fixing with automatic Spec Browser task creation.

When Create Spec Tasks from findings is enabled, every finding is saved as a structured Backlog.md task:

• Title prefixed with [GITLEAKS], [OPENGREP] or [TRIVY] for easy filtering
• Priority mapped from the scanner's severity (high, medium, low)
• Labels security, scanner name and severity level
• Description with rule ID, affected file/package and remediation guidance

Re-running a scan won't flood your backlog — duplicate findings (matched by title) are skipped automatically.

Once the tasks are in the Spec Browser you can use the Agent Loop to implement remediations autonomously: select the security tasks, click Run All To Do, and let the agent work through them one by one.

Settings​

Everything is configured under Settings → DevoxxGenie → Security Scanning:

• Enable Security Scanning — master toggle for all agent tools
• Create Spec Tasks from findings — gate automatic task creation
• Per-scanner sections — each with a file browser to locate the binary, a Test button that verifies the binary is reachable and prints its version, and install links

The Test button runs the binary version command on a background thread and shows ✓ with the version string if the binary is found and working, or ✗ with the error message if something is wrong — no guessing required.

You can also control which individual tools the agent can call under Security Agent Tools, allowing you to enable only the scanners relevant to your project.

Get Started​

1. Install the scanners: brew install gitleaks opengrep trivy
2. Open Settings → DevoxxGenie → Security Scanning
3. Click Test next to each scanner to verify the setup
4. Enable Security Scanning and optionally Create Spec Tasks from findings
5. Start a conversation in Agent Mode and ask: "Run a security scan on this project"

Full documentation is available at genie.devoxx.com/docs/features/security-scanning.

Security scanning is available from DevoxxGenie v0.9.17, free as always on the JetBrains Marketplace.

Whether you maintain an IntelliJ plugin yourself or just want to understand how these integrations work under the hood, this post walks through the full picture: the integration API first, then the two concrete implementations with screenshots.

The Integration API​

Detecting DevoxxGenie at Runtime​

The first thing any integration needs to do is check whether DevoxxGenie is actually installed in the IDE. You don't want your plugin to blow up or show broken UI when DevoxxGenie isn't present. The check is a two-liner using PluginManagerCore:

import com.intellij.ide.plugins.PluginManagerCore;
import com.intellij.openapi.extensions.PluginId;

public static boolean isDevoxxGenieAvailable() {
    var plugin = PluginManagerCore.getPlugin(PluginId.getId("com.devoxx.genie"));
    return plugin != null && plugin.isEnabled();
}

Always guard your integration code with this check. If DevoxxGenie is absent, your plugin should degrade gracefully — hide the action, skip the menu item, or silently no-op.

Sending a Prompt via Reflection​

DevoxxGenie exposes ExternalPromptService as the entry point for receiving prompt text from other plugins. Rather than requiring a hard compile-time dependency on DevoxxGenie's JAR, you access it via reflection. This means your plugin can be distributed independently and will simply not call the API if DevoxxGenie isn't present:

public static void sendPrompt(Project project, String promptText) {
    if (!isDevoxxGenieAvailable()) return;

    try {
        Class<?> serviceClass = Class.forName(
            "com.devoxx.genie.service.ExternalPromptService"
        );
        Object instance = serviceClass
            .getMethod("getInstance", Project.class)
            .invoke(null, project);

        serviceClass
            .getMethod("setPromptText", String.class)
            .invoke(instance, promptText);

    } catch (Exception e) {
        // DevoxxGenie not available or API changed — fail silently
    }
}

setPromptText(String) populates the DevoxxGenie prompt input and submits it immediately, triggering a full LLM query with the current conversation context. The response appears in the DevoxxGenie chat panel — no polling, no callbacks needed on your side.

Backlog Task File Integration​

Not every finding warrants an immediate AI fix. Sometimes you want to defer resolution to a later session or hand it off to the Spec-Driven Development workflow. For this, integrations can write TASK-*.md files directly into backlog/tasks/ inside the project root:

---
id: TASK-7
title: Fix SonarLint java:S2259 in UserService.java:87
status: todo
priority: high
created: 2026-02-18
source: sonarlint
rule: java:S2259
file: src/main/java/com/example/UserService.java
line: 87
---

## Description

SonarQube rule **java:S2259** (Null pointers should not be dereferenced) triggered at
`UserService.java:87`.

## Acceptance Criteria

- [ ] Resolve the SonarLint finding without introducing regressions
- [ ] All existing tests pass

DevoxxGenie picks these up automatically — they appear in the Spec Browser's task list and Kanban board, ready for an agent to implement.

Task ID Synchronisation​

To avoid ID collisions across sessions, scan the three task storage locations before allocating a new ID:

Find the highest existing id: TASK-N value across all three, then increment by one. The full Java implementation is in the API reference.

Creating Tasks Programmatically​

For a simpler path that handles ID allocation and backlog initialisation automatically, use ExternalTaskService:

Class<?> svc = Class.forName("com.devoxx.genie.service.ExternalTaskService");
Object instance = svc.getMethod("getInstance", Project.class).invoke(null, project);
String taskId = (String) svc
    .getMethod("createBacklogTask", String.class, String.class, String.class, List.class)
    .invoke(instance, title, description, "high", List.of("sonarlint"));

This returns the created task ID (e.g. "TASK-5") and requires no manual ID scanning or directory setup. The trade-off: it supports only title, description, priority, and labels. For richer metadata (source, rule, file, line), write the file directly as shown above.

Full details in the API reference.

SonarQube / SonarLint Integration​

The SonarLint DevoxxGenie plugin is a fork of SonarLint for IntelliJ (v11.13) that adds a DevoxxGenie AI layer on top of standard SonarQube analysis.

The fork surfaces three entry points for acting on a SonarLint finding with AI.

Entry Point 1: Intention Action (Alt+Enter)​

Press Alt+Enter on any SonarLint-highlighted code and you'll see a "Fix with DevoxxGenie" intention action in the lightbulb menu. Select it and the prompt is assembled and submitted automatically — rule ID, rule description, severity, and ±10 lines of context all included.

Entry Point 2: Rule Panel Button​

Open the SonarLint tool window, select an issue, and look at the rule detail panel. A "Fix with DevoxxGenie" button appears in the header. Clicking it sends the same rich context to DevoxxGenie and focuses the chat panel so you can review the response.

Entry Point 3: Create DevoxxGenie Task(s)​

The SonarLint toolbar has a "Create DevoxxGenie Task(s)" action that does something different: instead of invoking the LLM immediately, it writes one or more TASK-*.md files into backlog/tasks/. This is the SDD integration path — defer the fix, let an agent handle it later.

What Context Gets Sent​

All three entry points build the same prompt from the same fields:

GitHub: github.com/stephanj/sonarlint-devoxxgenie-intellij Full docs: /docs/integrations/sonarlint

SpotBugs Integration​

The SpotBugs DevoxxGenie plugin is a fork of the JetBrains SpotBugs plugin that adds a DevoxxGenie AI layer for fixing static analysis findings. When SpotBugs detects a potential bug, you send it to DevoxxGenie for an AI-assisted fix — no manual copy-pasting required.

Three Entry Points​

1. Intention action — press Alt+Enter on SpotBugs-highlighted code. You'll see a "DevoxxGenie: Fix '[BugPattern]'" entry, e.g. DevoxxGenie: Fix 'NP_NULL_ON_SOME_PATH'. Selecting it assembles and submits the prompt immediately.

2. Gutter icon right-click — SpotBugs annotates flagged lines with a gutter icon. Right-clicking opens a context menu with a "Fix with DevoxxGenie" item alongside the standard SpotBugs actions. Useful when you want to stay in the editor without switching tool windows.

3. Bug details panel button — in the SpotBugs tool window, selecting a finding shows a details panel. The "Fix with DevoxxGenie" button there sends the full finding to DevoxxGenie with a single click.

Smart Context​

Regardless of which entry point you use, the prompt includes:

Scope Note​

SpotBugs DevoxxGenie is a prompt-sending integration only. It does not create backlog task files — it sends the finding directly to the active DevoxxGenie conversation for an immediate AI response. If you need deferred task-based resolution with SDD workflow integration, use the SonarLint fork above.

GitHub: github.com/stephanj/spotbugs-devoxxgenie-plugin Full docs: /docs/integrations/spotbugs

Build Your Own Integration​

The pattern is deliberately small. Here's what a minimal integration looks like end-to-end:

1. Check if DevoxxGenie is installed (PluginManagerCore.getPlugin("com.devoxx.genie"))
2. Build a rich prompt string from whatever context your plugin has (rule, file, code snippet, description)
3. Choose your delivery mechanism:
   • Immediate AI response → call ExternalPromptService.setPromptText() via reflection
   • Deferred SDD resolution (simple) → call ExternalTaskService.createBacklogTask() via reflection
   • Deferred SDD resolution (rich metadata) → write a TASK-*.md file to backlog/tasks/ directly

That's it. No SDK to pull in, no compile-time coupling, no registration required. If DevoxxGenie isn't installed, your code path silently does nothing.

The full API reference — including the TaskIdAllocator implementation, filename conventions, and frontmatter field definitions — is at /docs/integrations/overview.

If you build an integration, open an issue or PR on the DevoxxGenie GitHub repository — I'd love to list it in the docs.

Enjoy!

Links:

• Install DevoxxGenie from JetBrains Marketplace
• Plugin Integration API docs
• SonarLint DevoxxGenie on GitHub
• SpotBugs DevoxxGenie on GitHub
• DevoxxGenie GitHub Repository

ACP Runners open that door. Instead of unstructured text, they use the Agent Communication Protocol — a structured, bidirectional communication layer built on JSON-RPC 2.0 — to turn your IDE into a proper agent hub.

Why ACP?​

CLI Runners are effective for one-shot tasks: send a prompt, get a response, done. But modern AI coding assistants are becoming agents — they don't just answer questions, they plan, execute, report progress, and coordinate. Plain text pipes weren't designed for that.

ACP addresses this with a proper protocol:

• Typed messages instead of raw text — the IDE knows whether it's receiving a code edit, a terminal command, or a status update
• Capability negotiation — at startup, the IDE and the tool agree on what each side supports
• Persistent processes — the tool stays alive between tasks, eliminating cold-start overhead
• Structured streaming — response chunks are typed and ordered, not just lines of stdout

Think of CLI Runners as walkie-talkies. ACP Runners are a phone call — two-way, structured, and always connected.

How It Works​

DevoxxGenie spawns the ACP tool as a child process and communicates over stdin/stdout using JSON-RPC 2.0:

┌──────────────────┐  JSON-RPC 2.0   ┌──────────────────────┐
│  DevoxxGenie     │◀═══════════════▶│  ACP Tool            │
│  (ACP Client)    │  stdin/stdout    │  (Claude/Kimi/...)   │
└──────────────────┘                  └──────────────────────┘
        │                                      │
  1. Spawns process                   2. Handshake (initialize)
  3. Sends prompt via                 4. Streams structured
     ACP message                        response chunks back
  5. Receives completion              6. Process stays alive
     with metadata                      for next message

The protocol flow is straightforward:

1. Initialize — DevoxxGenie sends an initialize request with its supported capabilities; the tool responds with its own
2. Send Prompt — The task prompt is sent as a structured ACP message
3. Receive Response — The tool streams typed response chunks back — text, file operations, terminal commands
4. Completion — The tool signals it's done; DevoxxGenie processes the final result and the process stays alive for the next task

No MCP config file generation needed. No stdout parsing heuristics. The protocol handles context natively.

Supported ACP Tools​

DevoxxGenie ships with presets for five ACP-compatible tools, plus a custom option:

Claude Code doesn't natively speak ACP yet, but Zed Industries maintains the claude-code-acp bridge that wraps it in an ACP-compatible interface. Install it with npm install -g @anthropic-ai/claude-code-acp and you're good to go.

Setting It Up​

Setup is similar to CLI Runners — about a minute of configuration:

1. Go to Settings > Tools > DevoxxGenie > CLI/ACP Runners
2. Scroll to the ACP Runners section and click +
3. Select a Type from the dropdown — the executable path fills in automatically
4. Adjust the path if your tool is installed elsewhere
5. Click Test Connection to verify the ACP handshake succeeds
6. Apply and you're done

Selecting Your Runner​

The DevoxxGenie Specs toolbar includes an execution mode dropdown where ACP runners appear alongside CLI runners and the built-in LLM provider:

ACP runners show up prefixed with ACP: — so you'll see entries like ACP: Claude, ACP: Kimi, and ACP: Gemini next to the existing CLI runner options. The selection persists across IDE restarts.

ACP vs CLI Runners: When to Use Which​

Both runner types leverage your existing AI subscriptions. The difference is how they communicate:

Use CLI Runners when you want the simplest setup, when a tool doesn't support ACP yet, or when you're running one-off tasks where the overhead of a persistent process isn't worth it.

Use ACP Runners when you want richer agent interactions, structured streaming, and the efficiency of a persistent connection — especially for multi-task workflows like the Agent Loop where the tool handles multiple tasks in sequence without restarting.

Note that Claude Code is available in both modes: as a CLI Runner (direct stdin/stdout) and as an ACP Runner (via the claude-code-acp bridge). Try both and see which fits your workflow better.

The Bigger Picture​

DevoxxGenie's evolution follows a clear arc:

1. Chat — talk to an LLM inside your IDE
2. Agent Mode — let the LLM take actions on your codebase
3. Spec-driven Development — define structured tasks instead of ad-hoc prompts
4. CLI Runners — bring your own AI tools and subscriptions
5. ACP Runners — structured agent-to-agent communication

Each step builds on the previous. ACP Runners don't replace CLI Runners — they extend them for tools that support the richer protocol. And as more CLI tools adopt ACP, the integration will only get deeper: proper progress callbacks, multi-turn coordination, and true agent-to-agent collaboration.

The AI coding landscape is converging on protocols and standards. ACP is one of the emerging ones, and DevoxxGenie is ready for it.

Getting Started​

1. Update DevoxxGenie to the latest version
2. Go to Settings > DevoxxGenie > CLI/ACP Runners
3. Add an ACP tool (try Claude via claude-code-acp or Kimi)
4. Select it from the toolbar dropdown (look for the ACP: prefix)
5. Run a spec task or start a chat session

Same subscriptions. Smarter protocol. Better results.

Links:

• Install from JetBrains Marketplace
• ACP Runners Documentation
• CLI Runners Documentation
• Spec-driven Development Docs
• GitHub Repository

What if you could route all of that through a single interface inside IntelliJ, using the subscriptions you already pay for?

That's exactly what CLI Runners in DevoxxGenie do.

The Subscription Problem​

Most developers today are paying for at least one AI coding subscription. Claude Pro, GitHub Copilot, OpenAI's Codex — these are flat-rate monthly plans that give you access to powerful models. But using them typically means leaving your IDE: opening a terminal for Claude Code, switching to a browser for Copilot Chat, or running a separate CLI session for Codex.

Meanwhile, if you want AI inside your IDE through a plugin, you usually need to set up API keys and pay per-token on top of your existing subscription. You end up paying twice for the same models.

CLI Runners eliminate this problem entirely. DevoxxGenie launches your CLI tools as external processes, pipes task prompts to them, and streams the output back into IntelliJ's console — all while using your existing subscription, not a separate API billing account.

How It Works​

CLI Runners integrate directly with DevoxxGenie's Spec-driven Development workflow. When you select a task to implement, instead of routing it through a built-in LLM provider, DevoxxGenie can hand it off to an external CLI tool of your choice.

The system:

1. Launches the CLI tool as an external process
2. Pipes the task prompt via stdin (or as a trailing argument, depending on the tool)
3. Auto-generates an MCP configuration so the CLI tool can read and update your backlog tasks
4. Streams output into IntelliJ's Run tool window in real time
5. Reports exit code and elapsed time when the task completes

This means Claude Code, GitHub Copilot, and others can work on your spec-driven tasks with full awareness of your backlog — checking off acceptance criteria as they go.

Supported CLI Tools​

DevoxxGenie ships with built-in presets for five major CLI tools, plus a fully customizable option:

For tools with MCP support, DevoxxGenie automatically generates and injects the MCP server configuration. This gives the CLI tool access to the 17 backlog management tools — so it can create, edit, complete, and archive tasks just like the built-in agent does.

Setting It Up​

Configuration takes about a minute:

1. Go to Settings > Tools > DevoxxGenie > Spec Driven Dev
2. In the CLI Runners section, click +
3. Select a tool Type from the dropdown — defaults are populated automatically
4. Adjust the executable path if needed
5. Add any environment variables for authentication (e.g., API keys)
6. Click Test Connection to verify everything works
7. Apply and you're done

Switching Between Tools​

The DevoxxGenie Specs toolbar includes an execution mode dropdown where you can switch between the built-in LLM provider and any configured CLI runner. The selection persists across IDE restarts.

This makes it easy to keep multiple tools configured and switch depending on the task. Use Claude Code for complex refactoring, Copilot for quick fixes, or a local model via the built-in provider when you want to stay offline.

Interactive Chat Mode​

CLI Runners aren't limited to spec-driven task execution. You can also chat interactively with any configured CLI tool directly from the DevoxxGenie chat window. Messages are sent to the external tool, and responses stream back in real time.

This is where the subscription value really shines. Instead of burning API tokens at per-request rates, your conversations go through your existing monthly plan — whether that's Claude Pro, Copilot Business, or any other subscription. Same models, same quality, no extra cost.

Why This Matters​

The AI tooling landscape is fragmented. Every provider has their own CLI, their own interface, their own way of doing things. As a developer, you shouldn't have to choose one ecosystem and lock yourself in.

With CLI Runners, DevoxxGenie becomes a unified interface for all your AI coding tools:

• Use what you already pay for. No duplicate API costs. Your Claude Pro, Copilot, or Gemini subscription works directly inside IntelliJ.
• Stay in your IDE. No terminal hopping, no browser tabs. Everything streams into IntelliJ's console and chat windows.
• Keep your workflow. CLI Runners plug into the same spec-driven development and agent loop workflows. Your tasks, acceptance criteria, and backlog stay consistent regardless of which tool executes them.
• Switch freely. Different tools for different jobs. Configure them all, pick the right one for each task from a dropdown.

Bring Your Own Tool​

If your favourite CLI tool isn't in the preset list, the Custom type lets you configure any executable that can read prompts from stdin. Set the path, arguments, and optionally an MCP config flag — and it works like the rest.

Next Up: ACP Runners​

CLI Runners use stdin and MCP to communicate with external tools — and that works well. But the next evolution is already on the horizon: Agent Communication Protocol (ACP).

ACP is an emerging standard for structured, bidirectional communication between AI agents. Several CLI tools are beginning to adopt it, and once they do, the integration gets significantly richer. Instead of piping text prompts and parsing stdout, ACP enables proper agent-to-agent dialogue — task delegation, progress callbacks, structured results, and multi-turn coordination between DevoxxGenie's built-in agent and external CLI agents.

We're actively exploring ACP Runners as the next step. Same idea as CLI Runners — leverage the tools and subscriptions you already have — but with a protocol designed specifically for agents talking to agents. Stay tuned.

Getting Started​

1. Update DevoxxGenie to the latest version
2. Go to Settings > DevoxxGenie > Spec Driven Dev > CLI Runners
3. Add your preferred CLI tools
4. Select a CLI runner from the toolbar dropdown
5. Start implementing tasks — or just chat

Your AI subscriptions are already paid for. Now put them to work where you actually write code.

Links:

• Install from JetBrains Marketplace
• CLI Runners Documentation
• Spec-driven Development Docs
• GitHub Repository

What if instead of ad-hoc prompting, you could define exactly what needs to be built as a structured spec, and then let the AI agent implement it autonomously — checking off acceptance criteria as it goes?

That's the idea behind Spec-driven Development (SDD), the latest feature in DevoxxGenie v0.9.7.

The Problem with Ad-Hoc Prompting​

Most AI-assisted coding today is conversational. You describe what you want in natural language, hope the LLM understands the full picture, and manually verify the result. This approach has real limitations:

• Requirements get lost in chat history
• There's no structured way to track what's been done vs. what's pending
• You can't easily hand off work between sessions, developers, or agents
• Verification is manual and inconsistent

A More Disciplined Approach​

SDD flips the workflow. Instead of writing code instructions in chat, you write task specifications — structured markdown files with a title, description, acceptance criteria, priority, labels, dependencies, and milestones. These specs live in a backlog/ directory alongside your code, version-controlled like everything else.

I've intentionally aligned with the Backlog.md directory structure and workflow, so you can use their board or browser view side-by-side with the new IDEA SDD views that DevoxxGenie introduces.

The workflow is straightforward:

1. Create tasks from natural language​

Type something like "Create a task for adding JWT authentication to the REST API with acceptance criteria for login, token generation, and password hashing" in the DevoxxGenie chat. The agent creates a properly structured spec file automatically using one of the 17 built-in backlog tools.

2. Browse and organize in the Spec Browser​

A dedicated tool window in your IDE gives you two views:

A Task List grouped by status (To Do, In Progress, Done) with a detail preview panel:

A Kanban Board with drag-and-drop for visual task management:

3. Click "Implement with Agent"​

Select a task, click the button, and the agent takes over. It reads the full spec, explores your codebase, makes edits, checks off acceptance criteria one by one, records implementation notes, and marks the task complete when it's done.

Why This Matters​

SDD brings something that's been missing from AI-assisted development: traceability and structure.

• Specs are reproducible. They're plain markdown files. Commit them. Review them in PRs. Share them with your team.
• Progress is visible. Acceptance criteria get checked off as the agent works, so you can see exactly where things stand.
• Work is composable. Break a feature into multiple tasks with dependencies. Assign milestones. The agent respects the structure.
• Review is built in. Every completed task has implementation notes and a final summary documenting what was changed and why.

17 Tools, Full Lifecycle​

The agent doesn't just implement code — it manages the entire backlog programmatically:

• 7 task tools: create, list, search, view, edit, complete, archive
• 5 document tools: for supporting docs, design notes, API specs
• 5 milestone tools: for release planning and grouping

All accessible to the LLM in Agent mode.

Getting Started​

1. Update DevoxxGenie to v0.9.7
2. Go to Settings > DevoxxGenie > Spec Driven Dev and enable the Spec Browser
3. Click "Init Backlog" to create the directory structure
4. Start creating tasks from the chat prompt
5. Open the Spec Browser, pick a task, and let the agent do its thing

No external CLI tools needed. No npm packages. Everything runs inside your IDE.

The Proof is in the Pudding​

In the video above, I demonstrate how I built an SDD feature that adds a Trash icon to the Kanban view, allowing users to drag and drop a specific task to delete it. In less than a minute the spec was created, and in five minutes the spec was fully implemented and ready to ship — using Claude Sonnet 4.5 (not even Opus 4.6).

I could also have used a local model like GLM-4.7-Flash via Ollama, which works great, but that would have taken a bit longer to demo.

The Bigger Picture​

DevoxxGenie started as a simple LLM chat plugin. With Agent Mode, MCP support, and now Spec-driven Development, it's evolving into something more — an AI-augmented development environment where structured specifications replace ad-hoc prompts, and autonomous agents replace copy-paste workflows.

We're not just chatting with AI anymore. We're collaborating with it.

Try it out and let me know what you think. The plugin is free and open source.

Enjoy!

Links:

• Install from JetBrains Marketplace
• SDD Documentation
• GitHub Repository

Agent Mode with Parallel Sub-Agents​

The centerpiece of this evolution is Agent Mode. When enabled, the LLM doesn't just answer questions — it autonomously explores your codebase through seven built-in tools:

• read_file — inspect project files
• write_file — create new files
• edit_file — modify existing code
• list_files — browse directories
• search_files — find patterns via regex
• run_command — execute terminal commands
• parallel_explore — spawn concurrent sub-agents

Read operations auto-approve for efficiency, while write operations require explicit user confirmation via a diff preview. You stay in control.

Parallel Sub-Agents​

What makes this especially powerful is parallel sub-agents. Multiple read-only AI assistants can investigate different parts of your project simultaneously. Each sub-agent operates with:

• Isolated memory (no cross-contamination)
• Independent tool budgets
• Potentially different LLM providers

The main agent synthesizes their findings into a comprehensive response. This opens up interesting cost optimization strategies — use smaller, cheaper models like Gemini Flash or GLM 4.7 for sub-agents, while keeping a powerful coordinator like Claude Opus or GPT-4 as the main agent.

MCP Marketplace​

DevoxxGenie now integrates the Model Context Protocol (MCP), allowing agents to access external services — databases, APIs, documentation, cloud infrastructure — through standardized tool interfaces.

The built-in MCP Marketplace connects to an official MCP server registry, making it easy to discover and install servers with just a few clicks. No more manual configuration of JSON files or hunting for compatible servers.

Inline Code Completion​

For developers who want AI assistance without the overhead of a full conversation, DevoxxGenie now offers real-time inline code completion using local Fill-in-the-Middle (FIM) models.

Key characteristics:

• Runs entirely locally via Ollama or LM Studio — your code never leaves your machine
• Smart post-processing: suffix overlap detection, leading newline stripping
• Caching: recent completions are cached for instant retrieval
• Configurable: debounce delay (100–2000ms), max tokens (16–256), timeout (1–30s)

Supported models include StarCoder2 3B, Qwen 2.5 Coder, and DeepSeek-Coder — all running locally for complete privacy.

Built for Developer Control​

DevoxxGenie is built entirely in Java using Langchain4J and supports both local providers (Ollama, LM Studio, GPT4All, Llama.cpp) and cloud services (OpenAI, Anthropic, Google Gemini, Mistral, DeepSeek, and more). With over 42,000 downloads on the JetBrains Marketplace, it's become a go-to tool for Java developers who want flexibility in their AI tooling.

The plugin prioritizes developer control across every dimension:

• Model selection — use any provider, switch freely
• Approval workflows — confirm writes before they happen
• Spending — track token costs in real-time
• External service access — MCP tools are explicitly configured
• Code privacy — local models for sensitive codebases

What's Next​

This is just the beginning. With Spec-driven Development (SDD) now available in v0.9.7, you can define tasks as structured specs and let the agent implement them autonomously — complete with acceptance criteria tracking and a visual Kanban board.

We're not just chatting with AI anymore. We're collaborating with it.

Try it out:

• Install from JetBrains Marketplace
• Full Documentation
• GitHub Repository

A New Approach to AI Code Assistance​

Most AI coding assistants lock you into a specific model or cloud provider. DevoxxGenie takes a different approach, giving you the freedom to choose how you want to use AI in your development workflow:

• Run models locally for privacy and offline use
• Connect to cloud providers for more powerful capabilities
• Switch between providers as needed without changing tools

Key Features​

DevoxxGenie offers a comprehensive set of features that integrate seamlessly with your development workflow:

Multi-Provider LLM Support​

Connect to a wide range of LLM providers:

• Local Providers: Ollama, LMStudio, GPT4All, Llama.cpp, and more
• Cloud Providers: OpenAI, Anthropic (Claude), Mistral, Groq, Google (Gemini), and others

Advanced Context Features​

• MCP Support: Access external tools and services for enhanced capabilities
• Project Scanner: Add source code to prompt context for better responses
• Chat Memory: Maintain conversation context for more coherent assistance

Developer-Focused Tools​

• Git Diff/Merge: Review and accept AI-generated code changes with a Git diff interface
• Web Search: Augment LLM knowledge with web search results
• Token Cost Calculator: Manage API usage efficiently
• MCP Support: Model Context Protocol for extended capabilities

Getting Started​

Setting up DevoxxGenie is easy. Install the plugin from the JetBrains Marketplace, connect it to your preferred LLM provider, and start prompting. The plugin supports various workflows:

1. Code Explanation: Select code and ask for explanations
2. Generation: Request code generation for specific functionality
3. Refactoring: Get suggestions for code improvements
4. Learning: Ask questions about frameworks, libraries, or concepts

Why DevoxxGenie?​

1. Built in Java: Created by Java developers for the Java ecosystem
2. Provider Flexibility: Use any supported LLM provider
3. Privacy Options: Run models locally to keep your code private
4. Deep Integration: Works seamlessly with IntelliJ IDEA
5. Open Source: Community-driven development

The Future of DevoxxGenie​

The DevoxxGenie team is actively working on enhancing the plugin with new features:

• Enhanced MCP Support: More specialized tools for development tasks
• Agentic AI: More sophisticated reasoning and planning capabilities
• Improved Multimodal Support: Better handling of visual elements

Join the Community​

DevoxxGenie is an open-source project, and we welcome contributions from the community. Whether you're fixing bugs, improving documentation, or adding new features, your help is appreciated!

Check out our GitHub repository to get involved.

Ready to try DevoxxGenie? Install it from the JetBrains Marketplace and experience the next generation of AI-assisted development!