Linear Says Issue Tracking Is Dead. They're Right About Half of It.

Linear just published a new announcement page — /next — that opens with a blunt line: "Issue tracking is dead." Underneath: a new agent product, new automations, and a coding agent on the way. The pitch is that tickets become self-driving — context comes in, agents pick them up, code goes out.

I think they're right. And I think they've solved the wrong half.

I argued a few months ago that the backlog is dead, so I'm not here to defend tickets. The forward-thinking teams I talk to had abandoned them before AI made it cheap to. The argument was straightforward: when fixing a known bug costs the same as understanding it, why are you maintaining a queue?

Linear has now made that argument official, and at scale. Twenty-five thousand teams, real distribution, real product. "Issue tracking is dead" from one of the largest issue trackers in the world is a remarkable thing to publish.

But here's the part of the post-backlog argument I made then, and that Linear's announcement still misses:

The task list dies. The thinking doesn't.

The Wrong Diagnosis

Linear's framing is that issue tracking failed because it was designed for handoffs, and handoffs are slow. Their fix is to take the existing primitive — the issue — and make it smart enough to be handed off to agents instead of humans. Codex picks up ENG-2703, Codex writes the code, Codex opens the PR. The agent replaces the handoff. Tickets become self-driving.

To be fair, Linear sees the deeper problem too. Their announcement explicitly says people should spend more time on "intent, judgment, and taste" and that the system should "understand intent, route work to the right actor, escalate when needed." They name the thing. The disagreement isn't whether intent matters.

It's where intent lives. Linear's answer is that intent should live inside the same system that holds plans, work, and code — the issue tracker, evolved into a workspace that understands all of it. The issue (or the project, or the document) is still the operational primitive, and intent becomes one of several inputs that get shaped into work.

That accepts the same structural assumption that made backlogs broken in the first place: by the time something becomes work, the deciding is already over.

It isn't. Most of what fills a backlog isn't bugs. It's decisions disguised as tasks. "Add SSO support." "Redesign the onboarding flow." "Build a dashboard for enterprise customers." These aren't problems with known solutions. They're bets about what matters, and the part that's hard isn't writing them down — it's figuring out whether they should exist at all.

When AI agents execute well-decided work, you ship faster. When AI agents execute badly-decided work, you ship the wrong thing faster. Linear's upgrade directly improves the first case. The second is where the upstream system starts to matter.

The Loop Before the Loop

Linear's product now names five stages — Intake, Plan, Build, Diffs, Monitor. Look at where the loop starts. Intake's job is to take conversations and feedback and turn them into routed work. Conversations come in. Issues come out. The decision happens in between, and the system waves at it on the way to filing the ticket.

The decision is the work. Filing the ticket is the receipt.

There's an entire upstream loop that has to run before anything reasonable can become a ticket — and most teams don't run it. They run it in someone's head, in a Slack thread, in a Google Doc that disappears. Then the ticket gets filed, the rationale evaporates, and the agent (or the engineer) executes against a description that no longer carries the why it came from.

The upstream loop is short and unglamorous:

Capture. A user complaint, a quote from research, an observation, a metric, a request. Real evidence, not opinion.

Specify. Crystallize the evidence into a structured intent: what we're trying to do, who it's for, what success looks like, what edges exist, what we won't do.

Handoff. Send the intent — not a paraphrased ticket — to whoever's executing. Could be a person, could be a coding agent, could be Linear.

Verify. When the work ships, check whether the original problem actually moved.

This loop predates AI. Good PMs have been running it informally for decades. What changed isn't the loop — it's that AI execution is fast enough now that the quality of the input is the entire bottleneck. A coding agent can ship a wrong feature in twenty minutes. The cost of bad intent went up, not down.

Why This Isn't Just "Better Tickets"

Linear's instinct will be that this is the same problem with a smaller solution: enrich the ticket. Add evidence references. Auto-generate the description from the conversation. Ship a Linear Skill that watches Slack and writes the ticket for you.

That fix runs into the same wall that filling-in-better-Jira-templates ran into ten years ago. The artifact is still a description of the work, not a description of the decision behind the work. The ticket says "build SSO." It doesn't say which evidence convinced you to build SSO this quarter, what outcomes prove it worked, which constraints rule out the obvious shortcuts, or what edge cases were debated and resolved. Without that, the agent does the same thing the engineer used to do: it makes the missing decisions implicitly, and the resulting product is shaped by whatever the model defaulted to.

The right primitive isn't an enriched ticket. It's a different artifact entirely — one that carries evidence, intent, and verification state as first-class structure, not as comments stapled to a task. Call it an IntentSpec. Call it whatever you want. The key property is that it has to exist before anything becomes a ticket, and the ticket is an export of it, not the source of truth.

What Comes After "Issue Tracking Is Dead"

Linear is already moving upstream. The Intake product is the first step — feedback consumed, work routed. If that direction continues, the harder structural question is whether an issue-centered system can treat evidence and intent as first-class primitives, or whether they end up as adjacent fields on the issue.

The intent layer is hard to fit on top of the issue. It needs a different unit (evidence, not tasks), a different artifact (a spec, not a ticket), and a different audience (the people deciding what's worth building, not the people executing it). When you start from the issue tracker, those things look like adjacent features. When you start from the decision, they're the whole product.

This is the lane we've been working on for the last two years at Pathmode, and it's why we now describe Pathmode as the product intent system for teams and agents. The grammar mirrors Linear's "product development system for teams and agents" deliberately. We don't compete on the same axis. Linear is where teams plan, track, and execute product work. Pathmode is where teams decide what should become product work in the first place. Linear turns context into execution. Pathmode turns evidence into intent.

A coding agent doesn't need a smarter ticket. It needs a spec that carries the why — and a system that produced that spec from real user reality, not from a Slack thread someone happened to remember.

The Real Upgrade

Linear's claim is that issue tracking is dead. The truthful version is longer.

Issue tracking as ceremony is dead. Issue tracking as bureaucracy is dead. Issue tracking as the place where stale work goes to be re-prioritized monthly is dead. Good riddance.

But the deciding isn't dead. It got harder. It got faster. It became the bottleneck.

When AI agents are doing the building, the most valuable artifact in your system is the one that captures what you actually meant — grounded in user evidence, validated for completeness, traceable back to outcomes. That artifact doesn't live inside the issue tracker. It lives upstream of it.

That's the half Linear hasn't shipped. It's the half worth building.