Some time ago I joined a project where I had to extend an existing MuleSoft solution. The Low-Level Design (LLD) existed, and the code was there. But after months of active development, reality had drifted.
There were clear discrepancies between the design document and the final implementation. This was not intentional. It is just what happens when systems evolve under pressure.
To fix this gap, I started using AI to generate post-implementation documentation. Think of it as an extended LLD that reflects reality.
The ACB Workspace Workflow#
I cannot share the exact project code, but the process is highly repeatable. I open my MuleSoft applications inside an Anypoint Code Builder workspace. Then, I point AI directly at the codebase.
I tested this approach with both Claude Code and MuleSoft Vibes. Both handled the context exceptionally well.
Instead of asking for a generic summary, I tell the AI exactly which feature I am investigating. I instruct it to analyze the code from the top down.
Ask the AI to document specific implementation decisions, not just component names. You want to know why a particular caching strategy or routing logic was chosen based on the code structure.
Prompting for Reality#
The quality of the output depends on how you frame the request. I always ask the AI to move from the general flow down to specific details.
Here is the baseline prompt structure I use:
Analyze the feature [Feature Name] across the Mule applications in this workspace.
Write a post-implementation document going from a high-level overview to specific low-level details. Include sequence diagrams with flow in mermaid.
Explicitly list all implementation decisions you can infer from the code (e.g., error handling, mapping logic).
Initial LLD vs. Post-Implementation Doc#
Having an initial LLD is good. Having a post-implementation document is gold, especially if the original LLD lacked detail.
| Characteristic | Initial LLD | AI Post-Implementation Doc |
|---|---|---|
| Timing | Written before code exists | Generated from the final codebase |
| Focus | Design intent and assumptions | Actual reality and applied workarounds |
| Value | Secures approval and sets direction | Identifies tech debt and undocumented features |
Do not treat AI output as unquestionable truth. It is a starting point. You still have to review it and verify it against your own architectural understanding.
Once I had both documents side by side, I could clearly see the delta between the design intent and the implementation. This gave me the confidence to expand the solution safely. I understood what was actually built, not just what was planned.
I want to leave you with a question. Are you doing something similar on your projects? I am curious if others are using AI to close the documentation gap.
Key Takeaways
- LLDs and actual code often drift apart over time.
- AI tools like Claude Code and MuleSoft Vibes can reverse-engineer reality from ACB workspaces.
- Ask the AI to move from general overviews down to specific implementation decisions.
- Comparing initial design intent with implementation reality makes extending existing solutions much safer.