Async Coding Agents Need a Verifier That Isn't a Person
When agents run from events and schedules, nobody is watching to check their work. In a cloud-native system, that check has to happen in a real runtime before the PR opens.
Cognition crossed a line this year: more Devin sessions now start asynchronously than interactively. In Verifying Agentic Development at Scale, Ido Pesok describes sessions kicked off by events, automations, schedules and other Devins, with no developer typing the first prompt.
The milestone is less interesting than its side effect. A developer steering a session was also quietly checking it. Remove the developer, and that check disappears along with them.
Ido draws the same conclusion: an agent working on its own is worth something only if you can trust the result it returns. Writing code is no longer the slow part. Checking it is, and in cloud-native software, how well an agent can check its work comes down to what runtime it has access to. That runtime is the center of verifying AI-generated code on Kubernetes.
Interactive sessions hid the verification step
Nobody wrote “verify the change” into the interactive workflow because it happened by default. The developer skimmed the diff, tried it in whatever environment was handy, caught a strange log line and made a call. Verification was a side effect of someone paying attention.
Asynchronous runs expose the step by removing it. Consider an agent woken by a pager alert overnight. No one reviews its reasoning as it goes. If it has no way to confirm its own fix, it has not removed work. It has moved the work to whoever reads the PR in the morning.
Developers already approach that handoff warily. The 2025 Stack Overflow Developer Survey found 46% of developers distrust the accuracy of AI tools, against 33% who trust it. An unattended agent returning unchecked code gives that skepticism more evidence.
A green run against mocks the agent wrote
Give an agent good tools and it gets a lot done alone. It edits the code, runs whatever tests work on its machine, calls its stubs and declares success. The question is what that success is worth.
Every stub encodes the agent’s guess about how a dependency behaves. If the guess is wrong, the stub is wrong in the same way, and the test passes anyway. All the agent has shown is that its code agrees with its own assumptions.
For a single-process app, that distance between assumption and reality is narrow. For a microservice it is where the risk sits. The service talks to other services over the network, writes to databases and message brokers, and sits behind mesh policies for retries and timeouts that are invisible from its own code. Typical breakages at those seams:
- The producer changed a contract after the stub was written
- The consumer expects a field in a different format
- A downstream call starts exceeding its timeout once the mesh adds retries
- A schema change breaks a query no local test runs
All of these appear only when the change runs among the real services. Until then the agent can report a clean run on code that will fail as soon as it meets production traffic two services downstream.
The later a defect is found, the more it costs
| Where the defect surfaces | Who deals with it | Typical cost |
|---|---|---|
| Inside the agent’s own loop | The agent | Seconds. It reruns, reads the error and patches it |
| In PR review | A reviewer | Minutes to hours, and only if the reviewer notices |
| After merge | An engineer who never saw the code | Hours to days, with no agent context left |
| After merge, with dependent changes on top | Multiple teams | A sequence of reverts and fixes |
The bottom row rarely appears in a product demo, but it shows up in incident reviews. With one developer running one agent, the blast radius of a bad change was one person’s afternoon. With agents spawning agents and merging concurrently, any defect that slips out lands in a shared codebase that other work is already building on.
More agents do not raise throughput by themselves. If checking still happens after the PR, extra agents only lengthen the line of reasonable-looking changes waiting for a person to find the flaw. Output scales while trust stays a manual process.
Picking a runtime: isolation, fidelity and cost
The runtime is where it gets hard. Each familiar option gives up one of three things an agent needs.
- Shared staging is realistic and cheap per run, but offers no isolation. A hundred agents testing at once trample each other, and one agent’s partial change shows up as a mystery failure in another agent’s tests.
- A full environment per PR is isolated and realistic, but its cost breaks at agent volume, since each one approaches a duplicate of production and takes minutes to create. Brex found that 99.8% of a duplicated environment’s infrastructure cost went to services nobody was testing.
- Stubs and private per-agent runtimes are isolated, cheap and quick, but not realistic, so the agent ends up checking its code against its own guesses again.
Shared staging
Full environment per PR
Stubs and private runtimes
Shared cluster, changed services only
To get all three, share the environment instead of duplicating it. Keep one production-like set of stable services running in the cluster. Deploy only what the agent changed, and route the requests tagged for that change through the new version so they still hit real services everywhere else. Routing provides isolation, real dependencies provide fidelity, and cost stays low because thousands of lightweight ephemeral environments share a single cluster and each starts in seconds.
The agent’s loop, closed before the PR
Once that runtime exists, the agent can finish verification with no person involved.
- Deploy the modified service into a lightweight ephemeral environment on the shared cluster.
- Send test traffic through it so it calls the real services around it.
- Run the full range of checks: unit tests, integration paths, contracts and downstream effects.
- Read the real error, change the code, repeat.
- Open the PR only when everything passes against the live system, with the results attached.
That PR carries a different promise. It has already been checked against the system it will run in, so the reviewer can focus on whether the design and intent are right. Whether it breaks something three services away was settled before anyone opened it.
Where trust comes from
Ido’s conclusion holds: async development has to be verified development. Agents will take on more of the code as harnesses improve, and interactive sessions will be reserved for unusual work. The difference between an agent you rely on and one you supervise is whether it can prove its changes, and the runtime available to it sets the limit on that proof.
For cloud-native software, that runtime belongs in the cluster, beside the services the change depends on. Signadot provides it with lightweight ephemeral environments that let an agent test a change against real surrounding services within seconds, before the PR, for as many agents as run at once. Signadot for agentic development walks through setting up that loop.
