Flagship service
Merge Assurance
Independent verification of AI-assisted code, running as a gate on the pull request, before untrusted change reaches your main branch. Machines verify at volume. Named humans adjudicate what matters.
-
The ProblemAssistants generate change faster than any test capacity built for human authorship.
-
The TrapThe same model writes the code and its tests, so the suite agrees with the mistake.
-
What breaks itA verifier independent of the author, at the gate, with a human on the high-risk tier.
The Argument
Circular Validation Is the Actual Risk.
Models write reasonable code most of the time. That is not the problem. The problem is who checks it.
The Tests Inherit the Bug
An assistant asked to write tests for its own implementation writes tests that confirm what it already believes. If the belief is wrong, both are wrong in the same direction, and the pipeline stays green.
Coverage Stops Predicting Risk
Because the volume of generated tests rises with the volume of generated code, the coverage percentage goes up while genuine assurance goes down. The number your board watches moves the wrong way relative to reality.
A Second Opinion Isn't Independence
Adding a second reader to the same pull request does not break the loop, because correct is still being judged from the implementation. Independence needs a source of truth from outside the code: a specification the change was never derived from, tests generated from that specification, and a person accountable for the verdict.
The Automated Check and the Human Disagree by 24 Points.
Share of AI-written PRs Judged Mergeable →
Source: METR, 296 AI-written PRs, blinded maintainer review. Points are illustrative of the reported “about half would merge” and the measured 24.2 pp grader gap.
-
Who is on it
An engineering lead and someone commercial, so technical answers and scope can happen in the same call.
-
What helps
The target, the timeline, and roughly how much of your change is AI-assisted.
-
What you get
A straight read on whether your target is reachable, including when it is not.
-
If none of the times work
Send the form instead and we will find one.
What it runs on
Our Own System, Not a General-purpose AI Model.
A stock model does not generate the independent tests pointed at your repository. They come from an AI software test platform our own engineers have been developing since 2023.
That is what makes the second opinion worth having. A different model on its own would only give you a different guess. Ours is driven by the patterns that actually break software, gathered since 2002, finding them in other people's code.
You never license it, install it, or staff it. It is how the service is delivered, and a named engineer reviews every release-affecting decision it makes before it counts.
How it runs
Four Steps, Inside Your Pull Request.
Wired to your GitHub or GitLab checks. No new tool for your engineers to open, no separate workflow to remember. We post the verdict as a status check in your pipeline. Whether a failing verdict blocks the merge is your branch protection rule, not our call.
- 01 Classify Every pull request is risk-tiered on blast radius, whether it touches authorization, money, or personal data, diff size, and, critically, where its tests came from.
- 02 Verify independently We generate tests from the ticket and its acceptance criteria, never from the code, using a different model than the ones that helped write the change. The tests cannot inherit the implementation's assumptions because they were never derived from it.
- 03 Check invariants Differential and property-based runs against prior behavior catch silent changes: the ones where nothing failed and something is now different.
- 04 Adjudicate High-risk tier goes to a named Modenix QA engineer who reviews findings and signs the verdict. Lower tiers clear on machine verification with continuous human spot-audit.
Where it sits in your pipeline
Wired to your GitHub or GitLab checks. Turnaround is agreed with you per tier before work starts, because a gate that slows engineers is a gate they route around.
Classification
Not Every Change Deserves the Same Scrutiny.
Tiering is what makes a pre-merge gate survivable. Most pull requests clear without a person; the ones that touch what matters get one.
-
Tier 1Auto-clear. Cosmetic and local changes with no sensitive surface. Logged, sampled for spot-audit, never queued.
-
Tier 2Machine verification. Independent tests are generated and run; a failure escalates to a person, a pass clears without one.
-
Tier 3Human adjudication. Anything touching authorization, money or personal data, and anything system-wide, regardless of diff size.
-
OverrideYou set the thresholds. If your risk appetite differs from our defaults, the matrix is yours to redraw.
Domain knowledge
What AI-assisted Code Gets Wrong, Specifically.
These are the patterns we tier and test for. They are not the same patterns human-authored code fails on, which is why a conventional suite misses them.
- Happy-Path Bias The sunny case is implemented well and the error branches are thin, absent, or swallow exceptions silently.
- Plausible but Wrong Logic that reads correctly to a reviewer and is subtly incorrect: off-by-one on boundaries, wrong operator precedence in a condition, inverted guard.
- Phantom APIs Calls to methods, parameters or library versions that do not exist, are deprecated, or behave differently than the model assumes.
- No Blast Radius The assistant sees local context, not the system. Contract and integration breaks appear where the change was locally correct.
- Silent Divergence The same intent regenerated in three places produces three implementations that drift apart over time, with no single source of truth.
- Inherited Insecurity Injection-prone patterns, weak authorization checks and unsafe secret handling, reproduced faithfully from the code the model learned on.
- Review Fatigue Approval quality falls as diff size rises, and AI-assisted diffs are large. Large PRs are rubber-stamped, and everyone knows it.
Specimen
What Comes Back on a Pull Request.
| Risk tier | HIGH · auth + payment surface |
| Diff | 412 added · 88 removed · 6 files |
| Test provenance | same assistant · circular |
| Tests generated (different model, spec-driven) | 34 |
| Passed | 31 |
| Failed | 3 |
| F-01 · Authorization skipped when tenant is null | HIGH |
| F-02 · Retry can double-charge on timeout | HIGH |
| F-03 · Deprecated SDK call, removed in v5 | MEDIUM |
| Adjudicated by | named QA engineer |
| Result | BLOCK · 2 high findings |
| Turnaround | 3h 40m |
The number to run the program on
Unverified Merge Ratio.
The share of change you merged that was never checked by anything independent of whoever wrote it. Most teams have never measured it. When we do, the first reading is usually the most useful number a CTO sees that quarter.
It is your number, not an industry statistic. The diagnostic estimates it in two minutes; the readiness assessment computes it from your repositories. That measured baseline is what the engagement is judged on, and the line your board can follow quarter to quarter.
-
Baseline
Measured across the last 90 days of merged change, by service and by team.
-
TargetSet with you, by risk tier. Not every change needs independent verification, and pretending otherwise wastes your money.
-
ReportedInto your dashboard, weekly, alongside throughput and rework.
Illustrative shape, not a measured distribution
100% of change merged in the last 90 daysThe middle segment is the one most teams have never counted.
Boundaries
What We Will Not Claim.
No one can find every bug in a codebase, and any vendor who says otherwise is selling you a sentence their lawyer has not read.
- We do not find all bugs. We verify defined behavior under defined conditions and state what was not covered.
- We do not certify code as correct, safe or compliant.
- We do not block your merge. We return a verdict; the gate policy and the decision stay yours.
- We do not assume liability for defects that reach production.
- Every verdict names its residual risk. A clean result means what we tested held, not that nothing is wrong.
Verification Gap Diagnostic
Seven questions, two minutes. A scored read on where your gap is widest, an estimate of your unverified merge ratio, and what to fix first, on screen before we ask who you are.
Three-week Readiness Assessment
We measure change volume against verified change, find where coverage claims and production reality diverge, and hand you a costed 60–90 day plan you can take to a board.
Thirty Minutes With a QA Lead
An engineering lead is in the room, not just a salesperson. Bring the number you have to hit and we will tell you whether it is reachable, including when it is not.