Autonomous Software Engineering: Async Agents and Trust Calibration#

TL;DR#

Once an agent can plan its own work (agentic-software-engineering/04) and be trusted to decide its own structure at runtime (multi-agent-orchestration/03), a genuinely staff-level question opens up: how much unsupervised time and scope do you actually hand it, given real, measured, still-imperfect track records? This is a trust-calibration problem, not a binary "autonomous or not" switch - it requires reasoning about blast radius, reversibility, and evidence quality across task types and across time, and getting it wrong in either direction (too little leash wastes the technology, too much leash ships unreviewed damage) has organizational, not just individual, consequences.

The idea#

Everything earlier in this subject assumes a human is in the loop at a granularity close to the work itself: reviewing a plan before execution (agentic-software-engineering/04), reviewing a diff before merge (agentic-software-engineering/05). Autonomous, asynchronous software engineering removes that tight loop: an agent is given a task - fix this bug, add this feature, upgrade this dependency - and works on it unsupervised for an extended stretch (in current practice, commonly ranging from tens of minutes to several hours), producing a pull request only at the end, with no human checking in mid-task. The human's role shifts from "supervise the work" to "decide how much work to hand off unsupervised in the first place, and how to review what comes back" - a decision made before the task starts, not during it.

This is the same deterministic-vs-autonomous spectrum multi-agent-orchestration/03 described for multi-agent structure, but the axis being decided here is different: not "who decides the sequence of steps" but "how much real-world consequence can accrue before a human looks at it." Trust calibration is the practice of setting that boundary deliberately, based on evidence, rather than by default optimism or default paranoia. Both failure directions are real and documented: under-trust (reviewing every autonomous PR as skeptically as a stranger's first contribution, forever, regardless of accumulated track record) forfeits most of the leverage async delegation offers; over-trust (granting broad unsupervised scope on the strength of a few good outcomes, without asking what evidence would change your mind) is how unreviewed damage ships. Current research on human-AI oversight names trust miscalibration - in both directions - as the most common failure mode in deployed agentic systems, and notes that the tools available to support informed oversight decisions still lag what deployment scale actually requires.

How it works#

The evidence that currently exists, and what it actually shows#

This is not a purely theoretical judgment call - there is now more than a year of production data from at least one heavily-instrumented autonomous coding agent, and it is worth reasoning from real numbers rather than vibes.

As a concrete, swappable illustration (not the point of the lesson): Cognition's Devin, per the company's own November 2025 performance review, went from a 34 percent PR merge rate to 67 percent over about eighteen months of production use, while also getting roughly 4x faster and 2x more resource-efficient. Separately, LinearB's 2026 analysis of 8.1 million pull requests across 4,800 teams found AI-generated PRs overall merge at 32.7 percent versus 84.4 percent for human-written ones - and a task-stratified 2026 arXiv analysis found merge rates vary sharply by task type, with security-related PRs merging at meaningfully lower rates (around 52 percent for Devin specifically) than the agent's overall average. Any specific product's numbers will be stale within a year; the pattern underneath them - rising but uneven, and worse specifically on security-sensitive work - is the durable fact worth extracting.

Three things in that evidence matter more than the headline numbers themselves. First, the trend direction matters more than the current level - a merge rate climbing from 34 to 67 percent over eighteen months is evidence of a system getting more trustworthy over time, which argues for periodically re-evaluating a leash you set months ago rather than treating an initial calibration as permanent. Second, the gap between overall and task-stratified numbers matters more than either alone - an agent that merges at 67 percent overall but 52 percent on security-sensitive changes is telling you, directly, that "trustworthy for this agent" is not a single number, it is a distribution across task types, and a blanket autonomy policy that does not account for that distribution is miscalibrated by construction. Third, roughly one-third of PRs needing significant rework, even from the more mature end of the current evidence, is the honest baseline - "mostly good, meaningfully imperfect" is the actual state of the art as of 2026, not "essentially solved," and any trust calibration built on an assumption of near-perfect reliability is building on a foundation that does not yet exist.

The calibration question, decomposed#

"How much leash" is not one decision - it decomposes into at least three separable questions, and conflating them is a common mistake:

Blast radius: what is the worst plausible outcome if this specific task goes wrong? A dependency version bump that fails has a small blast radius - CI catches it, the PR sits unmerged, nothing in production is affected. A change to authentication logic that goes wrong silently (passes tests, looks correct, has a subtle bypass) has a large blast radius - the failure may not be caught by any automated check and can be actively exploited before a human notices. Blast radius is a property of the task, not of the agent's general competence, and has to be assessed per task, not once for "how much do we trust this agent" in the abstract.

Reversibility: how expensive is it to detect and undo the mistake after the fact? A PR that sits in a queue until reviewed is fully reversible - nothing happens until a human acts. A PR that auto-merges on green CI and deploys is far less reversible - by the time a human notices a problem, it may already be live and already have caused downstream effects (bad data written, a security window opened, dependent services calling a broken interface). The security-PR finding above is a direct illustration: security-sensitive changes are exactly the category where reversibility tends to be worst, because a security regression can be exploited during the window between merge and detection, which is one concrete reason the data shows agents underperforming specifically there.

Evidence quality: what track record actually exists for this agent on this kind of task, in this codebase, and how would that change your mind? A generic "AI coding agents are getting better" belief is not evidence for a specific autonomy decision; a task-stratified merge-rate history for this agent on this class of change, in this codebase, is. The honest, staff-level version of this question is not just "what evidence do I have" but "what specific evidence, if I saw it, would make me widen or narrow this agent's leash" - stated in advance, before the next report comes back, so the decision is not quietly re-litigated by whichever outcome happened to occur most recently.

Worked example: setting an autonomy policy across three task types#

A team with a codebase decides how much unsupervised scope to give an autonomous coding agent, and treats it as three separate decisions rather than one:

Dependency upgrades and lint/formatting fixes. Small blast radius (CI and existing tests catch most regressions), high reversibility (a bad upgrade PR just doesn't get merged), and by 2026 industry data, one of the task categories agents handle most reliably. Policy: agent may work fully unsupervised, open the PR, and even auto-merge on green CI with no human review for changes below a size threshold - the cost of occasional false positives is low and caught cheaply.

A new, moderately-scoped feature behind a spec (agentic-software-engineering/03) and a reviewed plan (agentic-software-engineering/04). Medium blast radius, medium reversibility (sits in review before merge, but a subtle logic bug could pass review if the reviewer is not applying the plausible-but-wrong scrutiny from agentic-software-engineering/05). Policy: agent works unsupervised for the multi-hour execution window, but the PR requires human review before merge, with review specifically weighted toward the areas the plan flagged as higher-uncertainty.

Authentication, payment, or access-control logic. Large blast radius, poor reversibility (per the task-stratified evidence, this is exactly the category where current agents measurably underperform their own average), and consequences that can be actively exploited rather than just embarrassing. Policy: no unsupervised execution at all - a human plans this work jointly with the agent from the start, reviews every step, and the agent's role narrows to implementation-under-close-supervision rather than autonomous delegation. This is a deliberate point on the deterministic-vs-autonomous spectrum from multi-agent-orchestration/03, chosen specifically because both blast radius and current evidence argue against it, not a default caution applied everywhere.

The point of walking through three tiers rather than one blanket policy is that "how much do we trust the agent" is not a single scalar the team sets once - it is a matrix of blast radius x reversibility x evidence, evaluated per task category, revisited as evidence accumulates.

What actually re-calibrates trust over time#

Given the Devin trend (34 to 67 percent merge rate over eighteen months), a staff-level question is: what would justify widening a leash that was set conservatively six months ago? The wrong answer is "it's been fine so far" - a run of good outcomes on low-blast-radius tasks says nothing about performance on a task category that has not yet been attempted unsupervised. The more defensible answer is a pre-committed review cadence: track merge rate and post-merge incident rate per task category, not in aggregate, and widen scope specifically for the categories where the evidence has actually accumulated favorably, while leaving categories with thin or unfavorable evidence (like the security-PR gap above) at their current, tighter setting until their own evidence improves. This mirrors the Adaptive Oversight Calibration framing found in current human-AI oversight research: oversight level should track task criticality and competency evidence continuously, not be fixed once at deployment and left alone.

Pros#

Frees senior human attention from moment-to-moment supervision for tasks with genuinely favorable blast-radius/reversibility/evidence profiles, which is where most of async delegation's real productivity gain comes from.
A per-task-category policy, built from real merge-rate and incident evidence, is falsifiable and revisable - it can get better over time as evidence accumulates, unlike a fixed blanket rule.
Forces an organization to be explicit about what "trustworthy" means for a given task category, surfacing disagreements (is this team more risk-tolerant than that one, and should they be) that a vague, implicit trust level would leave unexamined.

Cons#

Requires real instrumentation - per-category merge rates, post-merge incident tracking - that many teams do not have in place, making the honest version of this calibration more effort than the naive "just trust it" or "never trust it" defaults.
Evidence from one codebase, one task category, and one point in an agent's own improvement trajectory does not transfer cleanly to another - the temptation to over-generalize a good result ("it did great on the auth refactor, so it's ready for unsupervised payment work too") is exactly the over-trust failure mode this lesson warns about.
Task-type blast radius is not always obvious in advance - a change that looks like a small, low-risk dependency bump can occasionally have outsized downstream effects (a transitive dependency with a breaking change), meaning the tiering itself carries residual risk that no policy fully eliminates.
The current evidence base (roughly a year and a half of one product's public data, plus a handful of 2026 studies) is thin relative to the stakes of the decisions it is meant to inform - trust calibration built on this evidence should itself be held with appropriate humility, and revisited as more data accumulates industry-wide.

Alternatives#

Uniform supervision level regardless of task — either always-supervised (forfeiting the productivity gain autonomous delegation offers on genuinely low-risk work) or always-unsupervised (accepting the security-PR-style underperformance on high-blast-radius work); both are easier to implement than per-category calibration but foreseeably worse in expectation.
Trust-by-vendor-reputation instead of trust-by-evidence — deciding autonomy scope based on which product or company built the agent, rather than this codebase's own accumulated task-category evidence; faster to stand up, but ungrounded in the specific, local evidence this lesson argues actually predicts outcomes.
A fixed, one-time autonomy grant with no re-evaluation cadence — sets a leash once and leaves it; simpler to administer, but forfeits the entire benefit of a trend like Devin's documented 34-to-67-percent improvement, since a policy that never revisits its own evidence cannot capture an agent (or a task category) getting more trustworthy over time.

When to use it#

Extend autonomous, asynchronous delegation to task categories where you can point to real evidence of favorable blast radius, high reversibility, and an accumulated track record specific to that category and codebase - and build the instrumentation (per-category merge rate, post-merge incident tracking) needed to make that evidence real rather than assumed. Treat the resulting policy as provisional, with a stated cadence for re-evaluating it as more evidence comes in.

When NOT to use it#

Do not extend unsupervised autonomy to task categories with large blast radius and poor reversibility - authentication, payment, access control, anything where a subtle failure can be silently exploited before detection - regardless of how good the agent's aggregate track record looks, since aggregate numbers can and do mask exactly this kind of category-specific weakness (as the security-PR data illustrates). Do not treat a good run of outcomes on easy tasks as evidence for autonomy on hard ones, and do not set a trust level once and leave it un-revisited indefinitely in either direction - static trust, high or low, is itself the miscalibration this lesson is about avoiding.

Key takeaways / mental model#

Trust calibration for autonomous coding agents is a per-task-category decision built from three separable questions - blast radius, reversibility, and actual accumulated evidence for this agent on this kind of task in this codebase - not a single global dial. Real, current data (merge rates rising over time in aggregate, but measurably worse on security-sensitive work specifically) argues for both directions of caution: don't underuse a capability that is demonstrably improving, and don't over-generalize a good track record on low-stakes work into confidence on high-stakes work the evidence doesn't actually cover. The staff-level move is deciding, in advance, what evidence would change your mind in either direction - and building the instrumentation to actually see it.

Self-check questions#

A director wants a single company-wide policy: "agents can work autonomously up to 4 hours before requiring human review, on any task." Using the blast-radius/reversibility/evidence decomposition, explain what this policy gets wrong and what you would propose instead.
Devin's documented merge rate rose from 34 to 67 percent over about eighteen months, but security-related PRs merge at a lower rate than the agent's overall average. Explain why both facts can be true at once, and why citing only the aggregate number to justify expanding autonomy on security work would be a mistake.
Describe a concrete, observable signal (something you could actually measure) that would justify widening an autonomy policy for a task category that is currently supervised, and a signal that would justify narrowing one that is currently unsupervised.
A team has excellent unsupervised results on a new-feature task category for six months and proposes extending the same unsupervised policy to database-schema-migration tasks, arguing "the agent has clearly earned our trust." What is the specific flaw in this reasoning, using the evidence-transfer point from this lesson?
This lesson's worked example ties policy to blast radius, reversibility, and evidence, evaluated per task category. Pick a task category not covered in the worked example (e.g., writing internal documentation, or modifying a public API's backward-compatible surface) and reason through what policy the same three-question decomposition would produce, and why.

References#

Cognition, "Devin's 2025 Performance Review: Learnings From 18 Months of Agents At Work" (November 2025) - https://cognition.ai/blog/devin-annual-performance-review-2025
LinearB, "8 million pull requests reveal where engineering productivity breaks down" / 2026 Software Engineering Benchmarks Report (2026) - https://linearb.io/blog/8-million-prs-engineering-productivity
arXiv 2602.08915, "Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance" (2026) - https://arxiv.org/html/2602.08915v2
arXiv 2601.00477, "Security in the Age of AI Teammates: An Empirical Study of Agentic Pull Requests on GitHub" (2026) - https://arxiv.org/pdf/2601.00477
Anthropic, "2026 Agentic Coding Trends Report" (2026) - https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf
"Between autonomy and oversight: Trust calibration and human controllability in agentic AI systems" (2026) - https://gjeta.com/content/between-autonomy-and-oversight-trust-calibration-and-human-controllability-agentic-ai