how to search a huge java repo without running out of context

Launch Atlas subagents with the task tool, one per Maven module. Each subagent reads its module in its own session and returns only conclusions, so the file dumps never enter your main context. Merge the findings into one todowrite list afterward.

how should i split a maven multi-module audit

Slice by module first, since each module in the parent `pom.xml` has its own `src/main/java` tree and is a natural independent unit. If one module is still too large, slice it by package, or slice by rule when the audit has several distinct checks.

atlas task cancelled what does it mean

The task tool reports Task cancelled when a subagent was cancelled, and surfaces the child's error text verbatim when it fails. That distinction lets you re-launch only the failed slice of the Java audit rather than the whole sweep.

where do i apply the fixes an audit finds

In the main session, with the edit tool, after merging every subagent's findings into one todowrite list. Fixes interact and should be reviewed together, and Atlas computes a unified diff for every edit and surfaces it for approval before writing.

Audit a Repo With Parallel Subagents in Java Using Atlas (2026)

To audit a Java repository with parallel subagents, split the sweep into independent slices and launch one Atlas task per slice. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, and the task tool launches each subagent in its own session, so the files it dumps never enter your context: only its conclusions come back. In a multi-module Maven build that means one subagent per module under `src/main/java`, each returning findings rather than file contents. Use subagent_type explore, which is deny-by-default and read-only, for an audit where nothing should change. Merge the findings into one todowrite list, fix them in the main session with edit, then verify with JUnit 5 via mvn test.

How do I audit a large Java repo without blowing the context window?

Atlas's task tool launches subagents in their own sessions, so their file dumps never enter your context: only their conclusions come back. A Maven reactor with 12 modules and thousands of classes under `src/main/java` cannot be read into one session, but 12 subagents each reading one module can.

Context is the binding constraint on any repository-wide audit. Reading a Java codebase directly means every class, every interface, every `package-info.java` lands in the transcript, and the useful conclusion is buried in it. A subagent reads all of that inside its own session and returns a short answer: the 4 classes in this module that catch Exception and swallow it, with file and line. The main session receives 4 findings, not 400 files. That is what makes a whole-repo sweep possible at all.

How do I slice a Maven multi-module project for parallel subagents?

Split the Java audit into independent slices so the subagents do not overlap, along 1 of 3 axes: by module, by package, or by rule. A Maven reactor gives you the slicing for free, since each module listed in the parent `pom.xml` is already an independent unit with its own `src/main/java` tree.

Overlap is waste and it produces duplicate findings that then have to be reconciled. Slice by module first, because module boundaries are the natural seams in a Maven or Gradle build. If a single module is too large, slice it further by package: `com.example.orders` to one subagent, `com.example.billing` to another. Slicing by rule is the other axis, and it works when the audit has several distinct checks: one subagent looks for raw types, another for missing @Override, another for JUnit 5 tests annotated @Disabled. Use glob to enumerate the Java source roots before you decide the slices.

What is the difference between the explore and general subagent in Atlas?

Atlas offers 2 subagent types for an audit. The explore subagent is deny-by-default and read-only, which makes it the right one for a Java sweep where nothing should change. The general subagent can act, so reach for it only when the subagent must also run a command such as `mvn test` inside a module.

Choosing the wrong subagent type is the main safety mistake in a parallel sweep. An audit is a read: it should not edit `src/main/java`, should not touch `pom.xml`, and should not run a build. subagent_type explore enforces that by being deny-by-default, so the audit cannot mutate the repo even if the model decides it would be helpful. Reserve general for the cases where execution is genuinely required, for instance a subagent that must run JUnit 5 via mvn test in one module to see whether a suspected dead test still compiles. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and the explore subagent is the strictest end of that spectrum.

How do I make Atlas subagents run concurrently instead of one after another?

Issue the task calls together so they run concurrently rather than one after another. Launching 8 Java module audits sequentially takes 8 times as long as launching them in one batch, and Atlas fans out work to subagents that can run in the foreground or in parallel background sessions.

Concurrency here is not a micro-optimization, it is the difference between a sweep that finishes and one that is abandoned. Batch the task calls in a single turn, one per Maven module, each with the same audit instruction and a different scope. Collect each subagent's final message when they return. The task tool surfaces the child's error text verbatim if it fails, and reports Task cancelled if it was cancelled, so a subagent that died on a malformed glob is visibly distinct from one that found nothing. Re-launch just the failed slice rather than the whole sweep.

How do I turn Java audit findings into fixes?

Merge the findings from every subagent into one todowrite list and fix them in the main session with the edit tool. A Java audit across 12 Maven modules typically returns 30 or 40 findings, and a single ordered list is what stops the long tail from being quietly dropped after the first few obvious ones.

Fixing belongs in the main session, not in the subagents, because the fixes need to be reviewed together and they interact. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each change to a class under `src/main/java` is a reviewable patch. After the edits, run JUnit 5 via mvn test through bash to confirm the audit fixes did not break behavior, then run Spotless so the touched classes match the project's formatting. Atlas snapshots file changes as git patches, so a fix applied across many modules can be rolled back rather than hand-reverted.

Step by step

01Use glob to enumerate the Java source roots and the modules listed in the parent `pom.xml` before deciding how to slice the audit.
02Split the audit into independent slices (by Maven module, by package such as `com.example.orders`, or by rule) so the subagents do not overlap.
03Launch one Atlas task per slice with subagent_type explore for a read-only sweep, since explore is deny-by-default and cannot mutate `src/main/java`.
04Use subagent_type general only when a subagent must also run a command, for example JUnit 5 via mvn test inside one module.
05Issue the task calls together so they run concurrently rather than one after another.
06Collect each subagent's final message; the task tool surfaces the child's error text verbatim if it fails, and Task cancelled if it was cancelled, so re-launch only the failed slice.
07Merge the findings into one todowrite list and fix them in the main session with the edit tool, reviewing the unified diff before each write.
08Run JUnit 5 via mvn test through bash to confirm the fixes did not break behavior, then run Spotless over the touched classes.

Frequently asked questions

how to search a huge java repo without running out of context: Launch Atlas subagents with the task tool, one per Maven module. Each subagent reads its module in its own session and returns only conclusions, so the file dumps never enter your main context. Merge the findings into one todowrite list afterward.
atlas explore vs general subagent: The explore subagent is deny-by-default and read-only, which makes it correct for an audit where nothing should change. The general subagent can act, so use it only when the subagent must run a command such as JUnit 5 via mvn test inside a module.
how do i run atlas subagents in parallel: Issue the task calls together in one batch rather than one after another. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so 8 Maven module audits complete in roughly the time of the slowest one.
how should i split a maven multi-module audit: Slice by module first, since each module in the parent `pom.xml` has its own `src/main/java` tree and is a natural independent unit. If one module is still too large, slice it by package, or slice by rule when the audit has several distinct checks.
atlas task cancelled what does it mean: The task tool reports Task cancelled when a subagent was cancelled, and surfaces the child's error text verbatim when it fails. That distinction lets you re-launch only the failed slice of the Java audit rather than the whole sweep.
can a subagent accidentally change my java code during an audit: Not if you use subagent_type explore, which is deny-by-default and read-only. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and explore is the strictest end of that spectrum.
where do i apply the fixes an audit finds: In the main session, with the edit tool, after merging every subagent's findings into one todowrite list. Fixes interact and should be reviewed together, and Atlas computes a unified diff for every edit and surfaces it for approval before writing.
what do i run after fixing java audit findings: Run JUnit 5 via mvn test through bash to confirm the fixes did not break behavior, then run Spotless so the touched classes under `src/main/java` match the project's formatting before you commit.

Try Atlas in your terminal

The terminal-native AI coding agent. Free core, single binary.

Install Atlas

Related guides

Audit a Repo with Parallel Subagents in Atlas (2026 Workflow)

How to audit a repo with parallel subagents in Atlas in 2026: the task tool launches explore subagents in their own sessions, so only conclusions return to your context.

Atlas for Java in 2026

Adopt Atlas, the terminal-native AI coding agent, for Java development in 2026. Enhance your workflow with intelligent code search, refactoring, and robust safety features for Maven and Gradle projects.

Trace a runtime bug from a stack trace in Java with Atlas (2026)

Trace a Java runtime bug from a stack trace in 2026 with Atlas: read each frame at its offset, grep for the message string, and lock the fix with JUnit 5 via mvn test.

Onboard to an Unfamiliar Java Codebase with Atlas (2026)

Atlas maps an unfamiliar Java repo by meaning, not filenames: codebase_search ranks declarations, glob reveals the Maven module layout, and a read-only explore subagent fans out.

Review a Pull Request in Java with Atlas (2026)

Atlas reviews a Java pull request by pulling the raw diff with bash, reading changed classes in full, and running the lsp tool's findReferences on every changed signature.

Debug a Single Failing Test in Java with Atlas (2026)

Fix the code, not the assertion. Atlas runs one JUnit 5 test in isolation via mvn test in 2026, walks the call path with the lsp tool, and edits the Java that is wrong.

Run the Test Suite and Triage the Failures in Java with Atlas (2026)

Turn a wall of red Maven output into a ranked list of root causes. Atlas runs JUnit 5 via mvn test in 2026, saves the full log, and triages Java failures by cause.

Plan a Multi-File Change Before Editing in Java with Atlas (2026)

Plan a Java refactor with Atlas in 2026 before touching src/main/java: plan mode denies edits, the lsp tool maps the class hierarchy, and plan_exit gates the handoff.

Browse this resource hub