The most revealing number in Linear's March 2026 "issue tracking is dead" announcement wasn't the headline. It was buried in the supporting data: 25% of issues across enterprise Linear workspaces are now created by agents. When you layer on coding sessions — launched June 11, converting issues to PRs in the cloud without local setup — you get a system where agents write the spec and agents write the code. The human's job shifted somewhere else, and most developer productivity tools have no idea what to measure there.
Karri Saarinen's March declaration was blunt: "Issue tracking was built for handoffs. We're replacing it with a system centered on context and agents." Three months later, coding sessions make it literal. You assign an issue to Linear Agent, the agent reads the issue, investigates the codebase, proposes an approach, writes the code, opens a pull request. For a well-scoped issue, this takes twenty minutes.
Saarinen made the implication explicit: "A coding agent can ship a wrong feature in twenty minutes, so the cost of bad intent went up, not down."
What "Bad Intent" Costs When Agents Are Fast
In the hand-coded era, the distance between a bad idea and its implementation was wide. You discussed a feature in Slack, wrote an issue, assigned it, the developer pulled the ticket, built a mental model, asked a clarifying question, waited two days, then wrote the code. The friction created natural checkpoints. Wrong intent got corrected during implementation almost by accident — because a human encountered the consequences of the underspecified idea and pushed back.
Agentic implementation removes most of those checkpoints. The agent doesn't push back the same way. It reads the issue, infers what it can, and ships something. If the intent was wrong — the feature solves the wrong problem, the scope was poorly considered, the customer signal was misread — the PR is wrong and it was wrong quickly. The friction that used to catch specification problems is gone.
This is what "the cost of bad intent went up" means practically. Speed amplifies judgment calls. Better intent produces better output faster. Worse intent produces worse output faster, at higher review cost.
Where the Human Work Actually Lives
If agents are writing 25% of issues and converting issues to code in 20 minutes, what is the human doing? The work moved to places that never had good metrics.
Customer conversations. An issue grounded in a real complaint, with the signal attached and edge cases called out, produces a better agent session than one written from a vague internal hunch. Extracting that signal — sales calls, support tickets, Intercom threads, recorded demos — precedes and determines issue quality. It happens in calls, in Slack, in product docs. None of that time shows up in a commit graph.
Context curation. Linear's coding sessions work because they pull in "issue details, history, customer requests, discussions, and related work." That workspace context doesn't accumulate automatically. Someone maintained the issue descriptions. Someone tagged the customer signal. Someone kept discussions focused enough that the agent can read them and understand what matters. The agent's output quality is bounded by how well the workspace was tended.
Priority judgment. Agents can be assigned to any issue in the backlog. Deciding which twenty issues get delegated this week — and in what order — is now a non-trivial allocation decision that shapes what the product becomes. It's product judgment at a faster cadence than most teams are used to making it. It produces no artifacts that look like developer output.
Review and direction. Someone reviews the PR the agent opened. If the approach is wrong, someone redirects. If the tests miss a case, someone explains why. This is oversight labor. It produces judgment, not code. The time goes into Linear comments, GitHub review threads, Slack messages explaining why the first attempt didn't capture the actual requirement.
The Measurement Gap
The developer productivity stack most teams use measures implementation: commits, PR merge rate, cycle time from issue to merge, lines of code. WakaTime tracks coding hours. Copilot metrics track acceptance rate. DORA tracks deployment frequency.
None of these metrics captured the two hours you spent in customer calls before writing the issue the agent converted to a PR in twenty minutes. None measure how good the issue was, which was the entire determinant of output quality. The cycle time metric looks excellent — issue to PR in 20 minutes — even if the PR addresses the wrong problem and gets closed after review.
The measurement problem runs in both directions. If agents are writing 25% of your issues and implementing another fraction of the rest, your activity metrics look like a lot of development output. You might be doing significantly less implementation than the numbers suggest while doing more upstream judgment work that produces nothing countable. Or the opposite: you're doing high-quality context work that makes every agent session sharper, and the metrics show the merged PRs without capturing what made them right.
Standard developer productivity tooling was built to measure implementation. It now needs to measure something upstream of that, and mostly doesn't.
What's Worth Tracking
The signals that matter in an agentic workflow are different from the ones that mattered when humans wrote all the code.
Issue quality is a leading indicator for session output. The best proxy is discussion richness — issues that generated substantive clarification, that have customer signal attached, that document design decisions inline, produce better agent output than terse one-line descriptions. You can track this. It's real work that takes real time.
Time allocation across pre-implementation activities matters. How much time goes into customer calls, design reviews, issue writing, and context curation versus editing, reviewing, and debugging? As agent capability increases, that ratio should shift toward the former. If it isn't shifting, you're either not using agents in the way that unlocks their value, or you're doing upstream work that nothing is measuring.
Redirect rate on agent sessions measures intent quality directly. How often does the agent's first approach need substantial correction? An agent misunderstanding the goal and being corrected three times before producing something usable is worse than a developer who understood the goal from the beginning. Tracking redirect rate across sessions gives you feedback on issue quality that pure output metrics miss entirely.
At xeve, we track application-level time — every app, every session, every context switch. When the work moves from the editor into Slack and Linear, we see that shift. Most developer productivity tools don't, because they were built for a world where the editor is where the value gets created. That's the world that's ending.
Linear's bet is that the constraint on software output is now intent quality, not implementation throughput. The numbers behind their announcement — 25% agent-written issues, 5x agent volume growth in three months, 75% of enterprise workspaces with agents installed — suggest they're reading the market correctly. The metrics for tracking whether that bet pays off are still mostly being built.