What is an autonomous AI software engineer?

An autonomous AI software engineer is a coding agent you delegate a whole task to, such as a ticket or a Slack message. The agent plans the work, writes the code, tests it in its own environment and returns a pull request, with nobody at the keyboard. Autonomous means nobody is watching the work happen. It doesn't mean nobody is responsible: people still decide what done means and answer for what ships. There's a lot of buzz about autonomous AI software engineers. So what is an autonomous AI software engineer, how does it work, and who checks the work when no one watched it happen? Watch the video: https://youtu.be/5Twrs1V_n8s

What is an autonomous AI software engineer?

An autonomous AI software engineer is defined by the handover: ticket in, pull request out. A pull request, or PR, is a proposed code change, ready to review and merge. You hand over the task, and the agent walks the whole line alone, from plan to code to tests to pull request. Handing off a whole task this way is delegation. It's the opposite of working interactively, where you sit beside the agent and steer it as it goes. Both words come from the vendors themselves: Factory is built so teams can delegate complete tasks, and Claude Code's Slack integration exists to delegate development work.

What is Devin, and what is Factory?

Two autonomous agent products you might have heard of are Devin, from Cognition, and Factory. Devin is Cognition's autonomous AI software engineer that can write, run and test code. The deal fits in one line: Assign a ticket, get a PR. You delegate a ticket, and Devin tests end to end on its own computer and won't stop until the PR is ready to merge. Factory is an agent-native software development platform, built so teams can delegate complete tasks to its agents, called Droids. When you delegate a Jira issue in Factory, a Droid runs on a remote computer, is instructed to open a pull request and return its URL, and reports progress and results in Jira. Factory also includes human approval checkpoints.

How is a delegated agent different from Claude Code?

Claude Code is a coding harness: the tool that runs an agent on your code, while you sit beside it. Claude Code is an agentic assistant that runs in your terminal, and you're part of the loop: you can interrupt at any point to steer. With a delegated agent, you hand over the ticket and come back to a pull request. But delegated versus interactive is a way of working, not a brand. All three products offer both:
| Product | Delegated use | Interactive use |
| --- | --- | --- |
| Devin | Assign a ticket, get a PR | The Devin CLI, a command-line interface, runs Devin from your terminal, with /handoff to pass longer tasks to Devin in the cloud |
| Factory Droid | Delegate a Jira issue and a Droid runs on a remote computer | Droids work from the command line, among other places |
| Claude Code | Mention @Claude in Slack with a coding task, and Claude Code takes it to a cloud session (this earlier version answers Pro, Max and Ultra accounts) | In your terminal, where you can interrupt at any point to steer | The line runs through the products, not between them. Neither way of working is the better one.

Where Levr fits: does Levr compete with Devin?

Not as an agent. Levr doesn't do the work; it ensures what gets done is what was prescribed. Levr is a companion to the agents, and an alternative to work trackers like Linear and Jira. The clearest way to see why is a board game. The players. Devin, Factory's Droids, Claude Code, Codex and Cursor are the players, competing to do the work, and every player moves along a path from the ticket to done. When you use Claude Code, Codex or Cursor interactively, a developer guides the agent along that path, step by step. Devin and Factory's Droids are autonomous players: you delegate the task, and Cognition and Factory work to keep their agents on the path, on plan and on intent. That steering is real, and it helps. Factory's Missions split the work into small milestones that keep it from drifting, and validate each one. Devin Review checks pull requests for bugs and security issues. The players keep score. It's still the agents deciding how they did, and whether the task is done. Devin works until it judges the pull request ready to merge, and the review comes from Devin too: its findings appear as the Devin bot. In Factory, you agree up front how a mission is validated, but validation workers, which are agents too, judge the result. The board. Levr takes the opposite approach. Levr supplies no players or agents and writes no code. Levr is the game board. Your agents and harnesses play on the board, but they don't set the board, the spaces or the rules. Levr does, based on your plans and intent. Levr keeps the gates, the checks that work has to pass, apart from the agent's opinion. The goal stays put: work isn't done when the agent thinks it's done, but when the gate conditions are met. Levr is the control plane for agentic development: an orchestrator and gatekeeper, independent of the agent harnesses doing the work. Where Levr and Devin overlap is checking the work, and Devin's check lives inside Devin, while Levr's gates span every agent and harness you use.
| Layer | Examples | What it does |
| --- | --- | --- |
| Agents | Devin, Factory Droids, Claude Code, Codex, Cursor | Do the work, and compete with each other to do it |
| Work trackers | Linear, Jira | List the work |
| Levr | The control plane | Holds initiatives, projects, plans, issues, tests, project context and gates, across every agent | Levr works with Claude Code, Cursor, Codex and any MCP client, and you can mix agents on the same project. Levr's gates stay put without being frozen. Usually your agent drafts them from the plan, and you review or edit them. Once work has started, changing a gate takes a reason. A waiver needs a written reason, is recorded with its author, and leaves the failing result readable.

What does autonomous mean for a coding agent?

Autonomy is a dial, not a switch: it sets how much the agent does before it stops to ask a person. In Factory, the Autonomy Level runs from Off through Low and Medium to High, and a command policy can still require approval at High. But turning the dial up doesn't make anyone less responsible for the result. So who reviews code from an autonomous agent? In Factory, delegating an issue does not replace code review. With Claude Code, even on a long run you leave alone, starting the run, deciding what "done" means this time, and approving the merge stay with you. Devin goes further on approval. Devin Review's Autoapprover, in Beta, evaluates whether selected PRs can be approved without human review. The Autoapprover "does not merge PRs itself", though an approval can satisfy a repository requirement. So autonomy changes who's at the keyboard, not who answers for the work.

Can you trust an AI agent when it says the work is done?

When the agent performing the work is also the one reporting on it, the report is what you have, because nobody watched. Claude Code's own guidance puts the two on opposite sides of who has the last word: Claude's summary of what it did on one side, branch protection and a person who approves the merge on the other. Researchers at Mila, the Quebec AI Institute, Tara Research and Cohere built a test called OverclaimBench. They asked coding agents, including Claude Code and Codex, to review sets of files; Devin and Droid weren't in the test. When a run skipped files, 80.4% of those runs were misleading: the agent claimed a full review, or never mentioned the gap. The researchers concluded: "An agent's final report is therefore not a reliable proxy for its execution." Cognition and Factory add real checks of their own, and teams add more:

• Devin Review checks pull requests for bugs and security issues.
• Factory's Missions validate each milestone, with validation workers that run at its end.
• CI, continuous integration, runs automated builds and tests on each change. With Devin, tasks with test suites, CI checks or verifiable outcomes yield the best results. But CI only checks what someone wrote down, Devin's and Factory's checks each live inside their own product, and a person reading every pull request doesn't scale. The fix: evidence decided before the work, independent of the agent, like acceptance checks written on the ticket, tests the agent can't edit, and a verdict from the output, not the report.

What happens when several agents share one plan?

One delegated agent is a helper. But several on a plan can get in each other's way. With Devin, you carve out independent tasks and run them simultaneously. On a real plan, though, tasks depend on each other, and work often overlaps. Researchers at Drexel University and Missouri University of Science and Technology studied agent pull requests on GitHub. They read 600 rejected agent pull requests and could categorize 562. In 142 of those, maintainers pointed to an existing pull request that already made the same change. That's work done twice. The fix: one shared record of what's ready, what's blocked by what, who holds each task, and which work is a duplicate.

How does Levr check the work? The gates are the rules

Levr puts gates above any harness or agent: on the board, the gates are the rules. In Levr, a gate is a check or a test attached to a task, written before the work starts. You set the criteria, and once work has started, changing a gate takes a reason. The agent shows evidence against criteria it didn't get to pick. The agent hands over the command it ran, the exit code and the output, and Levr decides pass or fail from those facts, not from what the runner reports. Nothing passes on the agent's say-so. Not every gate is a mechanical test: Levr's checks also include AI judges plus hands-on checks. Either way, the agent's opinion isn't the verdict. One rule is deterministic: a task can't be marked done while a required gate is failing, no matter what the agent says. Gates check the work against the plan, and people still judge whether the plan was right. So Levr gives you one definition of done across every agent and every person.

How does Levr keep several agents out of each other's way?

Levr shows every player the same board, kept on the issues themselves. Each item on the shared record has a Levr answer:

• Ready work: Levr shows connected agents what's ready, over MCP.
• Blocked work: Levr records what blocks what, so agents can see what's still blocked.
• Who holds a task: An agent takes a ready task by assigning itself, so Levr shows everyone who holds that task.
• Duplicate work: Levr links duplicates, so the work gets merged instead of built twice.

Who checks the work when no one watched it happen?

Levr does, using evidence against gate criteria decided before the work started, regardless of which agent did the work. Humans step in for the decisions that need them, and are responsible for what merges. You set what counts as done. Levr ensures done means proven.

Better agents help. Better gates help more.

Handing a ticket to an agent is only as safe as the check it has to pass. Try Levr free. Levr is free during the preview, with no credit card.