(2026-03-24) Linear Issue Tracking Is Dead

Linear.app says Issue tracking is dead. It was built for a handoff model of software development. A PM scoped the work, engineers picked it up later, and the system filled with prioritization, negotiation, and workflows to bridge the gap. That ceremony came from real constraints. Engineering time was scarce.

But over time, complexity started to look like sophistication. The more process a system could absorb, the more advanced it seemed. Overhead kept growing, and the process became the work.

Linear has always been built on the opposite belief: the best systems remove overhead so teams can focus on building.

Agents push that further

People can spend more time on intent, judgment, and taste, and less time managing the mechanics of the process.

Today, coding agents are installed in more than 75% of Linear’s enterprise workspaces. In the last three months, the volume of work completed by agents grew 5x, and agents authored nearly 25% of new issues.

In this new world, the next system is not designed around handoffs. It is designed around context and agents.

Agents are not mind readers. They become useful through context. Customer feedback, internal ideas, strategic direction, decisions, and code all need to be captured in a system that humans and agents can work from together. This is also true for human builders.

That is what Linear is becoming.
Linear is the shared product system that turns context into execution.

Toward this vision, today we are launching:

Linear Agent.

Skills. As you find workflows worth repeating, you can codify them as reusable skills and compound your learning

Automations. Starting with Triage, trigger agent workflows the moment an issue enters the system.

Coming soon:

Code Intelligence

Code Diffs.

Linear Coding Agent.

These updates build on our earlier work in Triage Intelligence and deep integrations with cloud coding agents and other AI tools.

Issue Tracking Is Dead | Hacker News

At ZAR once we had pervasive ingestion into an organization-wide knowledge graph in place and working well, the next step was to ditch Linear and replace it with a homegrown experiment tracking system that focuses all product engineers on empirical data and scientific method applied to how we prioritize work.
It's the only way to actually encourage high-agency, high-ownership behavior.

Classic clickbait title. I guess it works, but also baits me to respond to it in the first paragraph: Issue tracking is clearly not dead, it is more important than ever. They are doing almost everything right

I really want to see diffs right in the issue. PRs are a dumb historically grown in-between step that is just annoying. As everything else becomes faster, this becomes more of a bottleneck for iteration speed.

Linear Coding Agent
Is this supposed to replace my dedicated coding agent? I’m skeptical of coding agents being built as parts of other products

• We're well aware that feedback comes from anywhere. The Linear agent also exists in other tools (Slack.com, Gong, Intercom, Zendesk, etc.) and we'll continue to add more channels to support collecting and managing feedback where it's coming from.

You can't possibly track all the places where customer feedback come from. So you'll end up needing a human to curate feedback.

Why not use Claude Cowork? It already can connect to any tool via MCP and do all these things (and Claude Code to, well, code tasks)

• Claude Cowork is great when you want to collaborate with AI and third-party tools via MCP, but it's not a multi-user collaboration tool built for organizations. Our customers need to collaborate on software products and AI is only one part of the equation. Our customers need a system of record (long-term history, priority, and cross-team visibility of a project) and contextual collaboration (e.g. a customer success team member reporting a feature request or bug, a person on the product team deciding it's worth building/fixing

🔵 Linear says Issue Tracking is Dead

For product teams, this context includes things like customer feedback, internal ideas, strategic decisions and your codebase, and Linear is pitching itself as the best place for product teams to build this rich context.

Linear says Coinbase is one of the early adopters of “agent-first” development and they published a piece from their Head of Engineering on how they managed to roll this out.

But, as some people have argued, what happens if IDEs like Cursor also decide to bolt on additional product-oriented features to become an alternative place to build the rich context that AI Agents need? Could we potentially also see tools like Claude Code or Figma do the same?

Linear adopts agentic AI as CEO declares issue tracking dead

One thing not mentioned in any of the posts or agent documentation is security, other than that "Linear Agent operates within your existing permissions." Generative AI systems can be vulnerable to malicious prompt injection and other errors. This will become a bigger concern as the capabilities of the agent increase

Basecamp from 37signals, another project management tool, is also planning to reposition itself as "agent first, agent native" with access from any AI agent via a command line interface (CLI) and the promise of becoming "an agent-driven assistant."

Nate B Jones: AI agents are about to route around every tool that can't pass 5 structural tests. Here's the diagnostic.

OpenAI open-sourced OpenAI-Symphony, and Linear.app became the literal control plane for the most ambitious autonomous-coding system ever shipped. Some internal teams saw a 500% increase in landed pull requests.

The thing Saarinen had just eulogized was now the substrate that made all of it work.
He was right about the user experience and wrong about the infrastructure.

The translation step is going away. The state machine, the assignee field, the audit history, the dependency graph, those are staying. They are quietly becoming the most strategic infrastructure in the enterprise software stack, and that repricing extends to every boring tool you own.

Here’s what’s inside:

• The five properties that make a tool agent infrastructure. Why Symphony looks obvious in retrospect
• Why your UX choice was actually a data choice. How Linear’s design discipline accidentally produced the cleanest agent substrate on the market, and what that means for tool selection from here
• The Atlassian repricing. The MCP server, the Anthropic partnership, the acquisition rumor, and why the market is treating Jira’s installed base as a strategic AI asset.
• Which of your tools are next.
• What to do about it. Three prompts that score your stack, spec out an MCP server for anything you build, and produce the migration brief your leadership team is missing.

LINK: Grab the prompts: These prompts exist because the five-question diagnostic in this article is only useful if you actually run it. The substrate audit forces you to score every tool in your stack against the five properties and confronts you with where your real work state lives. The MCP server spec turns “make this agent-ready” into a one-page engineering artifact. The migration diagnostic interviews you about your specific patchwork of systems and produces the leadership brief most organizations are missing. If you can’t fill in the blanks, you’re looking at the swamp tax this article describes. That is the starting point.

Where issue trackers came from

The genre starts with Bugzilla in 1998. Terry Weissman wrote it for Mozilla to replace the in-house defect tracker Netscape had been using.

*“Bugzilla’s developers have chosen to focus on the task of designing a system to track software defects. While the potential exists in the code to turn Bugzilla into a technical support ticket system, task management tool, or project management tool,” they deliberately chose not to. The scope stayed narrow, and the structural shape that came out of that narrowness is the template every issue tracker since has copied.

What Bugzilla encoded, almost as a side effect of taking software defects seriously, was a small set of structural primitives.*

It encoded persistent state outside any single person’s memory.

It encoded a state machine with well-defined transitions. NEW. ASSIGNED. RESOLVED. VERIFIED. CLOSED.

It encoded ownership. The assignee field made it unambiguous whose turn it was. When the assignee changed, the audit history captured who reassigned the bug and when. Responsibility was a first-class property of the data model, not a social convention.

It encoded defined verbs. Create. Comment. Assign. Resolve. Reopen. Mark duplicate. Block on another bug. Each verb had clear semantics, clear preconditions, and a clear effect on state. You could not “sort of” resolve a bug in Bugzilla.

It encoded dependencies as first-class objects.

And it encoded audit history by default. Every change to a bug was logged with timestamp and actor.

Weissman was solving a coordination problem for a few hundred Mozilla developers spread around the world, working asynchronously, through dial-up. The constraints he was responding to were human constraints: limited memory, time-zone friction, hand-off ambiguity, accountability gaps. The structural choices that fell out of those constraints happen to be exactly the choices you’d make if you were designing a substrate for autonomous agents to coordinate work through. That accident is the whole story.

How the genre evolved: Bugzilla, Jira, Linear

Bugzilla escaped Mozilla and became the de facto open-source bug tracker for a generation of projects. Atlassian’s Jira shipped in 2002, took the same structural model, and added the things enterprises needed: workflows configurable by administrators, custom fields, project hierarchy, role-based permissions, integration with everything. Jira became universal in part because it was infinitely flexible. Each company could shape Jira to its specific organizational structure, which was both Jira’s commercial advantage and the source of its terrible reputation. The thing every developer hated about Jira was that no two Jira deployments looked the same. Every company had configured it into its own particular maze.

Linear.app arrived in 2019 with the opposite philosophy.

built it around a single opinionated model: issues live inside cycles, cycles ladder up to projects, and the customization surface is deliberately narrow. You don’t configure Linear to match your org chart. You change your workflow to match Linear, and you accept that this is part of the deal.

The interesting thing about Linear, in retrospect, is that the data model is the same data model Bugzilla shipped in 1998. Issue. State. Assignee. Priority. History. Dependencies. The verbs are the same. Linear’s contribution was speed, design discipline, and an opinionated point of view about what good engineering coordination looks like.

This is the part that counterintuitively matters for agents: good UX produces cleaner data. When people resent a tool, they route around it. Important decisions end up in Slack.com instead of the tracker. Statuses become performative rather than accurate. Tickets get created retroactively, after the work is already done, to satisfy a process nobody believes in. When people actually like the tool, the real work migrates into the system voluntarily. The state gets cleaner. The ownership stays current. The dependencies reflect reality instead of fiction.

the tool that will serve your agents best might not be the one with the flashiest AI features. It might be the one your team has been filling in honestly for three years because the experience never made them want to cheat. (system of record)

Saarinen’s bet, articulated explicitly in his interviews from 2024 and 2025, was that “engineering is really the front line of all this information.” That phrasing reads differently now than it did then. He was saying that engineers’ work was where the real organizational state lived, and that putting good tools in their hands meant the rest of the organization would inherit cleaner state for free. He was right, but the implication he didn’t quite name in 2024 is that “the rest of the organization” includes a population of agents that didn’t exist yet.

Why the substrate fits agents

The reason OpenAI Symphony works, the reason some OpenAI teams reportedly got 500% more landed pull requests by routing autonomous Codex agents through Linear tickets, is that an issue tracker is the thing an agent system would have built for itself if it were starting from scratch.

An agent loop needs a place to put state that survives between runs.

Handoff semantics are the second requirement. Who owns this work right now? Is it the agent, or is it back to a human?

Parallel agents also need a coordination layer that prevents contention.

An agent loop needs audit history that humans can review when something goes wrong. IDC research from 2025 found that 88% of AI pilots never reach production at all, and the failure mode in many of those cases is investigability.

Issue trackers logged every change for thirty years, because thirty years ago we already knew that humans coordinating asynchronously needed audit trails to function.

What Atlassian and Anthropic are doing about it

If issue trackers are the substrate for agentic work, the company holding the largest installed base of issue trackers, Atlassian, with Jira, is sitting on what just became one of the most strategic data assets in enterprise software. Atlassian has noticed, and the moves they’ve been making in the last twelve months read very differently when you frame them through this lens.

In July 2025, Atlassian shipped its Remote MCP Server, branded Rovo, which exposes Jira and Confluence to any MCP-compatible client. Anthropic was the first official partner. Cloudflare hosts the infrastructure. The launch post emphasized that Jira and Confluence customers can “interact with their data directly from Claude.”

The Atlassian Rovo MCP Server is, mechanically, exactly what Symphony assumes Linear is.

In February 2026, Atlassian and Anthropic announced a multi-year partnership with the Williams Formula 1 team. Claude as Williams’ “official thinking partner,” branding on the cars and team kit, integration across the team’s race-strategy and engineering operations.

And then in late April 2026, around the same time Symphony shipped, a rumor began circulating on Blind, Hacker News, and Reddit that Anthropic was in advanced talks to acquire Atlassian for $150 a share, all-cash. Atlassian’s market cap at that price would put the deal in the $40-billion range. The rumor is unconfirmed. There has been no SEC filing, no formal statement from either company, and the conventional skepticism applies. But the rumor is itself a tell. The fact that the market is willing to treat “Anthropic buys Atlassian” as plausible enough to move share price tells you something about how the strategic value of issue trackers is now perceived.

Which other tools are like this

The substrate hypothesis is general. Tools with the same structural properties as issue trackers, persistent state, defined verbs, ownership, permissions, audit history, become agent-usable by accident, because they were already shaped that way for human coordination. Tools without those properties don’t, regardless of how much chat you bolt on.

The strong candidates are obvious once you see the pattern. CRMs (Salesforce, HubSpot) have records, owners, stages, history, and permissions. They are issue trackers for revenue.

Service desks (Zendesk, ServiceNow, Intercom) have tickets, assignees, statuses, and SLAs. They are issue trackers for customer problems. I

ERPs (SAP, Oracle, Workday) have records, workflows, approvals, and audit trails. They are issue trackers for business process at large.

The pattern keeps showing up in every direction you look: calendars, source control, procurement, HRIS, finance systems. Each one is an issue tracker for its own domain. If a system was built to coordinate people asynchronously around important work, it probably has the bones of an agent substrate.

The weaker candidates are the ones with state but ambiguous verbs and ownership. Email has audit history and permissions but its action verbs are conversational rather than structural. There is no assign or resolve in email, just reply.

Chat (Slack.com, Teams) has even less structure. The state of a Slack thread is “the messages in it,” which is closer to a transcript than a database. Agents already operate inside Slack, and Slack has benefited enormously from being the place where humans naturally congregate, because that proximity makes it the first place agent builders integrate. But proximity is not the same as substrate. If Slack is the only place your work state lives, the agent has to infer too much.

Documentation (Confluence, Notion) sits in the middle. It has versioning and permissions but its verbs are weak (edit, comment) and ownership is fuzzy. Useful context, but weaker as a work substrate.

Spreadsheets are the strangest middle case. They have structure, but the structure is user-defined, and often implicit.

The diagnostic for any tool in your stack is five questions. Does it have records or just content? Does it have a state machine or just labels? Is ownership a field or an implication? Are the verbs structural or conversational? Is the history queryable or just visible? Tools that score well on these will become agent infrastructure. Tools that score poorly will need to be replaced or wrapped, and the wrapping will be expensive.

What this means for you

For individual builders, the implication is direct. Your data model is your strategic surface now. If you are building a product that you want agents to use later, don’t start by bolting chat onto the UI. That is a very 2024 approach. Start by making the underlying state clean. Expose state, verbs, ownership, and history through an MCP server. Treat your data model as the public interface, not your UI. I

For teams, the implication is sharper than it sounds. Your work-tracking system choice is now your agent-infrastructure choice. The decision between Jira and Linear isn’t a UX question anymore. It’s a question about which substrate your future agents will run on, how cleanly your work data is encoded, and what shape of automation will be cheap to build versus expensive to retrofit. The same is true for your CRM, your service desk, your HRIS, your ERP.

The companies that own the substrate (Atlassian, Salesforce, ServiceNow, Microsoft, Oracle) are going to be unusually well-positioned for the next several years, because the substrate is hard to displace and the agent layer wants to consume it. The companies whose strategy depends on building agent-native replacements for these systems are fighting gravity. The thirty-year accumulation of human-coordination infrastructure isn’t going to be eaten by a green-field “agent platform.” It’s going to be wrapped, and the wrappers are mostly going to be the incumbents with MCP servers stapled on. Bet accordingly.

But there’s a practical question underneath the strategic one that I don’t think enough leaders are asking: what does your specific substrate actually look like right now? Every organization runs on a different patchwork of these systems, and the real work of building agentic pipelines isn’t choosing which AI model to use. It’s mapping the substrate you already have. Where does your ERP hand off to your CRM? How do your tickets connect to your customer feedback? Where are the clean handoffs, and where is the work state living in Slack threads and spreadsheets that nobody besides the person who built them can interpret?

Saarinen’s “issue tracking is dead” framing was right about the user interface and wrong about the substrate.

The thing nobody loved is the thing nobody can replace. Issue trackers won. The interesting question for the rest of 2026 is which other boring tools are about to follow them, and the diagnostic is sitting in plain sight: persistent state, defined verbs, ownership, permissions, history. If your tool has those, it’s about to become much more strategic than it looks.