Supercov Brings MC/DC Coverage to Coding Agents

Supercov is an independent Show HN project: a coverage wrapper for JavaScript, TypeScript, and Rust test suites that coding agents can run while they write tests. Code is cheaper to generate, but review and verification are not cheaper just because a model wrote the diff. MC/DC coverage is a test coverage criterion that checks whether each condition inside a decision can independently change the decision’s outcome. The phrase AI coding solutions roi for large teams sounds like procurement language, but Supercov points at the engineering version: did the agent leave stronger verification behind?

Run coverage where the agent already runs tests

Supercov’s hook is small. As of September 2026, the project says you can wrap an existing test command like this:

npx supercov -- npm test

That shape matters. It does not ask a developer to move into a new test runner before learning whether the idea helps. A Cursor user can ask an agent to run the normal project tests through Supercov, inspect the uncovered decisions, and add one focused test.

Don't treat coverage output as a task list that must go to 100%. The author’s own framing is more modest: let the agent keep writing tests where it makes sense. That last clause does real work.

A good first repo is a small library with branchy logic: permissions, pricing, feature flags, parsing, validation, or state transitions. A bad first repo is a UI-heavy app where most risk lives in browser behavior, async timing, or visual regressions.

Why MC/DC made developers stop scrolling

MC/DC is stricter than line coverage and more specific than branch coverage. If your code says canDelete = isOwner && !isLocked, MC/DC asks whether the tests show isOwner can change the result and isLocked can change the result, independently.

That is exactly the kind of thing an agent can miss while still producing a comforting green test run. AI code generation is good at plausible paths. It is less naturally good at hostile, boring edge cases unless the workflow keeps pulling it back to them.

The objection is fair too. MC/DC does not prove the expected behavior is right. A test can cover every condition and still assert the wrong product rule.

So the interesting part is not “coverage solves review.” It is that coverage can give a coding agent a better next move than “write more tests.” The next move becomes “write the missing decision test, then stop when the value is gone.”

Let the overnight loop create evidence, not mystery

The overnight pitch is charming because it matches how agents already behave. Give the agent a narrow command, let it iterate, and wake up to a diff instead of a chat transcript.

Cursor is a natural place to try that because the agent’s work lands in the same editor where you review code. You can see the test file, the production diff, the command output, and the commit-sized change together. That is much better than replaying a long agent conversation to guess what happened.

Don't let the agent change production code to satisfy a coverage metric. If the task is test coverage, the boundary should say tests only unless the agent asks for approval. This is the same lesson showing up in adjacent agent infrastructure experiments, like Manzanas leasing iOS simulators to agents: autonomy gets useful when the artifact is easy to verify.

For projects using MCP to connect agents to GitHub, Jira, or internal docs, keep those tools read-only during a coverage experiment. The agent needs code, tests, and command output. It probably does not need permission to close tickets at 2 a.m.

Keep the Cursor boundary small

Do not start with a giant Skill, a custom subagent, and a new process document. Start with one local Cursor rule and one repo boundary in AGENTS.md, then see whether the diffs are worth reviewing.

Here is a small .cursor/rules/supercov.mdc stub that keeps the agent honest:

---
description: Use Supercov for focused test coverage exploration
globs: ['**/*.{ts,tsx,js,jsx,rs}']
alwaysApply: false
---

When asked to improve test coverage with Supercov:

- Run the existing test command through Supercov before editing.
- Prefer adding or improving tests over changing production code.
- Do not modify source files unless the user explicitly approves it.
- Keep each pass to one behavioral area, such as permissions or pricing.
- Report the command run, the uncovered decision addressed, and the files changed.

Then put the durable repo rule in AGENTS.md:

## Test coverage agent boundary

Coverage tasks may edit test files by default. Production code changes require approval in chat and must explain the failing behavior they fix.

That is enough structure for an AI coding workshop exercise, and it is small enough to delete if Supercov is not useful in your repo. For broader patterns around reviewable agentic coding, keep this near AI coding governance, not buried in a one-off prompt.

Try Supercov when branch risk is real

For AI coding solutions roi for large teams, Supercov is most interesting when the cost center is review time, not typing time. If an agent can turn vague “please add tests” work into reviewable MC/DC deltas, the return is fewer missed edge cases and less human spelunking.

Use this fit table before you hand it an overnight job.

The practical starter checklist is short: pick one branchy module, run Supercov around the existing test command, ask the agent for one missing decision test, reject production edits by default, and review the diff like any other test PR.

Further reading

• MC/DC coverage so coding agents could work overnight
• Cursor Agent docs
• genai.owasp

Where to go next

Start from AI coding governance.