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. It deals with a very current AI coding problem: 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: Devin Workshop is part of Harness Institute.

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.

The trap is treating 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, Anysphere’s AI code editor, 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.

The trap is letting 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 the related training topic, 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.

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.

Common questions

What should teams know about ai coding?

Start by writing down one visible team rule for Cursor, not a loose preference. That is the practical core of ai software development. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

Which Cursor artifact should teams standardize first?

Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

How do teams know the convention is working?

The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “Supercov Brings MC/DC Coverage to Coding Agents.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; keep the path that leaves the shortest auditable trail.

Further reading

• MC/DC coverage so coding agents could work overnight — source
• Cursor — Agent
• OWASP — Top 10 for Large Language Model Applications
• developers.google.com: fundamentals creating helpful content

Where to go next

Start from the related training topic and make the first exercise prove scope, verification, and ownership in the PR body.