1
Methodology
Why working without a methodology is expensive. Three anti-patterns — insufficient context, overloaded context, blind trust — and how to fix each one.
Explyt / Webinar
Working with AI Tools at the User Level
Methodology, Specification-Driven Development, feedback loops, and subagents — a practical framework for senior Java developers and team leads who need predictable results from AI coding agents, not vibe coding.
Reserve your seat
Leave your email and we'll send you the recording link and the setup guide from the webinar.
You're registered.
We'll send the recording link and setup guide to your inbox.
What you'll learn
Five modules, from methodology to personal setup
Each module addresses a real problem Java teams face when working with AI coding agents — from Spring context loss to Maven build failures — and gives concrete, repeatable solutions you can apply the same day.
2
Approaches: SDD + TDD
Specification-Driven Development: the agent writes the spec, you validate it. Test-Driven Development: a validation system before the implementation.
3
Feedback Loops
Give the agent a "goodness" criterion: tests pass, linter clean, coverage above threshold. Plus the anti-pattern — fitting tests to broken code.
4
Parallel Work & Subagents
When to delegate to subagents and when a single agent is faster. Git worktrees for running multiple agents in parallel on different branches.
5
Personal Configuration
Global Rules, personal Skills, and long-term memory — settings that travel with you across projects. A 30-minute setup guide you can run today.
Module 1 · Methodology
Anti-pattern 1
Anti-pattern 2
Anti-pattern 3
Three anti-patterns that waste hours
Every anti-pattern has a symptom you can spot and a set of fixes you can apply. The golden rule: the quality of the result equals the quality of the context.
Insufficient context
The agent solves the wrong task. It fills in the gaps with assumptions and hallucinates.
Example: you say "add tests" — the agent adds unit tests, but you wanted end-to-end tests. The agent isn't at fault: it didn't know.
- Be precise. Not "add tests" but "add unit tests for class X."
- Rules + AGENTS.md. Project conventions, style, libraries — once, not every chat.
- Specification-Driven Development. Write the spec before implementation.
Overloaded context
The agent jumps between tasks. It returns to old problems, mixes contexts, loses focus.
Example: three hours in one chat solving different tasks. On the fourth task, the agent applies a pattern from task one to code from task three.
- One chat — one task. Start a new task, open a new chat.
- Break big tasks into subtasks. Each subtask gets its own chat.
- Compress the chat. After solving the first task, compress before moving to the next.
Blind trust in the result
The code looks correct. It passes a visual review. Then it breaks in production a week later.
Example: tests weren't run — you trusted your eyes. The agent writes confidently, as if it tested. A week later, a bug ships to prod.
- Automated validation. Tests, linters, scripts — not just eyes.
- Human-in-the-loop. Review the agent's work at key checkpoints: spec, plan, tests.
- Review agent. Always a separate agent — and ideally a different vendor's model.
Module 2 · Approaches
SDD + TDD: control the input, control the output
Specification-Driven Development gives you control over what goes in. Test-Driven Development gives you control over what comes out. Together, they form a "claw" that catches errors before a human ever sees them.
Input control
SDD — Specification-Driven Development
The agent gathers context and produces a specification before writing any code. You review and revise the spec. Implementation uses the spec as a single source of truth — without overloading the chat context.
Project
AGENTS.md
→
Task
Plan
→
Spec
Before code
Output control
TDD — Test-Driven Development
The agent can always make a mistake — so it needs a way to self-check before handing off to a human. Tests are written first, the implementation follows, and the agent runs the tests itself. Red → implement → green.
Tests
Agent writes
→
Code
Agent implements
→
Run
Green?
When to use what
From vibe coding to SDD + TDD
Not every task needs the full methodology. Match the approach to the complexity — but know what breaks when you skip ahead.
| Task complexity | Recommended approach | What happens if you skip methodology |
|---|---|---|
| Simple / prototype | Vibe coding | Works fine for throwaway code |
| Medium / moderate | SDD | Agent misunderstands the task, produces buggy output |
| Complex | TDD | No reproducibility, bugs hide until production |
| Mission-critical | SDD + TDD | Unrecoverable — wrong task, hidden bugs, no way to scale |
Module 3 · Feedback Loops
Give the agent a "goodness" criterion
Instead of reviewing every line yourself, define what "done" means. The agent runs the check and keeps working until the criterion is met.
What a good criterion looks like
"Write code until all tests in the e2e folder pass." The agent runs the check and iterates until the criterion is met.
- Linter passes with no warnings
- Unit, integration, and automated tests pass
- No compilation errors (Explyt checks automatically)
- Test coverage above threshold
- UI works on basic scenarios (Playwright MCP, Chrome MCP)
Anti-pattern: tests fitted to the code
Tests are green but verify nothing. The agent weakens assertions, mocks everything, or skips failing tests instead of fixing the code.
- Lock the test directory via .agentignore (Explyt: quick "Edit scope")
- One agent writes tests, a different agent writes the implementation
- Review test diffs first with a separate Review-agent, then by eye
Quick wins
What you can apply today
You don't need to adopt the whole framework at once. These changes work in any AI coding agent.
One chat — one task
Stop mixing tasks in a single conversation. New task, new chat. The simplest change with the biggest impact.
Write an AGENTS.md
Describe your project once: tech stack, conventions, directory layout. Every new chat starts with shared context.
Define a done-criterion
Tell the agent what "finished" means — tests pass, linter clean, coverage threshold — and let it iterate.
Review with a separate agent
Agents praise their own work. Always review with a fresh context — ideally a different model.
Lock the test directory
Prevent the agent from editing tests to make them pass. Explyt's Edit scope makes this a one-click setting.
Set up in 30 minutes
Global rules, one or two personal skills, and memory. Explyt's onboarding skill interviews you and proposes ready-made config.
Speaker
About the speaker
Sergey Pospelov
Explyt Team
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.
FAQ
Frequently Asked Questions
Do I need Explyt to apply these methods?
No. The methodology works with any AI coding agent. Some features mentioned — Edit scope, onboarding skill, automatic compilation checks — are Explyt-specific, but the core principles apply everywhere.
Is this for Java developers only?
Explyt is built for Java and Kotlin teams in JetBrains IDEs — IntelliJ IDEA, Android Studio, and the full JetBrains family. The methodology (SDD, TDD, feedback loops) is language-agnostic, but every example in this webinar uses Java and Spring Boot code running in IntelliJ.
How long does it take to set up?
The webinar includes a 30-minute setup guide: global rules (10 min), one or two personal skills (10 min each), and memory (5 min). Explyt's onboarding skill does most of the work for you.
What if my team is new to AI coding agents?
Start with Module 1 (methodology) and the Quick Wins section. The anti-patterns are the most common failure modes — avoiding them early saves the most time.
Where can I find the recording and notes?
The recording is available on the Explyt YouTube channel. Extended notes are published on the Explyt blog.
Get started
Try the methodology in your IDE
Explyt runs inside IntelliJ IDEA and the full JetBrains IDE family. IDE-native debugging, semantic refactoring, test coverage feedback, and agent onboarding — built for senior Java and Kotlin teams working on production Spring Boot and enterprise code.