Every statement about the present or the future below carries one of these labels. The point is that you can see, at a glance, how much weight it can bear.

Notice what the ledger contains: capability descriptions and honest uncertainty, but no evidence about how reliably any of it works on your codebase. That evidence you must produce yourself — as every chapter of this guide tried to model.

Chapter 2 described the shift as moving from typing and running to directing and verifying, and from operating each step to supervising an outcome. The experience of building this guide supports the description with specifics (MEASURED HERE): the time-consuming decisions were about what to ask for and how to prove it — a test that fails on a real defect, a comparison against the original, a budget on change size, a boundary on a command — not about typing code.

What the documentation supports directly (DOCUMENTED): the user is responsible for reviewing proposed code and commands (Source 10), and the safest agent setups keep a human able to deny tool calls (Source 11). The role is changing in where the effort goes; the accountability is not changing at all.

The table is the AUTHOR'S VIEW, but its logic rests on Anthropic's published guidance: use agents for problems where steps cannot be predicted, in trusted environments, accepting higher cost and compounding errors, and start with the simplest solution that works (Source 9). A one-line change done by an agent that explores, plans and verifies costs more than doing it yourself; a cross-module change without any check is dangerous in either mode.

What is real today (DOCUMENTED): subagents for isolation and summaries, dynamic workflows for scripted fan-out, and a manual approach of one worktree per session. What is experimental: agent teams of peers that message each other. The costs are documented too: agent teams use significantly more tokens, with Anthropic's cost page putting it at roughly seven times a standard session when teammates run in plan mode (Source 12), and the agent-teams page advises starting with 3–5 teammates and with research and review before parallel implementation (Source 5).

What is not established: whether specialised agents (a tester, a reviewer, a cleaner) beat one capable general agent over a long project. Anthropic's own engineers list it as an open question (Source 8). MEASURED HERE, in a very small way: two hand-played "agents" working in separate worktrees finished in the wall-clock of one and merged cleanly because they touched disjoint files, and a third that touched the same lines produced a merge conflict (Chapter 11). Parallelism paid off exactly where the work was independent, which is a property of the task, not of the tool.

The offerings exist: GitHub documents a cloud agent that works in a cloud environment and opens pull requests (in its earlier form with a 59-minute maximum session and one branch and one PR per task); Devin is positioned by Cognition as an autonomous engineer taking tickets; Claude Code runs in the cloud, as background sessions, and in CI (Source 6, Source 7, Source 1). What none of those pages provides is independent evidence of reliability on arbitrary codebases — and this guide did not gather any either.

What is documented about the problems of long-running autonomy is more informative than any forecast (Source 8): agents try to do too much at once, leave half-finished work, declare victory early, mark features done on shallow evidence, and lose state between context windows. The mitigations are engineering, not magic: an initial structured plan, one feature per session, descriptive commits, end-to-end tests that behave like a user, and an orientation step at the start of every session. This guide's own Chapter 11 implemented a miniature of exactly that.

AUTHOR'S VIEW, framed as a rule rather than a prediction: autonomy should be extended only as far as verification extends. A task with an independent, mechanical check can be delegated for longer; a task whose correctness only a human can judge cannot, however capable the model.

An observation from the product pages, not a prediction (DOCUMENTED): the agent is no longer tied to the editor. Claude Code is offered in the terminal, VS Code and JetBrains, a desktop app, and the web, all sharing one engine so that CLAUDE.md, settings and MCP servers carry across (Source 1); Copilot spans IDEs, a CLI and a cloud agent (Source 6); Cursor and Devin ship their own desktop environments, and Cline and OpenCode run in terminals, extensions and desktop apps (Chapter 4).

AUTHOR'S VIEW: the editor stays valuable for what it does best — reading code, reviewing diffs inline, fine edits — and the terminal, cloud and CI become the places where long or unattended work runs. Which mix wins for you is an empirical question about your team's tasks, not a settled one.

All of this is the AUTHOR'S VIEW, but each skill is tied to something observed earlier in this guide:

The pattern across the examples is that the model supplied a plausible first answer quickly, and engineering judgement supplied the correctness: knowing that lazy associations multiply queries, that exceptions need a translation layer, that a refactor needs an oracle, that a blocklist is not a boundary. That judgement is built on fundamentals — data structures, databases, networking, concurrency, security, testing — which the rest of this site teaches. Tools that make code cheaper to produce raise the value of being able to tell whether it is right.

Apply the filter to this guide too. It quotes no benchmark because none was verified; its demonstrations are small and labelled; its few vendor-claim statements are marked as claims; and the facts that could not be confirmed (such as Anthropic's founding history, current plan prices, and some competitor details) were left out or flagged rather than filled in from memory.