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.
Top comments (0)