On June 2, 2026, Harness acquired Codecov from Sentry. The strategic logic, stated plainly by Harness CEO Jyoti Bansal in the announcement: turn signals like coverage into "enforceable decisions" that guide every release. Read that framing again, because it contains the entire problem in the same sentence as the company's answer to it. A signal and a decision are not the same object. You do not convert one into the other by acquiring the company that produces the signal.
The gap between a signal and a decision is exactly where release incidents live, and no acquisition closes it.
The move itself is validation that the contested ground has shifted. When a delivery vendor spends acquisition money to put a quality measurement next to the deploy button, it confirms that the question is no longer how fast you ship. The question is whether you should have. That is a governance question, and the market is now pricing it as one. The error is not in caring about the question. The error is in answering it with a number that was never built to answer it.
The one-line version of what Tomosu does: Tomosu scores every pull request for reliability, operational risk, security exposure, and policy compliance, against the production system the change is about to enter.
A signal is a measurement of the past. A gate is a decision about a specific change. The two are different objects, and the next decade of software delivery hinges on the industry getting clear about which is which.
Coverage has been a hint for thirty years
Coverage measures which lines of code executed while the tests ran. It has never measured whether those lines are correct, whether the assertions are meaningful, or whether the change is safe to put in front of customers. Engineering teams have known this for decades. They hit eighty percent and shipped the bug anyway. They watched the dashboard go green over code that fell over in production. The metric was always a proxy, useful as a hint and dangerous as a promise.
None of that is new. What is new is the proposal to take the proxy and make it the gate. A hint you can ignore. A gate decides what reaches users. Promoting a measurement from advisory to authoritative does not make the measurement smarter. It just raises the stakes on its blind spots.
Agents collapse the proxy precisely when you need it
The reason this acquisition arrives now, and not five years ago, is that the same systems writing the code can write the tests that satisfy the coverage threshold. A coverage gate is the easiest gate in the world for a code-writing agent to clear. Generate tests that execute every branch and assert almost nothing. The coverage number climbs. Reliability does not move. The proxy detaches from the thing it was supposed to proxy, and it detaches fastest under exactly the volume of agent-generated change that made teams want a gate in the first place.
This is the structural trap. The metric you chose as your control is the metric your code generator is best at gaming. After-the-fact review cannot scale to meet agent throughput, so the decision has to move to the gate. And a gate that checks a gameable number is not a control. It is a formality with a threshold.
The verified data is no longer in dispute. LinearB's 2026 Software Engineering Benchmarks Report, drawn from 8.1 million pull requests across 4,800 engineering teams in 42 countries, found AI-generated PRs accepted at 32.7% versus 84.4% for manual code. The merge gate is already triaging by force of human exhaustion. Senior engineers spend 38 minutes per AI PR and accept only 23.7%. The reviewers are rejecting AI code at scale because they cannot trust the surface evidence the diff presents. A coverage gate that an AI-generated test can game does not solve the trust problem. It hides the trust problem behind a higher number.
What a gate actually has to do
A gate has to answer one question: should this change proceed. That answer cannot be inherited from any single signal, because no single signal carries the decision. The gate has to compute a verdict on the specific change in front of it, live, weighing many signals at once, where coverage is one input among several and never the conclusion by itself.
Tomosu sits above your existing GitHub or GitLab as the verifier the architecture has been missing. Every pull request, especially AI-generated ones, gets scored before it lands on main. The score is the Production Reliability Index, a single trendable number composed of signals you can name to a board.
The blast radius of the diff. What services, what data paths, what downstream systems this change can affect. The cache invalidation that looked harmless in isolation gets surfaced because its blast radius touches the legacy auth service the agent did not know about.
What it costs if the service this change touches goes down. A change to the payments path scores differently from a change to the marketing site, even if the diffs look identical.
Whether the change touches regulated paths. PCI, HIPAA, SOC 2, the audit-bearing systems. The change that the CFO will be asked about by a regulator gets flagged before it ships, not after.
Whether the change conforms to the organization's declared engineering and security policies. CODEOWNERS satisfied. Required reviewers present. Dependency allowlists honored. The SOC 2 CC8.1 answer is embedded in the receipt.
Coverage is one of many inputs that may inform any of these signals. It is not, and was never, the verdict. AI-origin is a cross-cutting modifier on all four dimensions, not a fifth dimension on its own. An AI-generated change with high blast radius scores worse than the same change written by a senior engineer who can defend it.
Over time, the moat compounds through a cross-fleet governance graph that learns from millions of code changes, incidents, and remediation actions across organizations. Each customer's deployment makes every customer's verification sharper. The patterns of which kinds of diffs cause which kinds of incidents, and which remediations actually held, accumulate as shared signal across the fleet, without crossing any tenant boundary on the underlying code or data.
What buyers should ask
There is now one question that separates a release control from a repackaged metric. Ask the vendor: does your gate compute a decision, or does it threshold a measurement? If the answer is a measurement with a configurable cutoff, you have bought a more expensive number, not a control.
The regulatory version of this question is already forming. A general counsel reviewing why a change was safe to ship will not accept "we reached eighty percent coverage" as the record of the decision. That is a measurement, not a rationale. The defensible answer describes what the system evaluated about the specific change and why it concluded the change could proceed. A coverage figure cannot produce that record, no matter who owns the company that generates it.
What changes for the people in the chain
The on-call engineer is no longer responding to incidents on changes they did not review and cannot defend. The verifier filtered out the changes that should not have shipped without a human looking at them. When the pager does ring, the call is for a change the on-call engineer can actually trace, against a score the team understood, with the policy that permitted it named.
The senior engineer reviewing forty pull requests a week is not reading all forty. The low-risk ones merge with the receipt attached. The engineer's attention goes to the surfaced ones, with the score and context visible. The forty-clicks-a-week problem is not solved by reading faster. It is solved by being asked to read only the changes that need a human, and being given the context to make a real call when asked.
The CFO is no longer signing off on a quarterly summary with green metrics that the data has now shown do not predict what happens after the code ships. The CFO is being shown, in a board-trendable score, what the organization's production risk posture actually is. The signoff means something operational again.
The General Counsel and the Chief Data Officer have the same upgrade. Every high-risk merge has a named reviewer who attested to the score and the basis. The policy is named, by every receipt, as the policy that permitted the merge. When a regulator asks about the change that produced the loss, the answer is a document that was produced when the decision was made, by the system that made the decision possible.
A 90-day pilot
We are partnering with three to five engineering organizations in regulated industries this quarter. The pilot is measurable, not vibes.
The line
Every delivery vendor will reach the same realization Harness reached on June 2: the merge decision is the contested ground. Every one of them will reach for the same shortcut. Acquire a signal, wire it to the deploy button, call it governance. The signal will be real and the wiring will be clean and the thing in the middle — the decision — will still be missing. Because the decision was never the signal's job.
A signal you can buy. A gate you have to compute.
Book a 30-minute conversation: calendly.com/manil-tomosu/30min
Questions: contact@tomosu.ai · Book a call →
Harness Press Release: harness.io/press-and-news/harness-acquires-codecov (June 2, 2026). LinearB 2026 Software Engineering Benchmarks Report: 8.1 million pull requests, 4,800 engineering teams, 42 countries. LinearB is a 2026 Gartner Magic Quadrant Leader for Developer Productivity Insight Platforms. The architectural argument for why signals and gates are structurally distinct categories of release control is developed at fixgovernance.ai/essays/the-authorization-gap.