Cut code review time—and bugs—in half.
CodeRabbit gives fast-moving engineering teams AI-powered code reviews that catch bugs, suggest fixes, and learn your team’s coding preferences directly inside your workflow.
Trusted by 15,000+ teams and used across 6M repositories, CodeRabbit helps developers ship faster without sacrificing code quality.
2-click install. Available in PRs, CLI, and IDE.
For most of software engineering history, code was expensive to produce.
A feature might require days of design, implementation, debugging, review, and testing before a pull request appeared. The development process evolved around that constraint. Code review queues, CI pipelines, security scans, staging environments, and release processes assumed that software changes would arrive at approximately human speed.
AI changes that assumption.
Coding assistants can now generate functions, tests, migrations, infrastructure definitions, entire features, and increasingly complete pull requests within minutes. Autonomous coding agents can take an issue, explore a repository, modify multiple files, run tests, and submit a proposed change without a developer manually writing much of the resulting code.
The production side of the organization has not accelerated at the same rate.
DORA’s research into AI-assisted software development found that AI adoption is associated with greater software-delivery throughput, but also with increased instability. Its subsequent analysis describes an important tension: time saved during code creation is often being reallocated to auditing and verification.
A 2026 longitudinal study of professional software engineers describes the same transition from another direction. Developers reported spending less time writing code while their work increasingly shifted toward what the researchers call supervisory engineering: directing, evaluating, correcting, and validating machine-generated output.
That may become one of the defining changes in software engineering.
The scarce resource is increasingly not the ability to produce another thousand lines of code.
It is the ability to decide whether those thousand lines should be trusted.
The economics are straightforward.
AI dramatically increases the supply of proposed software changes.
But every change still consumes some combination of review capacity, test capacity, security analysis, architectural judgment, deployment validation, runtime monitoring, and incident-response capacity.
Those resources do not automatically scale just because code generation does.
Sonar’s 2026 developer survey illustrates the mismatch. The company reported that AI-assisted code represented about 42% of committed code among respondents, while 96% of developers did not fully trust AI-generated code. Yet only 48% said they always verified AI-generated code before committing it. Thirty-eight percent said reviewing AI-generated code required more effort than reviewing code written by another developer.
The implication is uncomfortable.
AI can increase engineering throughput while simultaneously increasing the amount of software requiring verification.
That produces what might be called verification debt.
Traditional technical debt accumulates when developers knowingly accept architectural or maintainability compromises.
Verification debt accumulates when an organization produces software changes faster than it can confidently determine their consequences.
The code may compile.
The tests may pass.
The security scanner may remain green.
The pull request may look reasonable.
But nobody actually knows whether the combination of those signals means the software is safe to run at production scale.
Modern engineering organizations already perform an enormous amount of verification.
Static-analysis systems inspect source code.
Software-composition-analysis tools examine dependencies.
Security scanners search for known vulnerability patterns.
Unit tests validate local behavior.
Integration tests verify interactions.
Contract tests protect API assumptions.
CI systems enforce build rules.
Code reviewers examine implementation decisions.
Feature flags control exposure.
Observability systems collect metrics, logs, traces, profiles, and user-experience signals.
SRE systems monitor service-level objectives.
Incident platforms track operational failures.
Each system is useful.
The problem is that they frequently operate on different representations of reality.
A static analyzer understands files and functions.
A CI platform understands builds.
Git understands commits.
A service catalog understands applications and ownership.
An APM platform understands runtime services.
A security platform understands vulnerabilities.
An incident system understands alerts and escalations.
A ticketing system understands work.
Production reliability, however, exists across all of them simultaneously.
That creates an increasingly important architectural mismatch.
We have excellent instruments for measuring individual stages of the software lifecycle but relatively weak mechanisms for understanding the lifecycle as one continuous reliability system.
Consider a simple pull request that changes a database query.
Viewed as code, the change may appear harmless.
Static analysis passes.
The query is syntactically valid.
Unit tests pass.
The developer runs it locally and sees the correct result.
But suppose that query executes against a table containing hundreds of millions of rows in production.
Suppose it sits inside the checkout path.
Suppose the application has a small connection pool.
Suppose the new query removes an index-friendly predicate.
And suppose traffic increases by 30% during a promotional event.
Nothing inside the isolated diff necessarily tells you the true risk.
The risk exists in the relationship between the change and the system surrounding it.
This is why production reliability is fundamentally contextual.
A change cannot be evaluated solely by asking:
Is this code correct?
Increasingly, engineering organizations need to ask:
Is this change appropriate for this architecture, this workload, this service, this dependency graph, this production environment, and this organization’s risk tolerance?
That is a much richer verification problem.
The next logical step is to connect these previously separate signals.
Imagine that every production service has a continuously evolving reliability graph.
A proposed change enters that graph.
The system knows which repository it came from.
It knows which service owns the code.
It knows which downstream systems that service calls.
It understands recent incident history.
It understands current SLOs.
It sees whether the modified files are historical hotspots.
It knows which tests cover the affected path.
It knows whether the service is payment-critical or merely internal tooling.
It understands previous production failures associated with similar changes.
It can then evaluate the change in context rather than examining the diff in isolation.
This is where the idea behind systems such as Tomosu becomes interesting.
Tomosu describes itself as a production-reliability governance layer spanning development, pre-merge evaluation, and production. Its proposed Production Reliability Index combines signals including fragility, development-versus-production drift, governance compliance, runtime behavior, code volatility, deployment velocity, and escalation patterns. It also proposes feeding production failures back into future development guardrails.
The important part is not necessarily the score.
It is the loop.
Most software verification today flows primarily in one direction.
Development produces code.
Code enters CI.
CI runs checks.
Software is deployed.
Observability watches it.
An incident eventually occurs.
Engineers diagnose it.
Someone fixes it.
Then the organization moves on.
The weakness is what happens after the incident.
Imagine that a production failure was caused by an external API request without an appropriate timeout.
An engineer discovers the problem at 2:00 a.m., adds the timeout, deploys the fix, and closes the incident.
The organization has technically learned something.
But the development system may not have.
Three months later, another engineer—or another AI coding agent—introduces the same failure pattern somewhere else.
A genuine reliability-control plane would treat the incident differently.
The sequence would become:
Production failure → root cause → responsible code pattern → reliability rule → future pre-merge check.
Production becomes training data for development policy.
That is a profound change.
Instead of observability merely explaining yesterday’s outage, runtime behavior continuously improves tomorrow’s verification system.
The development lifecycle becomes a feedback loop.
Observability platforms are already moving aggressively toward this territory.
Datadog, for example, now connects CI visibility, static-analysis results, software catalogs, service relationships, deployments, runtime telemetry, database changes, feature flags, incidents, and remediation workflows. Its Change Tracking system can correlate deployments and other system modifications with changes in service behavior.
This convergence is important because it shows that the underlying market need is real.
But observing a change and governing a change remain different problems.
Observability traditionally asks:
What happened?
A reliability-governance system increasingly needs to ask:
Given everything we know about production, should this change be allowed to happen?
That moves the decision boundary upstream.
Instead of waiting for production telemetry to identify a bad deployment, historical production telemetry becomes evidence used when evaluating the pull request itself.
The same limitation exists on the development side.
Static analyzers are extremely valuable precisely because many of their checks are deterministic.
An LLM might think a SQL query is safe.
A purpose-built security analyzer can formally identify a known injection flow.
This distinction becomes more important as AI-generated code increases.
A 2026 academic evaluation of GitHub Copilot’s code-review capability found that it frequently missed serious vulnerability classes including SQL injection, cross-site scripting, and insecure deserialization in the evaluated samples, while often focusing on lower-severity issues. The researchers concluded that dedicated security tools and human security review remain necessary.
The lesson should not be that AI reviewers are useless.
It should be that AI should orchestrate verification rather than replace verification.
Deterministic analyzers, tests, formal methods, runtime telemetry, and policy engines should remain sources of evidence.
AI is potentially most valuable one level above them—connecting the evidence, understanding context, prioritizing findings, explaining trade-offs, and deciding which specialist verifier should run next.
The strongest reliability architecture is therefore unlikely to be one gigantic model inspecting everything.
It is more likely to be a system of specialized deterministic and probabilistic verifiers coordinated through a shared application context.
Connecting all these signals sounds straightforward until production enters the picture.
Suppose error rates rise immediately after a deployment.
Did the deployment cause the incident?
Maybe.
But perhaps traffic also increased.
Perhaps a dependency degraded.
Perhaps a feature flag changed.
Perhaps a database schema migration ran simultaneously.
Perhaps the cloud provider experienced a networking problem.
Correlation is relatively easy.
Reliable causal attribution is much harder.
A serious reliability platform therefore cannot simply observe that deployment X occurred before incident Y and conclude that X caused Y.
It needs evidence.
That might include stack traces referencing modified functions, distributed traces crossing affected services, error fingerprints appearing only after a new version, canary comparisons, rollback behavior, feature-flag cohorts, database-query changes, dependency telemetry, and historical incident patterns.
This causal layer may ultimately be far more defensible than any dashboard.
If a platform can reliably connect a production symptom to the change that created it, it creates extraordinarily valuable structured data.
And that data can improve every future merge decision.
Tomosu’s Production Reliability Index represents another interesting idea: compressing numerous reliability signals into a single score.
Engineering executives understandably want this.
Nobody wants to explain 47 dashboards during a quarterly business review.
A trend showing application reliability moving from 62 to 78 is much easier to communicate.
But composite scores create their own risks.
Reliability is multidimensional.
A service could have excellent code quality but poor operational resilience.
Another could have excellent availability while accumulating security vulnerabilities.
Another could have perfect SLO compliance because almost nobody uses it.
Compressing all of this into one number creates the danger that teams optimize the metric rather than the underlying system.
The score therefore needs to remain decomposable.
Engineers should always be able to answer:
Why is the number 62?
More importantly:
What evidence would move it to 63?
Without that transparency, a reliability index becomes executive theater.
With it, the score can become a useful abstraction over an otherwise overwhelming signal landscape.
Another question the industry will need to resolve is how strongly AI authorship itself should affect risk scoring.
Tomosu describes AI origin as one factor that can modify change risk.
There is some logic to this.
AI-generated changes may require different verification assumptions, especially when no human deeply understands the generated implementation.
But provenance should not become a substitute for evidence.
A well-tested AI-generated five-line change may be safer than a poorly tested 5,000-line human rewrite.
The ultimate object being governed is not AI code.
It is production change.
AI matters because it changes the velocity, authorship, review dynamics, and uncertainty surrounding those changes.
Risk systems should measure those consequences rather than simply penalizing machine authorship.
Interestingly, coding agents are becoming operationally autonomous faster than they are becoming organizationally authoritative.
A 2026 ACM study reconstructed 29,585 pull-request lifecycles involving OpenAI tools, Copilot, Devin, Cursor, and Claude Code. In more autonomous “collaborator” workflows, at least 96% of the studied PRs were agent-initiated, while terminal merge authority remained overwhelmingly human.
That separation matters.
AI may increasingly perform the work.
Humans still own the consequences.
The reliability-control plane therefore becomes an interface between machine-scale software production and human-scale accountability.
Its job is not necessarily to replace the reviewer.
Its job is to give that reviewer enough compressed, contextual evidence to make a meaningful decision despite the rapidly increasing volume of machine-generated work.
Tomosu is one expression of a much broader platform shift.
Sonar is building AI-specific quality gates.
GitHub is introducing AI-powered security detections and automatically validating code created by third-party coding agents.
Datadog is connecting software delivery, security, service catalogs, deployments, and runtime behavior.
Dynatrace’s 2026 SRE research found that fragmented tools and data remain significant barriers, with nearly half of surveyed SRE respondents saying too many data sources and metrics hinder effective SLO management. Dynatrace itself describes observability as increasingly becoming a control plane for AI-driven operations.
OpenTelemetry is meanwhile standardizing semantic conventions not only for application telemetry but also for CI/CD signals, making lifecycle-wide correlation increasingly practical.
All of these developments point toward the same architectural destination.
The boundaries between development tooling, DevSecOps, observability, platform engineering, incident management, and AI governance are beginning to blur.
The strategic question is therefore not whether engineering teams need another verification tool.
They almost certainly do not.
The more interesting question is which system becomes the place where all verification evidence is assembled into a coherent understanding of application risk.
That system could emerge from observability.
It could emerge from code-quality platforms.
It could emerge from Git hosting.
It could emerge from internal developer platforms.
Or a new category of reliability-governance companies such as Tomosu could establish itself between those layers.
Winning will require considerably more than adding an LLM to code review.
The winning system will need a persistent model connecting software components, repositories, ownership, dependencies, deployment history, policies, telemetry, incidents, and business criticality.
It will need deterministic verification underneath probabilistic reasoning.
It will need to distinguish correlation from causality.
It will need to explain every automated decision.
It will need human override and auditability.
And, most importantly, it will need to demonstrate that the predictions it makes before deployment correspond to what actually happens afterward.
That final requirement is what separates an AI reviewer from a reliability system.
Software development has spent decades building increasingly sophisticated mechanisms for producing code.
AI may finally force the industry to invest equally heavily in deciding whether that code deserves to exist in production.
That is why the exploding verification stack should not necessarily result in another generation of point solutions.
The deeper opportunity is consolidation at the reasoning layer.
Static analysis should continue finding static problems.
Security scanners should continue finding vulnerabilities.
Tests should continue validating expected behavior.
Observability should continue measuring reality.
But something above those systems needs to understand how their evidence fits together.
And, eventually, that system needs to remember what production taught it.
The most important transition may therefore be from a software lifecycle filled with verification tools to a software reliability control plane—one that observes every change, understands its context, follows it into production, learns from the outcome, and makes the next change safer.
AI created the verification problem by making software dramatically easier to produce.
Ironically, AI may also become the connective tissue that finally allows the industry to solve it.