Your AI Doesn’t Know Your Microservices Depend On Each Other
Why static analysis at the module boundary matters for AI-assisted development
You ask Claude to delete an unused utility class.
Twenty lines. Looks clean. Claude confirms the change is safe.
Then your CI pipeline lights up.
Forty-seven test failures across six modules.
Your payments-service imported it. So did notifications-service. And the integration tests in e2e-tests. And a Spring configuration in auth-service that wired it as a bean.
Claude didn’t see any of this.
It saw one file in one module.
The other six modules might as well have been in a different repository.
This isn’t a Claude problem. It’s a context problem.
And it’s getting worse as AI coding tools become more autonomous.
The blind spot every multi-module project has
Java is the language of enterprise software, and enterprise software lives in multi-module projects.
Spring Boot microservices. Maven reactors with twenty services. Gradle multi-project builds with shared libraries.
The standard layout looks like this:
my-platform/
├── pom.xml
├── auth-service/
│ └── src/main/java/com/example/auth/
├── payments-service/
│ └── src/main/java/com/example/payments/
├── notifications-service/
│ └── src/main/java/com/example/notifications/
└── shared-lib/
└── src/main/java/com/example/shared/
A symbol defined in shared-lib might be imported by all three services.
Delete it, and you break three downstream consumers.
When you point an AI agent at this codebase, it reads files. Maybe one. Maybe fifty.
It does not read all 1,800 files across all fifteen modules to understand which imports cross module boundaries. That would consume more tokens than the project budget allows.
So the AI guesses.
Pattern matching on filenames. Searching for likely consumers. Reading what looks relevant.
It misses what doesn’t look relevant.
That’s where production bugs ship from.
What an AI agent actually needs
The mental model a senior engineer builds during their first month on a project includes:
- Which files import from which other files
- Which modules depend on which other modules
- What breaks if you change a specific symbol
- What architectural patterns does the code follow
This is graph data.
Nodes are files, classes, and functions.
Edges are imports, calls, and inheritance.
Building this graph by reading files at AI runtime is impossibly expensive. Building it once, deterministically, and serving it to the AI on demand is the right architecture.
That’s what Depwire does.
It builds a deterministic dependency graph using tree-sitter, then exposes it to AI coding agents through MCP.
Until last week, multi-module Java projects had a partial blind spot.
The fix
For multi-module Maven projects, Depwire was checking only the standard source root at the project’s top level.
It would find src/main/java directly under the root, but it would not traverse into module subdirectories.
In a single-module project, this works.
In a fifteen-module project, fourteen modules are invisible.
The new release adds a module discovery pre-pass.
Before parsing source files, Depwire now:
- Reads pom.xml and extracts <module> entries recursively, including nested modules
- Reads settings.gradle.kts and extracts include() declarations, including Kotlin DSL and Groovy
- Builds a verified set of module source roots
- Feeds these roots to the Java and Kotlin import resolvers
The change is architecturally clean.
Existing single-module behavior is preserved as a fallback.
Nothing previously working can break.
What the numbers look like in real code
The fix was tested against google/guice, the canonical Java dependency injection framework.
Guice is a 13-module Maven project with 647 Java files across core, extensions, and tests.
Before:
Total edges: 5,972
Cross-file Java import edges: 0
Cross-module Java edges: 0
After:
Total edges: 10,081
Cross-file Java import edges: 2,247
Cross-module Java edges: 759
The dependency graph went from “useless on multi-module Java” to “captures 759 real cross-module relationships.”
The most useful test:
What happens if you simulate deleting Injector.java, the core interface that powers Guice’s dependency injection?
$ depwire whatif . --simulate delete \
--target core/src/com/google/inject/Injector.java
Result:
Action: DELETE core/src/com/google/inject/Injector.java
Affected Nodes: 128
Broken Imports: 124
Cross-module: 106 across 10 extension modules
124 files break.
10 different extension modules feel the impact.
An AI agent making this change without visibility into these dependencies would silently break the entire Guice ecosystem.
With Depwire’s What If simulation, the AI sees the impact before it commits the change.
The change gets refined, or it gets escalated.
How does this fit into your workflow
The fix is in depwire-cli@1.7.1.
If you’re working on a multi-module Java or Kotlin project:
npm install -g depwire-cli@1.7.1
depwire parse .
Or connect it to your AI assistant via MCP.
Claude Desktop config:
{
"mcpServers": {
"depwire": {
"command": "npx",
"args": ["-y", "depwire-cli", "mcp"]
}
}
}Then ask your AI things like:
- “What breaks if I delete this file?”
- “What depends on the Injector class?”
- “Show me the cross-module impact of refactoring this service.”
The answers come from the graph, not from guessing.
Why this matters more than it sounds
AI coding agents are getting more autonomous.
Cursor and Claude Code already make multi-file edits without explicit human approval on each change.
The next generation will run unsupervised against entire codebases.
When agents operate at that level of autonomy, the cost of a blind spot multiplies.
An agent that doesn’t see module boundaries will eventually delete something it shouldn’t, refactor across a boundary it shouldn’t cross, or introduce a circular dependency it can’t see.
The deterministic graph is what keeps autonomous agents from making confident mistakes.
It’s foundational architecture for production-ready AI development, not optional.
Depwire is one piece of that foundation.
The fix in v1.7.1 closes one of the JVM ecosystem's biggest gaps.
If you’re building with AI agents on multi-module Java or Kotlin projects, it’s available today.
Try it:
npm install -g depwire-cli
Repo: https://github.com/depwire/depwire
Cloud: https://app.depwire.dev