Sensez Catches Agent Code Smells
This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.
Sensez provides static feedback on duplication, dead code, dependency cycles, architecture boundaries and design smells. Its MCP integration puts findings inside the coding-agent workflow, where the agent can act before handing over a patch.
The project reports improvements in its own evaluations. Those results do not establish a return on investment for your team. This article assesses the documented workflow and proposes a local trial; it does not report an independent benchmark or hands-on product test.
Establish the baseline before asking for a change
A scan of an older repository can surface debt that predates the agent’s task. Save the initial report and commit identifier. Otherwise a reviewer cannot tell whether the agent introduced a cycle, inherited it, or removed one part while exposing another.
The project documents sensez init for configuration and MCP registration, and sensez noze . for a scan. Inspect the configuration changes made by initialization, then restart the agent if required by the client. Choose the installation method documented for your language and environment.
Keep the first task bounded: change one service behavior that already has a test. Record the exact test command in AGENTS.md if it is a durable repository convention. A static report and a behavior test answer different questions, so neither should replace the other.
Ask the agent to explain a finding before simplifying
Consider a function with include_tax and dry_run flags. A smell finding is a reason to inspect its callers. It is not automatic permission to introduce a class hierarchy or split a public API into several incompatible functions.
Require the agent to name the ambiguous call, show a simpler alternative and preserve the behavior test. Sometimes a named argument or a small caller change is enough. Sometimes the flag genuinely represents a different operation. The useful outcome is a clearer contract with evidence that the change still works.
Likewise, inspect a reported dead-code candidate before deletion. Dynamic registration, plugin discovery and reflection can make a symbol appear unused to a static analyzer. A tool finding should lead to investigation of the actual execution path.
Measure the review work left over
Use one branch for the trial and save the before-and-after reports beside the diff. Record these outcomes separately:
| Outcome | What to record |
|---|---|
| New findings introduced | Which findings the task added |
| Findings repaired | The specific changes and passing behavior checks |
| Findings disputed | Why a report was not actionable |
| Scope expansion | Unrelated refactors triggered by the tool |
| Human review | Corrections still needed before acceptance |
This is a small workflow experiment, not a controlled benchmark. One successful task cannot establish a percentage improvement. Repeated, comparable tasks are needed before drawing conclusions about review time.
Keep feedback advisory until the team understands its false positives and has agreed which rules deserve to block delivery. A lower warning count is not a success if it comes from deleted behavior, suppressed checks or a larger abstraction that nobody needed.
Updated 21 September 2026: removed keyword stuffing and duplicated sections, distinguished project claims from independent evidence, and added baseline and false-positive review criteria.