Software Engineering · Chapter 27 of 31
Devin, Blitzy, and the autonomy spectrum
The product tiers between an autocomplete and a fleet of agents, who the vendors actually are, and the one thing that changes as you climb.
A category that produced a great many company names in a short time, and they are routinely compared as if they were alternatives. Mostly they are not — they sit at different points on one spectrum, and knowing which point is the whole of the evaluation.
Who the companies actually are
The first thing to get straight, because it trips people in meetings
Cognition is the company. Devin is the product. They are not two things.
Cognition launched Devin in March 2024 as “the first AI software engineer”, acquired Windsurf (the AI-native editor) in July 2025 after Google hired away its leadership, and renamed that editor Devin Desktop on 2 June 2026.
So “Devin” now names two different products from the same company — the autonomous cloud agent, and a desktop editor. If you search for Windsurf you land on the renamed one, which is covered in your editor, and putting a model in it.
The company has raised repeatedly at escalating valuations. Treat the valuation as a statement about expectations rather than about the product.
Blitzy is the tier-5 example and it is a genuinely different shape. It is pitched at enterprises with large, old codebases: ingest an entire repository — the claim is tens of millions of lines — produce a unified technical specification, then run an orchestrated fleet of agents for eight to twelve hours to batch-generate and pre-compile the implementation.
Its stated split is the most useful thing about it: roughly 80% generated, the final 20% left to human engineers. That is a far more honest framing than ‘AI writes your software’, and it puts the interesting question exactly where it belongs — on whether your team can absorb the 20% and verify the 80%.
A sourcing caution, and it applies to this whole category.
The agent counts, the hour ranges, the percentage splits and the customer velocity figures in this section are vendor-published. There is no independent benchmark for tier-4 or tier-5 tools comparable to what exists for models.
Which is not an accusation — it is a statement about what evidence exists. Ask a vendor at this tier for a reference customer with a codebase like yours and a named engineer you can speak to, because the published numbers cannot answer the question you actually have.
And note the harness finding applies here directly: a benchmark result that does not name the harness is not a result about the model, and these products are harnesses. See harness engineering.
What actually changes as you climb
| Tiers 1–3 | Tiers 4–5 | |
|---|---|---|
| When you review | Continuously, while it happens | Afterwards, on a finished result |
| What you review | A line, a file, a turn | A pull request, or a repository-scale change |
| Context you have | You watched it being made and know why | None. You are reading someone else's code cold. |
| What catches errors | You, immediately | Your tests, your types, your pipeline — whatever exists |
| The binding constraint | How fast you can type and think | How fast your organisation can review |
That last row is the entire decision. Tier 4 and 5 products are bought to increase output, and output was rarely the constraint — the vibe-coding chapter makes the same point from the other end, and loop engineering makes it a third time. Three separate technologies, one unchanged bottleneck.
What makes the higher tiers work, when they do
Notice that the answer is not the model.
- A machine-checkable definition of done. Tests that must pass, types that must hold, a build that must succeed. An unattended agent with nothing to verify against produces confident work nobody can assess.
- A codebase an agent can navigate. Consistent conventions, real tests, a sane structure. The estates that most want tier 5 — decades-old, undocumented, untested — are the estates where it works least well, which is an uncomfortable correlation and a real one.
- Review capacity you have actually counted. Not intend to build. Counted.
- A bounded, well-specified task. Which is the spec-driven argument arriving from a different direction: at tier 4 and above, the specification is the interface.
How to evaluate one
- Run it on your own repository, not a demo one. Every one of these is excellent on a greenfield project and the question is never that.
- Measure the review time, not the generation time. Wall-clock from task assigned to change merged, including every round of human correction. That is the number the business case needs and it is not the number the vendor reports.
- Check what it does when it cannot succeed. Does it stop and say so, or produce something plausible? The second behaviour is far more expensive at tier 4 than at tier 1, because nobody watched it happen.
- Decide the blast radius before the trial, not after. Which repositories, which branches, whether it may touch infrastructure or dependencies.
- Price it per completed, merged change — not per seat and not per task. The same reasoning as cost per completed task in the cost chapter.
The one-sentence version: these are not competitors, they are tiers — Cognition's Devin sits at unattended-agent, Blitzy at orchestrated-fleet, and your editor sits below both; climbing a tier defers and enlarges the review rather than removing it, so the honest question is never ‘can it write the code’ but ‘what verifies the result, and can we absorb the volume’.
Check yourself