Autonomous software engineering agents, of which Devin is the best-known example, are built to take a task — often a ticket or an issue — and work it through to a pull request with substantially less per-step human interaction than other coding agents, using their own sandboxed execution environment that can include a browser, a shell, and a code editor. Governing this category means accepting that the usual per-action checkpoint is largely absent by design, and compensating with scope limits, task-level review, and hard boundaries on what the sandbox itself can reach.

What an Autonomous SWE Agent Actually Does

The individual capabilities are not new: reading a codebase, planning a set of changes, writing and running code, using a browser to consult documentation, and opening a pull request each exist in other coding agent products. What distinguishes this category is the degree of autonomy over the sequence: rather than a human confirming each meaningful step, the agent is designed to work through a multi-hour task largely unsupervised, checking in at defined points — clarifying questions, a completed draft — rather than continuously.

This is explicitly the value proposition: assign a ticket the way you would assign it to a contractor, and get back a pull request rather than a stream of individual actions to approve. Evaluating whether that trade is acceptable for a given task, repository, or organization is the central governance question this category raises, more so than any single technical control.

The Blast Radius

  • The agent's own sandboxed execution environment. Because the agent operates inside an environment purpose-built for the task rather than a developer's existing machine, the boundary of "what can this action reach" is defined by that sandbox's own configuration — its network access, any credentials provisioned into it, and what it can browse or install.
  • Whatever credentials or access are provisioned for the assigned task. An autonomous agent working a ticket that requires access to a specific service or repository needs that access provisioned somewhere, and the scope of that provisioning is entirely within your control, independent of the tool's own design.
  • The pull request surface, as with other repository-level agents — volume and frequency of agent-opened PRs changes what your review process has to absorb, and an autonomous agent working many tickets in parallel can produce that volume faster than a repository-level agent triggered by individual issue assignment.
  • Compounding error over a long task. A misunderstanding early in a multi-hour autonomous run — a wrong assumption about a requirement, a misread of an ambiguous ticket — is not caught by a human at the moment it occurs, because no human is watching that moment. It can shape a large volume of subsequent work before anyone reviews the result.

The Core Shift: Removing the Per-Step Checkpoint

Every other coding agent covered in this series retains some meaningful point of human review closer to real time — an approval prompt in a terminal agent, a pull request review shortly after a repository-level agent finishes a bounded task. An autonomous SWE agent is designed specifically to reduce how often that checkpoint occurs, in exchange for handling longer, less closely supervised tasks.

This means the review that does happen — at task assignment and at pull request time — has to carry more weight than it would for a more tightly supervised agent. Task assignment is the point where scope should be constrained: which repositories, which categories of ticket, and what the agent is explicitly not authorized to touch as part of completing the task. Pull request review is the point where the actual diff has to be read in full, not skimmed on the assumption that a plausible-sounding summary reflects a correct implementation. Neither checkpoint can substitute for the other.

Scoping Task Assignment Deliberately

Treat assigning a ticket to an autonomous agent as a distinct governance decision from assigning code-completion or editor-assist tooling to a developer, because the agent is being given standing authority to work a task with minimal supervision for its duration:

  1. Choose repositories and ticket categories deliberately. Start with tasks that are well-scoped, testable, and low-consequence if wrong — not the first exploratory use case that presents itself.
  2. Provision only the access the specific task needs, scoped and time-bounded to the task's expected duration, not a standing credential reused across every assignment.
  3. Define what is explicitly out of scope — infrastructure changes, security-sensitive code paths, anything touching production data — as a hard boundary the task assignment process enforces, not a hope that the agent infers it. This is the same excessive-agency boundary described in excessive agency: OWASP LLM06 controls.
  4. Cap the number of concurrent autonomous tasks against a given repository, so review capacity is not overwhelmed by a volume of pull requests arriving faster than a team can meaningfully review them.

Prompt Injection Over a Longer Task Window

An autonomous agent that browses documentation, reads a ticket, and consults external content over an extended task has more opportunities to encounter attacker-influenced content than an agent completing a single bounded action — a malicious instruction embedded in a webpage the agent consults, a crafted comment on a linked issue, or content in a dependency it examines. The longer and more autonomous the task, the more those opportunities compound, and the less likely a human is present at the specific moment an injected instruction would need to be caught. See threat model: indirect prompt injection for the underlying defenses, and treat instruction hierarchy enforcement and post-hoc action review as more essential here than for a more tightly supervised agent, precisely because the real-time checkpoint they usually supplement is largely absent.

Review at Pull Request Time Cannot Be Skipped

Because the intermediate steps of an autonomous agent's work are, by design, not continuously reviewed, the pull request it produces is the first and sometimes only point where a human evaluates the actual implementation. Treat this review with the rigor of reviewing a contractor's unsupervised multi-day work, not a colleague's incremental commit: read the diff fully, verify test coverage reflects the actual change rather than a superficial pass, and confirm the implementation matches the ticket's intent rather than a plausible-sounding but subtly different interpretation of it. See insecure output handling for what can go wrong when an agent's output is trusted without that scrutiny.

Common Questions

Is an autonomous SWE agent just a repository-level agent with a longer leash?

The individual mechanics overlap, but the governance implication is different in degree to the point of being different in kind. A repository-level agent working a single assigned issue produces one pull request from one bounded task, with a human able to reason about what triggered it. An autonomous agent working many tickets with minimal per-step interaction can produce a sustained stream of pull requests, each representing a longer unsupervised task, arriving faster than most review processes are built to absorb at full rigor. If review capacity does not scale with assignment volume, the effective review quality per pull request degrades even if the formal review step never gets skipped.

Should an autonomous agent ever be given direct merge authority to reduce the review bottleneck?

No. Removing the merge checkpoint to relieve review-capacity pressure trades a process problem for a security exposure, and it is the wrong fix regardless of how well the agent has performed on past tasks. The correct response to a review bottleneck is to reduce the volume of concurrent autonomous tasks to what the review process can sustain at full rigor, not to remove the review. See approval workflows and break-glass access for how to structure exception paths without collapsing the standing review gate.

What Must Be Enforced Centrally

  • Explicit, scoped task assignment, with repositories, ticket categories, and access provisioned deliberately per task rather than as standing broad authority.
  • A hard boundary on out-of-scope work — security-sensitive code, infrastructure, production data — enforced structurally, not left to the agent's judgment.
  • Mandatory full-diff review at pull request time, with no exception for tasks that appear routine.
  • Concurrency limits on active autonomous tasks per repository, matched to actual review capacity.
  • A centralized record of every task assigned, what access was provisioned for it, and what the agent produced. See how to audit AI agent activity.

What Good Looks Like

  • Task assignment to an autonomous agent is a deliberate decision, scoped to specific repositories and ticket categories, not a default extended to every backlog item.
  • Access provisioned for a given task is narrow and time-bounded to that task's expected duration.
  • Security-sensitive and infrastructure-adjacent work is explicitly excluded from autonomous assignment.
  • Every resulting pull request receives full, unhurried diff review — never a rubber stamp based on a passing test suite and a plausible summary.
  • The number of concurrent autonomous tasks against any one repository stays within what the review process can actually absorb.

The autonomy that makes this category of agent valuable is exactly what removes the checkpoints other coding agents still provide. Compensate at the boundaries you do control — what gets assigned, what gets provisioned, and what gets reviewed before it ships — rather than assuming the agent's own judgment will substitute for them.