DEV Community: Viktoria

Explyt 5.17 Lets It Refactor the Project.

Viktoria — Wed, 19 Aug 2026 07:33:09 +0000

Move, Delete, Rename, run, and debug through JetBrains IDE mechanisms instead of reconstructing project relationships from text alone.

AI coding agents are good at producing patches. The harder problem begins when a change crosses file, package, module, or runtime boundaries.

Move a class through the file system and its package may become wrong. Delete an entity without checking usages and another module may stop compiling. Rename a symbol as text and unrelated strings can change with it.

JetBrains IDEs already resolve many of these relationships. Explyt 5.17 gives agents a direct path to that project knowledge.

The central change in Explyt 5.17 is simple: an agent can ask the IDE to perform and inspect engineering operations that the IDE already understands.

Why Are File Edits Not Enough?
A repository is more than a collection of text files.

Code entities are connected through:

resolved symbol references;
imports and package declarations;
module and source-root boundaries;
run configurations;
debugger state;
framework and language support;
generated code and configuration.
A text edit can produce a clean-looking diff while missing one of those connections. Explyt 5.17 reduces that risk by routing supported refactoring operations through native JetBrains IDE mechanisms.

The IDE contributes indexes, symbol resolution, usage search, conflict detection, and refactoring support. The agent contributes task planning, tool selection, and follow-up verification.

What Changed in Refactoring?
Earlier versions already supported Rename. Explyt 5.17 adds Move and Delete.

Move
Move can relocate supported files, folders, and code entities through IDE refactoring.

For a class moved to another package, the IDE can update the package declaration, imports, and resolved references it recognizes in the open project. Before the operation is applied, the agent receives information about affected locations and conflicts.

This is materially different from moving a file and repairing references afterward with a sequence of searches and edits.

Delete
Delete checks usages before removing a supported entity.

The agent can inspect the dependencies found by the IDE, revise its plan, and handle affected code before deletion. This makes the usage check part of the operation rather than an optional cleanup step after the entity has disappeared.

Rename
Rename continues to operate on code entities and their resolved references rather than every matching character sequence.

Depending on the language, entity type, and IDE support, the operation may also include related elements. Renaming a class, for example, may include its file name.

What Does the Agent See Before a Change?
Explyt can expose the IDE's refactoring preview and conflict information to the agent.

Before Move, Delete, or Rename is applied, the operation can identify:

the elements selected for the change;
files and references included in the refactoring;
conflicts that block or complicate the operation;
related entities the IDE proposes to update.
That preview matters most when a task spans several packages or modules. It gives the agent evidence about the scope before files are written and creates a checkpoint where the plan can change.

inspect scope → review conflicts → apply a bounded refactoring → build → test → inspect the diff

This loop is stronger than treating a successful tool call as proof that the task is complete.

Where Does IDE Analysis Stop?
IDE-backed refactoring improves the evidence available to an agent. It does not guarantee complete dependency discovery.

Results depend on:

language and framework support in the installed JetBrains IDE;
successful completion of project indexing;
the relationships the IDE can resolve;
reflection and other dynamic references;
generated code;
configuration files and templates;
references held in external systems;
text mentions that are not symbol references.
A large refactoring still needs a diff review, a build of affected modules, and relevant tests. If the change touches runtime behavior, reproduce the affected path or inspect it with the debugger.

Can External Agents Use the Same IDE Tools?
Yes. Explyt 5.17 includes an MCP server that runs inside the IDE.

It can connect Claude Code, Codex, Cursor, OpenCode, and other MCP-compatible clients to selected IDE operations in the context of the open project.

The external client keeps control of its own model, prompts, context, and call sequence. Explyt executes the selected IDE tool calls and does not provide inference in this mode.

The MCP server is available free without an Explyt subscription.

This gives developers a practical way to keep their preferred agent while adding structured access to JetBrains IDE capabilities.

Which Tool Groups Can You Expose?
The server configuration lets you enable only the groups required for the current task:

project navigation;
run configurations;
debugger operations;
IDE refactoring.
The client does not receive every IDE capability automatically. Its available tools depend on the selected server configuration.

That boundary supports a narrower setup: a client investigating a failing test may need navigation, run, and debugger tools but no refactoring access. A client reorganizing packages may need navigation and refactoring, followed by a run configuration for verification.

How Do You Inspect MCP Calls?
The MCP server window includes a call log.

For each request, you can inspect:

the tool requested by the external agent;
the arguments sent with the call;
the response returned by the IDE tool;
the step at which an error occurred.
This creates a concrete record of the interaction between the agent and the IDE. If a debugger workflow fails, you can see whether the problem came from the selected tool, its arguments, the run configuration, or the returned state.

Before sharing logs or server configurations, review them for local paths, source code, and other project data that should remain inside the working environment.

What Does Chat Branching Actually Separate?
Explyt 5.17 can create a new chat from a selected message.

The new conversation inherits history up to that point. From there, the two chat histories develop independently. This is useful when one investigation produces several directions:

tests in one chat and documentation in another;
implementation in one chat and code review in another;
competing architecture discussions from the same initial context;
a fresh path after an unsuccessful approach.
The separation applies to conversation history, not to project files.

Both chats continue to work with the same open project and the same file system. A change made from one chat is visible to the other. Chat branching does not create a Git branch, worktree, project copy, or isolated workspace.

Use Git branches or worktrees when parallel alternatives must not modify the same files.

What Else Improved in 5.17?
The release reduces unnecessary background work by refreshing the context panel less often and processing internal project data more efficiently. Internal log growth is limited as well.

It also fixes reliability issues in several paths:

background tools resume work in chats more reliably;
tool calls recover more correctly from incomplete arguments;
absolute Windows paths are handled correctly;
issues involving enterprise models are fixed;
large MCP server responses are handled more reliably.
These fixes require no extra configuration after the update.

A Practical Verification Loop
IDE access is useful when it shortens the distance between a proposed change and evidence about its effect.

For a refactoring task, use this loop:

Wait for indexing to finish.
Ask the agent to identify the target entity and affected scope.
Inspect the IDE preview and conflicts.
Apply one bounded Move, Delete, or Rename operation.
Review the resulting diff, including configuration and generated-code boundaries the IDE may not resolve.
Build the affected modules through the relevant run configuration.
Run focused tests.
For runtime-sensitive changes, reproduce the path and inspect state through the debugger.
Repeat with the next bounded operation.
For an external MCP client, add two checks:

enable only the tool groups needed for the task;
confirm the first request, arguments, and response in the call log.
This keeps the agent's work observable and makes completion depend on project evidence, not on a plausible patch.

Try Explyt 5.17
Update Explyt from Settings | Plugins | Installed, restart the IDE if prompted, open the project, and wait for indexing to finish before the first refactoring.

If you use Claude Code, Codex, Cursor, OpenCode, or another MCP client, open the Explyt MCP Server window, select the required tool groups, start the server, connect the client, and inspect its first call in the log.

Explyt is available from the download page.

Sources
Explyt 5.17: IDE refactoring and an MCP server for external agents - product facts, capabilities, limitations, setup, and release fixes.
Building a Fair Benchmark for AI Agent Memory Systems - editorial reference for article pacing and section structure only; its benchmark topic, claims, and wording were not reused.

#java

Viktoria — Mon, 17 Aug 2026 15:07:53 +0000

Stop Copying Random Code Snippets And Finally Build Your Persistence Layers With Ease And Confidence!

Viktoria — Mon, 17 Aug 2026 11:43:04 +0000

Viktoria

Aug 17

How to Configure an AI Agent for Your Project: Context, Rules, Skills, MCP — A Java/Kotlin Playbook

9 min read

How to Configure an AI Agent for Your Project: Context, Rules, Skills, MCP — A Java/Kotlin Playbook

Viktoria — Mon, 17 Aug 2026 07:54:19 +0000

This article distills two of our April webinars with a developer of the Explyt agent. The takeaways are general enough that you can verify every claim on your own project — and if you work in Java or Kotlin, most of them land even harder, because a strongly typed, tooling-heavy stack is exactly where good context wins or loses.
Press enter or click to view image in full size

Agent output quality = context quality. Everything else is downstream.

There are five customization levers: rules, skills, agent modes, MCP, and AgentIgnore. Each has its own use case.
AGENTS.md is the project's source of truth. The memory bank is long-term memory.

The two main anti-patterns: insufficient context and overloaded context. Opposite fixes, opposite symptoms.
A TDD/SDD approach with an agent yields the best quality. With local models it’s critical.

Evolution: from autocomplete to agentic systems
The chain is short:
StageWhat it doesMain painAutocompletecontinue a line, finish a functioncontext = current fileChat assistantsdialogue, explaining codehuman = proxy, copy-pasteAgentsread/edit files, run commands, MCPone context overloadsAgentic systemsorchestrator + sub-agents, rolessetup complexity
With chat assistants the developer constantly copied code back and forth — hence “lots of manual work and broken context.” Agents live inside the project, see all the code, and have tools. On top sit agentic systems that coordinate several specialized agents and solve the single-context overflow problem.

Where the agent lives: three classes of tools
Console agents

They live in the terminal. They run on a remote server or in CI and parallelize easily via git worktree.
ProsConsNo IDE vendor lock-inLess control during developmentCan run in CI/CDNo language semantics — only LSPParallelism across many agentsNo autocomplete for controlled generationRiskier security-wise (filesystem access)
Examples: Claude Code, Codex, Gemini CLI, Aider, Goose, Amp (can commit on its own). Fully autonomous: AutoGPT, SWE-agent, OpenHands.

Agents inside the IDE
They understand the language better: PSI / indexes, refactorings via the IDE API, semantic search (Find Usages, Go to Declaration). For a Java/Kotlin codebase this is the difference between an edit that compiles and one that’s a lucky text guess. A familiar UI is an underrated adoption factor for teams.
ProsConsLanguage understanding via PSITied to one IDEDeveloper’s familiar UIHarder to parallelizeHarder to run in CI
Examples: Cursor (a VS Code fork), Explyt, Windsurf, Junie, AI Assistant.

Agents in CI/CD
Async PR review, description generation, auto-fixes, changelogs.
ProsConsA single review standardTake the human out of the loop, slow pipelinesUnpredictable token costsFalse positives kill trust in reviewAccess to sensitive infrastructure
Examples: CodeRabbit, PR-Agent (Codium Merge), GitHub Copilot for PRs, GitLab Duo (can hunt for vulnerabilities).

Fully autonomous
They take a task from a Jira/GitHub issue and go solve it without a human: AutoGPT, SWE-agent, OpenHands.

Context: where it comes from and how it breaks
Manual collection — @-attaching files, classes, methods. Sometimes more reliable than automation, especially when you know exactly what the result should look like.
Automatic collection — three industry approaches:
ApproachWhat it givesWhere it breaksLSP serversAST, syntaxno semantics, poor with broken codePSI (JetBrains)dependency graph, inheritance, inspections, understands broken codetied to the JetBrains platformCode RAGembeddings, flexible searchindivisible code gets chunked; knows nothing about compilation
PSI is the only one of the three that sees code semantically: it knows for a fact that a method is inherited, that an annotation applies, that a function is used right here. This is precisely the Java/Kotlin superpower — overrides, generics, Spring bean wiring, annotation processing. PSI also works with broken code, so it can explain to the agent exactly what the compilation error is.
The one rule
Result quality depends on context quality. No matter how good the agent is, on bad context it won’t produce the right solution.
Anti-pattern 1: insufficient context

Symptom. The agent solves the wrong task.
Fixes:
Edit the message you already sent instead of tacking on a correction. If you reply “no, you misunderstood,” the agent sees both the original task and the fix in context and starts to get confused.
Use rules for repeated instructions that migrate from chat to chat.
Pass the full spec via MCP — from Jira, Confluence, GitHub.
Plan before solving — most agents can decompose a task before starting. That gives you a de facto spec immediately.
Anti-pattern 2: overloaded context
Symptom. The agent mixes different tasks or suddenly starts solving a third thing.
Fixes:
One task = one chat. A big task → decompose into subtasks in separate chats.
Chat compression — a feature in most agents. It compresses the context into a summary so you can move to a second related task without carrying the whole history.
Five levels of customization
LevelWhat it isWhen to use itRulesrules injected into the system promptcode style, working around model bugs, shell instructions, MCP prioritizationSkillsa description of how to solve a specific task (frontmatter + resources + scripts)recurring tasks: test generation, migrations, refactoringsAgent modesown model, system prompt, tools, and skills per rolea dedicated agent for testing, debugging, analyticsMCP serversexternal toolsJira, Confluence, GitHub/GitLab, Figma, Playwright, Chrome, secrets, TDD flowAgentIgnoreread/write restrictionslegacy, secrets, TDD
Rules
Text rules added to every chat’s system prompt.
What to write:
the rule’s scope (where it applies, where it doesn’t);
what is strictly forbidden.
A classic case is PowerShell on Windows. Most models learned on bash/zsh and get confused on PS. One dedicated rule about PowerShell specifics fixes it once and for all.

Other common uses:
agent style (autonomous vs. controlled);
corporate code style (Google Java Style, parameterized tests — right at home for Java/Kotlin teams);
working around specific model bugs (e.g., Claude 4.5 Sonnet likes to create lots of reports — you can rein it in);
MCP prioritization — if the agent doesn’t call a connected server, spell out when and why to use it.

Skills
Unlike rules, a skill describes how to solve one specific task.

Structure:
skills/
└── my-skill/
    ├── SKILL.md      # prompt + frontmatter with a description
    ├── scripts/      # scripts the agent can call
    └── references/   # docs and specs

The frontmatter holds the skill’s name and description. From the description the agent decides when to invoke it. Manual invocation — /skill_name.

Important about context. Until the skill is invoked, the agent sees only the frontmatter description — no resources or scripts enter the context. That’s what saves you from pollution.

Recommendations:
one goal per skill (even if it has subtasks);
scope and prohibitions — mandatory;
reference scripts and resources from SKILL.md, or the agent won't "notice" them;
the folder structure (scripts/, references/) is optional, but the agent navigates it better;
top-down (write everything at once) is slow and blind to whether it’s needed. Bottom-up (extract from frequently repeated requests) is more practical;
you can generate skills with the agent itself, but validate them by hand.
Compatibility. The SKILL.md format has become a cross-vendor standard — supported by Claude Code, Cursor, Codex, Copilot, and Explyt. A skill written for Claude Code works in Explyt and vice versa.
Agent modes (roles / sub-agents)
Customizable:
the model (e.g., a lightweight model is enough for a tester agent, a stronger one for an architect);
the system prompt describing the role;
the set of available tools;
the set of skills.
A common mistake is describing the role via the org chart (“architect,” “team lead,” “DevOps”). Better to start from the tasks the agent solves. The model doesn’t understand “architect”; it does understand “generates dependency diagrams and checks for cycles.”
Most agents ship with Plan mode and Code mode out of the box. Many can orchestrate — picking which sub-agent to call for a given step.
MCP servers
Not a complicated thing: most often an MCP is a proxy between the model and a service. It parses the model’s arguments, makes an HTTP request, squeezes the response to fit the context limit, and hands it back.
Useful ones:
GitHub MCP — reading repos, search, issues, PRs, branches, commits, review.
Atlassian MCP — Confluence (CQL search, pages) and Jira (JQL search, statuses). Very valuable — that’s where all the company’s domain logic lives.
Figma MCP — project structure, layers, components, variables. Doesn’t handle motion/animation.
Playwright MCP — turning manual clicks into automated tests.
Chrome MCP — DevTools in the agent’s hands.

If the agent doesn’t call an MCP — write a rule, a skill, or a dedicated agent explicitly meant for that MCP.
AgentIgnore
Same syntax as .gitignore. Vendors use different names: .cursorignore, .codeiumignore; Explyt splits "don't read" and "don't edit" into separate lists.
Scenarios:
SituationWhat to forbidLegacy / stable moduleswriting (reading is fine — for understanding)A module too complex, you don’t trust the agentwritingSecrets, creds, .envreading and writingTDD: don't bend tests to the implementationwriting to the test folder
Important. Via the run-command tool, the agent could in theory bypass AgentIgnore. Good agents put a small checker model next to command execution, but even that can be worked around with a clever script. This applies to every vendor — an open question for the industry.
Documentation for the agent
AGENTS.md
A file in the project root. It goes into the system prompt — the agent always knows about it.
What’s inside:
project structure by folders and modules;
the stack;
build and test commands;
code style;
architectural paradigms;
what is strictly forbidden.
Creation — usually an /init command (often a skill) that walks the project and assembles a first AGENTS.md. After generation, validate it: an error in this file lives in context forever. Version it in the repo as the team's source of truth.
Tip: don’t bloat it. The file is added to every chat and eats context. If AGENTS.md grows to 1000 lines, it's no longer help — it's load.
Memory Bank
The agent’s long-term memory — a folder of Markdown files with a size cap. The logic:
Every N messages, the agent pulls relevant facts and adds them to context.
Every N messages, it saves new facts from the current dialogue.
On overflow, it summarizes and drops the irrelevant.
The goal: with each new chat, the agent understands your project better.
Caveat: the smaller N, the higher the token spend. Some agents use N = 1, which becomes constant extra load on the provider.
Context pollution: what the agent should do, and what you should do
The agent:
Cache tokens with the chosen provider — cached tokens are much cheaper.
Auto-compress the chat when the context fills up (thresholds like 75%, 80%).
Save tool results to a file and give the model only the structure. Especially important for unpredictable MCPs whose response easily overloads context.
You:
Know your provider. Anthropic’s cache lives for 5 minutes — small tasks are faster and cheaper within that window.
Compress the chat manually when you see it’s full. Remember: it’s not strictly positive — quality can suffer.
Turn off unneeded tools. Tool descriptions eat context on their own.
Compress AGENTS.md and rules if they've grown and gone stale.
Project setup checklist
StepTimeWhat to do1. AGENTS.md~10 min/init + manual validation2. AgentIgnore5–15 minlegacy, secrets, TDD dirs3. MCP30 minconnect Jira, Confluence, GitHub; compare community vs. official4. Rules15 minagent style + model bug workarounds5. Skillsas neededcheck existing ones in registries first6. Commit1 mincommit it — a single source of truth for the team
Q&A from the chat
Which tasks simply can’t be solved with an LLM? There’s no hard “can’t” if a human sits alongside and validates. Be careful with tasks demanding strict determinism (vulnerability hunting with complex algorithms) — better to give the agent a specialized tool via MCP. With weak/small models, agentic pipelines struggle.
How do you avoid regressing to a junior when using AI? Validate generated code; don’t accept it blindly. Grow expertise in architecture, review, planning, specs. Technical expertise will be needed at any moment.
Cursor vs. IDE agents — worth switching? Cursor is a VS Code fork; you’d have to change your environment. If you’re used to JetBrains, try plugins: Junie, AI Assistant, Explyt. Switching to Cursor pays off only if IDE agents lack the features you need.
When to use SDD, and when not to overcomplicate? It depends on task complexity relative to the model:
Simple tasks — just dive in.
Medium and complex — SDD/planning.
If the agent drifts — roll back, write a plan or spec, continue from it.
If the agent is on track but doesn’t finish — TDD: fix the validation system and let the agent work until the tests go green.
How to control token consumption? Split tasks. One task, one chat. Make sync points through a plan file that carries progress — so sub-agents with small contexts see the big picture.
Which local models are good on limited hardware? There are solid options in the ~32B range with a good quality/cost balance; larger models are better but need more hardware. Very large models can be quantized, but carefully.
Which local-LLM features work in development (think, web)? Thinking works (for local models the concern isn’t token cost but server load). Web/external sources help. Inside the agent, tools like running inspections are critical.
Can analysts and testers use AI? They can and should. Testing and analytics map well onto agents, but the agent must be customized to the role — dedicated skills, corporate rules, task decomposition.
Wrapping up
For Java/Kotlin teams the throughline is simple: the agent is only as good as the context you feed it, and this stack rewards agents that understand code semantically — PSI, real type resolution, inspections, safe refactorings. Set up AGENTS.md, lock down what the agent may touch, connect the MCPs that hold your domain knowledge, and codify your conventions as rules and skills. Do that once, commit it, and every chat starts smarter than the last.

Code Clean-up Agents: the new 2026 niche between AI generation and shipping

Viktoria — Fri, 14 Aug 2026 11:00:51 +0000

Vibe coding solved the wrong half of the problem.

Generation got fast. Everything after generation didn't.

The first PR out of an agent looks fine. The fifth PR looks like it was written by three different developers on three different days. Somewhere in there is a SQL injection the agent copied from a training example, and nobody checked.

That's the gap a new category is built for in 2026: Code Clean-up Agents.

What the category does Three jobs AI generation leaves behind: Refactor the accumulated diff into something one person could have written. Hunt vulnerabilities in code assembled faster than it was reviewed. Standardize naming and conventions so AI-written files match the rest of the codebase.

Why now A feature that took three days now takes thirty minutes to generate. Review still takes three hours: reading, re-running, hunting vulnerabilities, re-deriving what the IDE already knew. The bottleneck didn't disappear. It moved from generation to everything after it.

The SDLC is growing a stage Old cycle: plan, code, test, deploy. Current cycle: plan, AI-generate, code, test, deploy. 2026 cycle: plan, AI-generate, Code Clean-up, test, deploy.

Play
Most "AI coding agents" skip that middle stage and ship whatever generation produced.

What makes one real, not a renamed coding agent Six IDE-native facts, not guesses: Run Configurations, Decompile, Inspections, Debugger, Coverage, Edit Scope (agent touches only what it's told to, every change accepted by a human, auditable by anyone).

One engineering team put a number on the split: roughly 25% of a developer's day is spent writing code, the other 75% is everything around it. The goal behind a Code Clean-up Agent is to cut that 75% by roughly 5x. That's a target the team is building toward, not a blanket guarantee for every codebase.

The hard part is control A Code Clean-up Agent that ships on its own is just an AI coding agent with a new label. The category only works if every change comes with an itemized receipt. The developer accepts. A reviewer can audit.

Explyt is built as an IDE-native Code Clean-up Agent. You accept. A reviewer audits.

Stop Treating Green Tests as Proof That Your AI Agent Wrote the Right Code

Viktoria — Wed, 12 Aug 2026 09:43:01 +0000