The extended guide to the webinar: methodology, approaches, feedback loops, parallel work and subagents, and personal setup — everything from the session, in one place, ready to apply in your IDE.
Questions after the webinar? Message me on LinkedIn — I'm happy to help.
The vocabulary used throughout the guide. Everything else builds on one idea: output quality equals context quality.
AGENTS.mdOutput quality = context quality.
The cost of working without a methodology shows up in three ways.
The agent confidently solves the wrong task. It invents requirements and relies on assumptions. Hours of work go to waste.
The code looks correct and passes a quick review. A week later, it breaks in production. Debugging costs more than starting from scratch.
It works this time, but not the next. You cannot share the practice with your team or scale it.
The percentage of context used directly affects the quality of the model's responses.
Completely empty context (never happens)
An empty chat
Model response quality declines
The model cannot respond
Context-usage figures reproduced from the webinar presentation.
Every anti-pattern has a symptom you can spot and a set of fixes you can apply.
The agent solves the wrong task. It fills in the gaps for you, relies on assumptions, and hallucinates.
Example: you ask to "add tests" — the agent adds unit tests, but you wanted e2e tests. The agent is not to blame: it did not know.
The agent mixes up tasks. It returns to old tasks, mixes them together, and loses focus.
Example: you spend three hours on different tasks in one chat. On the fourth task, the agent applies a pattern from the first to code from the third.
The code looks correct. It passes your visual review but breaks in production.
Example: you skipped the tests and trusted what you saw. The agent sounds confident, as though it tested the code. A week later, a bug appears in production.
Idea: solution quality depends on an accurate understanding of the project and a precise task description. So a specification is needed before implementation — a reusable project description and a task description. Writing specifications takes effort, so the agent drafts them in planning mode; you validate and edit.
AGENTS.mdA reusable project description, stored in the repository and shared with the team. In Explyt, create and update it with a Skill.
Create AGENTS.md for the current project
During specification, the agent gathers extensive context and summarizes it. During implementation, the agent uses the specification without context overload.
The agent writes them — you just review and refine.
Solution quality = project understanding × task precision.
A sample task-01.md the agent drafts in Plan mode. You review it, fix it, and approve it. Then the agent implements from this file, not from a long chat history.
# Task 01 — Rate-limit GET /api/orders
## Context
- Service: order-service (Spring Boot 3, Java 21), see AGENTS.md
- Source: GitHub issue #482
- Touches: OrderController, ApiKeyFilter
## Goal
Limit each API key to 100 requests per minute on GET /api/orders.
## Requirements
1. Over the limit → 429 Too Many Requests with a Retry-After header.
2. Limits are per API key, not per IP.
3. Configurable: orders.rate-limit.per-minute (default 100).
4. Requests without an API key still return 401 (unchanged).
## Out of scope
- Other endpoints
- Distributed (multi-node) limits
## Design
- New RateLimitFilter, registered right after ApiKeyFilter.
- In-memory token bucket per API key (Bucket4j).
## Acceptance criteria (tests first)
- [ ] 100 requests within a minute → all 200
- [ ] 101st request → 429 + Retry-After
- [ ] Two API keys have independent limits
- [ ] Property override changes the limit
- [ ] ./gradlew check passes (tests + linter)
## Plan
1. Write failing tests: RateLimitFilterTest (MockMvc).
2. Add Bucket4j and RateLimitProperties.
3. Implement RateLimitFilter.
4. Run tests until green, then review (max 3 rounds).An agent can always make mistakes. It needs a way to self-check before handing work to a human.
The agent writes tests.
The agent writes code.
The agent runs tests.
What should the tests be based on?
Connect GitHub MCP and attach the issue link.
SDD controls the input; TDD controls the output. Together they catch errors before a human ever sees them.
Creates a high-quality description of the project and task.
Creates an automated system for validating the output.
Six steps from issue to merge. You own the checkpoints; the agent does the work in between.
Issue link, goal, constraints. AGENTS.md already gives project context.
Plan mode → task-01.md with acceptance criteria and a plan.
Fix wrong assumptions now. Mistakes here are the cheapest to fix.
✓ checkpointFailing tests from the acceptance criteria. You approve them, then lock them with Edit scope.
✓ checkpointCode → run tests → fix. It repeats until every check passes.
↻ loopA review agent runs at most 3 rounds, then you read the diff and merge.
↻ loopSpend your attention on steps 3, 4 and 6. Everything between them is the agent's job.
Task complexity increases from simple / prototype to complex. Escalate the approach only when the simpler one fails.
| Task complexity | Approach | What to do |
|---|---|---|
| Simple / prototype | Vibe coding | Create AGENTS.md, choose the right agent mode and Skill, describe the task in the chat. |
| Medium / complex | SDD | The agent misunderstands the task → add a specification. |
| Medium / complex | TDD | The solution is buggy → add tests before implementation. |
| Complex | SDD + TDD | Still not solved? Combine both. |
Approve every step.
Validate the plan, the review, and the code itself.
Validate only the output.
Greater autonomy requires better context and stronger validation.
The agent runs the checks itself and keeps working until the criterion is met.
Keep writing code until all tests in the e2e folder pass
Anything the agent can check on its own and report back.
Tests are green but check nothing. The agent edits tests instead of code: weakens assertions, uses mocks, or marks tests as skipped. Example: a test was failing, so the agent disabled it — the criterion is technically met, but the bug remains.
.agentignore (Explyt: quick "Edit scope" settings)Tests catch broken behaviour. A review agent catches the rest: missed requirements, risky code, weak tests. Let the agent fix what the review finds, but cap the number of rounds.
Implement the task from task-01.md. When all tests pass, run a review subagent on your diff. If it reports problems, fix them and run the review again. Do at most 3 review rounds. Stop when the review is clean or after round 3, then report: what you fixed, what is still open, and why.
Agents praise their own work. A fresh context, or a model from another vendor, sees what the author missed.
Without a cap, the agent can loop forever on nitpicks, burn tokens, or start rewriting good code. Anything still open after 3 rounds needs a human decision.
A subagent is a separate agent with its own context, system prompt, and tools.
By task type: review, testing, and code search.
The subagent returns only the result, without cluttering the main chat.
Independent tasks run in parallel.
"We have seen teams spend months building complex multi-agent architectures, only to discover that better prompting of a single agent delivers the same result."
Work that splits cleanly into separate steps.
A single agent is the better default.
Advanced AI agents decide when to launch subagents (Claude Code, Cursor, Explyt in general mode). But the system is not perfect: it may launch too many or too few. Set boundaries and preferences with Rules and Skills.
git worktree — multiple working copies of one repository, each on a different branch. Scenario: each working copy has its own agent. One agent builds feature A, another builds feature B, while you review a bug fix.
Realistically, you can supervise 2–3 agents at once. Your review is the bottleneck, not code generation.
Agent settings live in two places: your home directory, and the repository.
Not added to the repository.
Version-controlled and committed.
AGENTS.md, project Rules and Skills — shared across the team..agentignore — agent access boundaries within the project..explyt/memory/; belongs to this project only.Assets are the part of the harness you control. Each one enters the agent's context differently. Pick the kind that matches the problem.
Standing instructions
Added to the system prompt, for files that match their pattern.
“Answer in English. Use JUnit 5 and AssertJ. Never edit generated code.”
Know-how on demand
The agent sees only the name + description and opens the full SKILL.md when a task needs it.
“Review a DB migration against the team checklist.”
~/.explyt/skills.explyt/skills/<name>/SKILL.mdExternal tools
The agent calls them to read or act outside the IDE; only the tools you allow.
“Read issue #482 from GitHub” · “Open the page in Playwright.”
~/.explyt/mcp_servers.json.explyt/mcp_servers.jsonThe agent should always follow it → Rule. It's a procedure for some tasks → Skill. It needs data or actions outside the IDE → MCP. Personal → global scope; team → project scope.
Memory Bank is project memory: durable, non-obvious knowledge about this project — conventions, pitfalls, decisions — stored as Markdown in the project's .explyt/memory/ folder. There is no personal memory that follows you from project to project: keep your own preferences in global Rules and personal Skills.
An index (MEMORY.md) plus one file per entry in .explyt/memory/. Readable and editable by hand.
The agent sees the index and opens the entries relevant to your request.
It adds new entries and merges or removes outdated ones.
Goal: capture project knowledge once — where the agent can find it next time — instead of re-explaining it. Keep personal preferences in global Rules. In Explyt, Memory Bank was introduced in release 5.14.
Just run Onboard the Agent to Your Project. The agent asks about your preferences and proposes ready-to-use Rules, Skills, and AGENTS.md.
Onboard the Agent to Your Project
If you have questions about the webinar, want to share how the approach worked for your team, or got stuck setting up your agent — write to me on LinkedIn. I read every message.
Sergey covers the practical side of working with AI coding agents in Java and Kotlin projects — methodology, specification-driven workflows, and the feedback loops that keep generated code trustworthy in IntelliJ IDEA and the full JetBrains IDE family.
Ask me a question on LinkedIn