What Devin is, in its own words
Cognition says it “operates Devin, the first autonomous software engineer”, which “plans, writes, tests, and ships production code on its own, working inside your codebase and the tools your team already uses” — the stated goal being that engineers “operate more like architects: strategizing, designing systems, and focusing on problem solving.” It says Devin “is deployed at some of the largest and most complex institutions in the world.” Its documentation is more specific and, to its credit, more restrained: the rule of thumb is that if a task would take you three hours or less, Devin can most likely do it, and larger work should be “split into focused sessions” that can run in parallel with managed Devins. Devin has a full desktop environment with a shell, IDE and browser, so it can run your app, click through the UI and QA its own changes before opening a pull request; it supports scheduled sessions for recurring work like triaging Sentry errors, MCP integrations, a CLI with handoff to a cloud session, and a Knowledge store it carries between sessions. (Sources: cognition.com and docs.devin.ai — When to Use Devin .)
We are stating that in full because the stale version of this comparison — “Devin is a demo, it can’t do recurring or long work” — is not true. It schedules sessions, runs them in parallel and QAs in a real browser.
The difference is the shape of the work, and what remains when the session ends.
The difference in one table
| Devin | Forge | |
|---|---|---|
| The unit | A session: one autonomous engineer on one scoped task | A run: one task moving through named roles, each handoff judged before it passes |
| Sizing guidance | Vendor’s own: roughly three hours of human work or less; split anything bigger | Slices that need several perspectives — a PM who surfaces ambiguity, an architect, a developer, a tester, a reviewer |
| Who checks the work | Devin QAs its own changes in a browser, then you review the PR | A management agent per edge: pass, return with enrichment instructions, or escalate to a person — before the next role starts |
| Parallelism means | Many sessions, each finishing its own task | One task moving through roles, plus fan-out to sub-runs when a sweep needs it |
| Primary artifact | A pull request | A run branch — spec, brief and each role’s handoff as commits, Co-authored-by the persona — and then a pull request |
| Memory | Knowledge, held in Devin | Agent memory, plus the run branch in your own repository |
| Where it runs | Cognition’s infrastructure | Managed SaaS, or self-hosted runners on your own hardware |
| Inference | Cognition’s models | Your provider pool with priority weights and automatic failover, including self-hosted models |
| Scope | Software | Software delivery (most mature), plus research, content and operations |
Where Forge is different
Roles that disagree, with a supervisor. A Forge delivery run is five roles: a product manager who surfaces ambiguity instead of inventing an answer, an architect, a developer, a tester and a reviewer. Between each pair sits a management agent that reads the handoff and decides whether it passes, comes back with specific enrichment instructions, or goes to a human. That is the mechanism for the class of work where the expensive mistake happens before any code is written. See Multi-Agent Pipeline .
The reasoning is committed, not summarised. Every run gets a branch — forge/workflow/{workflowId}/run/{runId} — with the spec, the original brief and each role’s structured and freeform handoff as its own commit. You can read why a decision was made, diff a second attempt against the first, or intervene mid-run by committing a corrected handoff yourself. Knowledge that lives in a vendor’s product is useful; history that lives in your repository is durable. See Git-Backed Audit
.
Your hardware and your keys. Self-hosted runners keep execution on your machines, and the routing gateway sends inference to a provider pool you control — with priority weights and automatic failover — including self-hosted models and any OpenAI-compatible endpoint. See Bring Your Own Hardware and Multi-Provider Routing .
It is not only software. The same engine, validation loop and audit trail run a research team that verifies its own sources, a content team, or an ops rotation. Software delivery is where Forge is most mature — because it is how Forge is built — but it is one archetype. See the use cases .
The one number a single agent cannot report
One engineer, however good, cannot report how often it was overruled. There is nobody to overrule it. That is not a criticism of Devin’s output — it is a structural fact about the shape, and it is the thing this table measures.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample, not a pilot, not a customer case study we cannot show you.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is precisely the review a single-agent tool leaves on your desk — here it is priced at one model call per edge, and counted.
It merged 202 pull requests across 7 repositories in the same period — roughly 17 a week, into the platform you are reading about, with a human performing every merge. Organisation-wide, agent-authored work merged at 773 of 875 opened. Forge is not a demo running beside the product; it is how the product gets built, and these are its commits.
A finished run takes about 39 minutes and 5 handoffs. Median dispatch-to-done — and inside those 39 minutes sit the reviews that stopped 80 pieces of work from reaching the next role in the state they were first written in.
5 handoffs and 39 minutes, against Devin’s own guidance of a task you would finish in three hours or less. Everything above that sizing rule is exactly where those 80 stops happened — and where a single session has nobody to catch it.
Ask us to walk you through the runs themselves — the branch, the handoff commits, the verdicts that sent work back, and the ones that went to a person. Every other number on this site belongs to a named run and says so: 18 sources gathered, 11 verified by direct retrieval, 4 corroborated and 2 shipped marked unverifiable, on the research use-case page .
Sources
- cognition.com — “first autonomous software engineer”, autonomy and deployment claims.
- docs.devin.ai — When to Use Devin — task-sizing rule of thumb, session splitting, parallel sessions, scheduled sessions, desktop environment, Knowledge.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.