Sensez Catches Agent Code Smells

sensez is an open-source Rust project by GitHub user popov95s that gives coding agents fast static feedback while they edit code. It deals with a stubborn ai coding problem: agents can follow instructions for a while, then quietly drift into hard-to-maintain shapes like dict[str, Any], boolean-flag APIs, nested logic, dead code, cycles, and duplication. The useful takeaway is simple: put deterministic smell feedback inside the agent loop, not only after the pull request exists. That makes sensez relevant to the quieter question behind ai coding solutions roi for large teams: whether ai code generation can reduce review load without hiding more cleanup work downstream.

Why this Show HN hit a nerve

The project touched a real sore spot because the failure mode is familiar. A developer writes clear repository rules in AGENTS.md, asks an agent for a small change, and still gets a function that grew a second boolean flag because the model found the shortest path through the current prompt.

As of September 2026, the sensez repository showed 16 GitHub stars, an MIT license, mostly Rust code, and a last push on 2026-09-03. Tiny projects can still be interesting when they name the problem cleanly.

The README says sensez runs static checks for duplication, dead code, cycles, architecture violations, and design smells. It also reports controlled evaluations where agents using sensez produced 86% fewer code smells, 90% less duplicated code, and 67% fewer lines. Treat those as project-reported results, not independent proof.

The important part is where sensez catches the smell: before the agent hands you a diff. CI can catch duplication too, but a red build after review often turns into a ticket, and tickets are where cleanup goes to nap.

The trap is believing instructions alone are enough. Instructions are memory. Static feedback is a constraint.

The trick is feedback before review

sensez uses the Model Context Protocol, often called MCP, to put analysis results where a coding agent can act on them. MCP is a standard way for an AI application to connect to external tools and data sources through structured servers.

That matters because coding agents work best when the correction arrives while the plan is still fluid. A linter failure after a pull request says stop. An in-loop smell report says change this shape now.

The project README says sensez init writes a commented starter sensez.toml and registers sensez as an MCP server with a coding agent. That is the right kind of surface area: a small config file, structured findings, and no need to wait for the full CI pipeline.

A realistic example is a service module where an agent adds this kind of helper:

def build_invoice_payload(order, include_tax=False, dry_run=False):
    ...

A human reviewer might pause at the flag pile-up. An agent may not. A tool like sensez can turn that into immediate feedback: split the behavior, model the state, or make the branch explicit.

The trap is treating smell feedback like style nitpicking. Duplication, cycles, and boolean-flag APIs are not taste when they make the next agent change harder to verify.

Where AGENTS.md stops carrying the weight

AGENTS.md is still useful. It is the right place for durable repo instructions: test commands, architecture boundaries, naming rules, and review expectations. Codex, OpenAI's coding agent, benefits from that kind of local context just like a human contributor does.

A small repo rule might look like this:

# AGENTS.md

When editing payment code:
- do not add boolean flags to public functions
- prefer typed request and response models over dict[str, Any]
- keep business logic outside nested helper functions
- run pytest tests/payments before handing off

That is good context. It is not enforcement.

The hard part is session decay. A coding agent can start strong, then lose the thread after several edits, tool calls, and partial fixes. The author of sensez called out exactly that pattern: instructions and skills become less reliable over a long session.

This is why the project fits the same verification-loop family as Supercov Brings MC/DC Coverage to Coding Agents. Both stories point at the same lesson: agents need feedback they can use before humans become the error boundary.

The trap is making AGENTS.md longer every time the agent disappoints you. Past a point, you are feeding the model a policy manual when what it needs is a short failing check.

Try it on one messy path first

Do not start with a grand program. Pick one part of the repo where ai pair programming already produces annoying review comments: a controller layer with duplicated branches, a data-access package with circular imports, or a test helper file that keeps absorbing business logic.

For Codex users, the safe experiment is boring on purpose:

git checkout -b sensez-smell-check
sensez init
# ask the agent for one small change in a known-problem module
# run your normal verification loop, for example:
pytest tests/payments
npm test -- --runInBand

Then compare the diff with and without in-loop smell feedback. Look for whether the agent repaired the design while editing, not just whether the final tests passed.

This is the practical place where ai coding solutions roi for large teams becomes less hand-wavy. The useful signal is not that an agent wrote more code. It is that fewer avoidable design comments reached human review.

For broader patterns, Codex Workshop tracks this under AI coding governance, but sensez is the concrete story: a small open-source project trying to move smell detection earlier.

The trap is testing it only on greenfield toy code. Code smells matter most in old modules where the agent is tempted to copy the existing mess.

Fit and not-fit table

Common questions

• Does sensez replace code review or CI?

  No. sensez is best read as earlier feedback, not final approval. CI still proves the project builds and tests pass, while review still handles intent, product fit, security, and maintainability judgment that static analysis cannot fully model.

• How does sensez affect ai coding solutions roi for large teams?

  It gives you a cleaner thing to measure: fewer preventable smell comments reaching review. The project-reported numbers are promising, but the safer metric is local: compare two similar agent tasks and count duplicated code, review comments, and rework time.

• Is this only for Claude Code or Codex?

  No, the interesting idea is tool-agnostic: deterministic feedback inside the agent loop. Claude Code, Anthropic's coding agent, Codex, Anysphere's AI code editor, and Codex-style CLI workflows all benefit from the same pattern when they can call tools through MCP or an equivalent boundary.

• What should I put in AGENTS.md if I also use sensez?

  Keep AGENTS.md short and durable. Put the repo rule there, such as no boolean flags in payment APIs, then let sensez or your normal checks provide the failure signal when the rule is broken. Long instruction files are easy for agents to ignore under pressure.

• Can static smell checks make ai software development too rigid?

  Yes, if every warning becomes a blocker. Start with smells that repeatedly cost reviewer time: duplication, cycles, dead code, and architecture boundary violations. Leave room for human judgment when a local exception is cheaper than a clever abstraction.

Best ways to use this research

• Best for: Engineers already using coding agents on real repositories and seeing repeated maintainability comments in review.
• Best first artifact: A tiny AGENTS.md rule paired with one deterministic check the agent can run before handoff.
• Best comparison angle: Measure review rework, duplicated code, and smell count, not lines generated.
• Best boundary: Keep sensez as advisory at first, then decide later which findings deserve to fail CI.

Further reading

• sensez — source
• Model Context Protocol — specification
• OpenAI Codex — source
• Codex — Agent
• OWASP — Top 10 for Large Language Model Applications

Next step

Try sensez on one annoying module and save the before-and-after diff. If the agent fixes smells before review, you have a useful new feedback loop; if it does not, you learned that your bottleneck is somewhere else.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.