Linear says agents now create half the work in its product

Twelve months ago it was 3%. Now it's 50%.

Linear disclosed that the share of work items created by agents rather than humans went from 3% to 50% over twelve months, and that agents are installed in 95% of its paid workspaces (SaaStr). The number I care about more than the headline is the second one: issues carrying an attached pull request from someone in engineering, product or design grew sevenfold since January 2026.

Take the caveats seriously before you take the number. This is share of creation, not raw count. If human-created issues fell while agent issues stayed flat, the share still moves. Linear didn't say whether it's weighted per workspace or aggregated across all of them, which matters a lot: a handful of heavy agent-running workspaces could carry the aggregate. And it's vendor-disclosed, from a company whose product gets more valuable the more this trend is real. No third party audited it.

With all that said, the PR-attachment figure is the one that resists a cynical read. A pile of agent-created issues could just be noise, tickets filed by a bot that nobody ever closes, inflating a metric while making the tracker worse. A sevenfold rise in issues that arrive with code attached means the created work is being resolved rather than accumulating. That's the difference between an agent that files tickets and an agent that does the job.

I run this pattern in my own projects and the shape matches. When an agent files an issue for something it noticed while doing other work, that issue is usually more specific than one I'd file, because it has the exact file and line in context. When it files an issue and opens a PR in the same pass, the review burden collapses to reading a diff instead of reconstructing what someone meant.

The 95% installation figure is the boring number that should worry you more. Nearly every paid Linear workspace has an agent connected, which means nearly every paid Linear workspace has granted an OAuth token with issue-write access to something that reads untrusted text. Cross-reference that with the GitLab Duo disclosures from this week and the eleven MCP CVEs below. Adoption arrived before the permission model did.

Concretely: if your team runs agents against a tracker, audit which scopes those integrations hold and whether any of them can also reach your repo. The create issue permission is fine. The combination of read repo plus write issue plus a model that reads issue bodies is the loop that Instruction Privilege Escalation exploits.