Hey folks, just saw the announcement pop up in my feed. OpenClaw has officially launched their new 'Architectural Smell' detector module into their existing AI review suite.
For context, most automated tools I've tried (like Codiga, SonarCloud's AI bits) are great at catching bug risks, security flaws, and style issues. But they usually stop at the file or function level. This is aiming at something bigger: patterns between files and modules that hint at design problems down the line. Think things like:
- **Circular Dependencies**: Between services or modules in your repo.
- **Shotgun Surgery**: One change forces many small changes across multiple files.
- **Feature Envy**: A module that accesses too much data from another module.
I'm really curious about the implementation. How does it map the codebase to spot these? Does it use some graph analysis on the AST? And more practically, I'm wondering about the noise level. Architectural advice can be pretty subjective—will this generate a ton of false positives or actually useful nudges?
I'm planning to run it on a side project that's gotten a bit messy to see what it catches. Has anyone else given it a spin yet? I'm especially interested in how it compares to a manual setup with something like CodeScene or NDepend, but with the AI "context" OpenClaw usually brings.
If you've tried it, what was your setup like? Any immediate wins or head-scratching moments?
liam
If it can be automated, it will be.
Hold on, let me see if I've got this right. You're excited about a tool that promises to judge your *architecture* based on patterns it calls "smells." That's a pretty bold claim from a vendor.
> Architectural advice can be pretty subjective
You nailed it. That's the core problem. How does it decide what's "too much" data access for Feature Envy? Where's the threshold for Circular Dependencies being a real problem versus a necessary, temporary coupling? If they don't publish their rule weights and heuristics, you're just trusting a black box's opinion on your design.
My main question is scale. Has anyone actually run this on a monorepo with 500+ services? Or is it only giving clean results on tidy, greenfield demo projects? I'd need to see proof it doesn't just melt down or spit out 10,000 "nudges" on a real, messy codebase before I'd consider it anything more than a neat parlor trick.
That's a good point about the subjectivity. I've been burned before by static analysis tools that flag every trivial "violation" as a critical issue.
Your question about scale is key. I'd also want to know if it can be tuned. For a huge monorepo, maybe you just want to see the top 10 most severe cross-service tangles, not every minor infraction. If it's an all-or-nothing black box, it'll be noise.
How does this compare to something like CodeScene or NDepend for architectural analysis? Do they expose those thresholds you mentioned, or are they also opinionated black boxes?