Debugging and Impact Analysis

Two of the hardest questions in engineering both come down to following code you did not write: "why is this happening?" and "what will break if I change this?" ProdE already understands how your repositories connect, so instead of tracing it all by hand you can just ask.

You have two places to do this, and both draw on the same understanding. Use whichever you are already in:

• ProdE Chat when you are investigating away from the code.
• Your coding agent, through ProdE's MCP server, when you are already in your editor and want to go from diagnosis straight to a fix.

Ask for a Root Cause Analysis

Describe the symptom and ask ProdE to investigate. It traces the behavior across services and gives you the likely root cause, grounded in the actual code, rather than leaving you to read through it yourself.

• "Users report their profile photo reverts to the old one a few minutes after upload. Investigate and give me the root cause."
• "Checkout intermittently fails with a 500 at the payment step. Trace the flow across services and tell me what is most likely causing it."
• "This job occasionally processes the same record twice. Where could the duplicate be coming from?"

Because ProdE searches across all connected repositories, it follows the path past a single service boundary, which is where these bugs usually hide.

If you are in ProdE Chat, you can ask ProdE to capture the issue and its root cause as a document, then hand that document to your coding agent to implement the fix.

Ask What a Change Will Affect

Before you change something, ask what depends on it. ProdE finds the callers and consumers across every repository, so the blast radius is concrete rather than a guess.

• "What calls the shared auth library's validateToken, and what would break if I change its signature?"
• "If I change the shape of the orders API response, what consumes that response?"
• "What depends on the users table having unique emails?"

The same question works from your coding agent, where find_symbol_usages surfaces every place a function, class, or variable is used across a repository. When the work is part of a Project, capture the decision or any risk you uncover as a blocker or in an engineering document, so the reasoning is visible to the team and nothing is rediscovered later.

---

Related: To get oriented in an unfamiliar service first, see Onboarding a Codebase. To build with full context once you know what to change, see Building with Your Coding Agent.