Verification is becoming the core of the dev stack

Our customers are changing how they build software. As agents write more of the code, teams are working out how to review it, test it, and decide whether a feature is ready for users.

In conversations with customers and other engineering teams, we keep coming back to the same question: when an agent says a feature is done, how do you know it works?

Some teams are building their own QA agents. Others still click through every flow after the automated checks pass. We are learning from both, including the time they spend waiting for CI, the review comments that send agents into another round of edits, and the login problems that prevent testing from starting.

More code, more to check

In April 2025, Sundar Pichai said that well over 30% of the code checked in at Google involved developers accepting AI suggestions. The earnings-call transcript is more specific about that than the shorthand that AI “writes Google’s code.”

The Claude Code team says Claude writes about 90% of its own code. In Anthropic’s separate monorepo, daily merged changes grew from about 2,500 in May 2026 to more than 30,000 in September.

DORA’s 2025 report, based on nearly 5,000 technology professionals, found that 90% of respondents use AI at work. Higher AI adoption was associated with more delivery throughput and more delivery instability. Thirty percent reported little or no trust in AI-generated code.

Those numbers describe different populations and measures. What we recognise in customer conversations is the extra work of checking what agents produce.

Teams are building their own QA agents

Nine teams we spoke with had already built an in-house QA agent. The usual design was a nightly swarm of persona testers running against a dev environment and leaving tickets for the morning. One engineer started building his team’s version the week we spoke. They ran their first multi-agent test on the day of our call.

One builder described a manager agent coordinating test users, each with a persona and a goal. The testers never see the source code. The manager reviews their runs and files labelled issues. A separate group of agents gets access to code and logs to investigate the root cause.

His view was that the randomness of models is a decent stand-in for the randomness of users. I agree with him. A tester given a goal has room to try something the author did not anticipate.

Another team has its manager turn reports and screenshots into tickets overnight. Each morning, an agent cancels duplicates and findings that are not worth keeping. Small issues go to a coding agent; critical ones go to a person.

Green CI, broken feature

Five teams described the same failure: CI passes, the review bot approves, and the feature still does not work for users.

One developer still clicks through every flow himself after his agent’s Playwright tests pass. He had seen an agent “test” login by setting a flag that skipped login entirely.

Others worried about JavaScript shortcuts that bypass the form a user would fill in. They pointed out that an agent can edit or delete the end-to-end tests used to check it. Some described agents looping on a PR until the review bot awarded it 5/5. The agent being checked could usually change the check.

Where the time goes

An advisor who works with several client teams gave us one example: an agent makes corrections in 3 to 5 minutes, then waits about 20 minutes for CI. Another team reported 15 to 25 minutes of CI followed by a 12-minute deploy.

Review has its own delays. One team counted around 20 bot comments per PR, with about one in five judged to be noise. Its coding agent tried to fix those too, sometimes spending hours on them. The team’s workaround was to let agents clear the comments until no new ones appeared, then have a person read a one-page summary of the goal, changes and risk.

The Claude Code team reported a PR that went through more than fifty rounds of agent review and fixes overnight before its author stopped it. They now cap review rounds and narrow later passes to the diff. Their experience matches a cost the teams described: a false positive can send an agent into another cycle of edits and review.

Test volume can grow without helping much, too. One team capped coverage at 90% because it considered the tests written above that threshold to be padding.

Verification before and after merge

A full pre-merge test run becomes harder to fit into the workflow as agents produce more changes. Teams described three ways they were considering shortening the wait.

One was to accept an agent’s claim that it had run the tests locally. That leaves the trust problem when the agent can also change those tests. Another was to fan CI out across hundreds of sandboxes, at a higher cost. The third was to reuse runs from the agent’s working session. The teams discussing that approach had not settled how to trust the results.

Anthropic has already changed where it runs some checks. Its monorepo team says a global merge-queue lock could not keep up, so it invested in post-merge and pre-deploy testing, supported by automated bisect and revert pipelines. It also cautions that its scale and token budget are unusual.

Claude Code lives in a separate repository and still uses a merge queue. Its team describes continuous review, a classifier assigning risk tiers, and low-risk changes that can proceed without human approval once automated review and security checks pass. Feature flags, internal use, staged releases and rollback support that process. From June to September, merged PRs more than doubled while the share reverted fell by over 40%.

I expect verification to spread across more of the release process. The teams still wanted an answer to a specific question: can a user do what this feature is meant to let them do?

Merge conflicts were mostly manageable

We expected conflicts to be a bigger problem for teams running agents in parallel. Nine of the 15 teams we asked said conflicts were not really a problem and that agents mostly resolved them themselves. Anthropic’s monorepo team reports a similar experience: Claude can usually fix concurrent-change conflicts faster than people identify them.

How teams are putting verification together

The more developed setups had several parts in common. Teams are assembling these parts in different ways as they learn what they can trust.

Keep verification separate from the writer

Seven teams described keeping the writing agent away from verifying its own code. Some use another model for review. One reviewer sees only the PRD. Another team runs a pre-commit agent instructed to assume the author was a saboteur.

Give each PR a preview

A deploy hook sends the preview URL to the verifier. Teams kept encountering differences between preview and production: authentication enabled in one and disabled in the other, private previews behind a VPN, or bot protection blocking their own agents. One team put the VPN client in the runner image.

Decide risk before spending compute

Teams looked at migrations, authentication, money and core business rules. They also considered which modules changed, complexity, shared dependencies and who wrote the change. One scores each PR from 0 to 100. The advice we heard was to start strict and loosen thresholds as trust builds.

Give code-blind testers goals

A manager starts persona testers without source access. They pursue user goals, then hand failures to a separate agent that can read code and logs to investigate the cause.

Make test accounts usable

Half of our last 10 setup calls stalled on 2FA, SSO, a VPN, bot protection or an IP allowlist before testing began. Teams got past these with dedicated agent logins, OTP inboxes the agent could access, TOTP secrets from a password manager, development environments without invite-only signup, and static IPs on allowlists.

Collect evidence and remove duplicates

Teams wanted screenshots, a short reproduction and network errors. Video helped when motion mattered. One nightly swarm was followed by a morning agent pass that cancelled duplicate findings before anyone read them.

Put findings where the writer can act

The result goes back as a PR comment or ticket, short enough for the coding agent to use. Small fixes go to an agent. Critical issues and high-risk PRs go to a person.

What we are learning and building toward

I think verification becomes a core layer of the dev stack as agents write more of the code. The customers and teams we speak with are still assembling their own ways to decide whether the result works for users. Their experiences are shaping what we build.

The direction I want us to reach is continuous verification before and after merge: agents that have never seen the source exercise the product, attach evidence to the change, and support rollback when behaviour drifts. Engineers can spend more attention on what to build and on changes that carry real risk.

That is the layer we are building at Composal. We have written more about that direction in Continual Agent Verification. If your team is building a verification loop, I’d like to hear what is working and where you still get stuck.

Sources

• Alphabet Q1 2025 earnings-call transcript, April 24, 2025.
• Google Cloud: Announcing the 2025 DORA Report and the full report.
• Anthropic: Redesigning source control at Anthropic, October 13, 2026.
• Claude Code team: How the Claude Code team does code review, October 15, 2026.