AI adoption needs enough capacity to verify the work

An organization can produce more proposed code without releasing more useful changes. Every proposal still needs a route through verification and an owner when something fails. An AI rollout which changes the volume or character of that work should therefore include a decision about verification capacity. Adoption share alone cannot answer whether the organization is delivering better outcomes.

The April 22, 2026 On Rails announcement presents Intercom engineer Brian Scanlan’s account of AI adoption. The episode’s notes and chapters cover CI costs, review and open-ended debugging. These are two presentations of the same interview, not independent corroboration. The discussion here uses the written material; it does not claim that the audio was heard or that the organization’s results were independently measured.

Adoption answers a narrower question

A reported share of generated code describes how code is produced under the speaker’s definition. It does not count useful deployments or show how much work reaches users. Definitions also matter: a share of daily code and a share of completed changes have different denominators. Treating either as a direct measure of productivity skips the work needed to connect an activity to an outcome.

A technical leader should ask what decision the number is supposed to support. If the decision concerns tool uptake, adoption can be relevant. If it concerns delivery capacity, the evidence needs to follow work through acceptance and release. If it concerns business value, even a successful release needs an account of the customer task it improves. One number need not carry every part of that argument.

Comparisons need a stable scope too. A period containing many small maintenance changes differs from one dominated by difficult migrations. Counting both as an undifferentiated increase can hide a change in the work itself. Record enough context to explain the comparison before attributing a difference to AI. That is a proposed measurement discipline, rather than a claim that the interview supplies such a controlled comparison.

Follow the verification demand

More proposals can create more test executions and more requests for review. Whether that happens depends on how the team uses the tools and organizes changes. The useful planning question is where the additional demand would go if generation becomes less constraining. Look at the queue which determines when a change can be accepted, rather than assuming the next bottleneck in advance.

For CI, distinguish time spent waiting from time spent executing checks. A team can have adequate compute and still lose time investigating unreliable failures. It can also have reliable checks with insufficient capacity at peak demand. Those situations call for different responses. Buying capacity without understanding the delay can leave the real source of verification work untouched.

For review, distinguish repetitive checks from judgment about behavior and responsibility. Automating a mechanical check can free attention, while a large generated change may still be difficult to understand. A reviewer needs a clear description of what changed and why the evidence is sufficient. The fact that a tool generated the patch does not supply that explanation or determine how much human review it deserves.

Automation can absorb part of the load

The strongest counterargument is that AI can help with verification as well as generation. Better test selection, automated checks and review assistance may absorb some of the additional demand. A planning model which assumes every new line requires the same amount of manual attention would miss that possibility. Verification capacity can change, and it deserves its own investment and evaluation.

The boundary is what each check can establish. A test subset can be appropriate for a defined class of changes without covering every possible interaction. Automated review can flag familiar problems without accepting responsibility for a product decision. Describe the evidence and the remaining judgment separately. Otherwise a shorter queue can be mistaken for stronger assurance when the acceptance boundary has merely moved.

Changes to automation should consequently be assessed against the work they are intended to handle. Record what is eligible, what requires escalation and what evidence would show that the rule needs adjustment. A team can remove low-value manual steps while preserving a clear owner for exceptions. That is a more useful objective than retaining every old gate or removing every human gate by principle.

Include the work after release

Verification continues when a change meets real conditions. Incident diagnosis needs an account of behavior, recent changes and ownership. If proposed code becomes easier to produce while the system becomes harder to explain, the cost may appear after deployment. This is a risk to examine, not a universal causal claim about AI-generated software or a measured finding from this article.

Keep incident work visible beside delivery measures. A useful comparison can consider accepted changes and the effort needed to support them over an appropriate observation period. Choose that period for the product rather than inventing a universal threshold. Independent evidence about useful delivery and operational work is necessary before adopting a broad claim of increased throughput from a single engineer’s account.

In a custom software project, agree who accepts a change and who investigates it after release. Then assess the coding tool alongside the verification system that makes its output usable. The practical rollout decision concerns the whole path to supported behavior. A high adoption share can be one observation on that path, while leaving the outcome question open.