The Emperor's New Process

A couple of months ago, project management app Linear struck a controversial tone when it stated, "Issue tracking is dead." Linear has always sought to differentiate itself in the crowded space of issue tracking. The company has made a name for itself with a very developer-friendly interface. It has also taken some Salesforce-like swings by claiming they are an advanced AI tool while delivering a mostly ho-hum AI-enabled experience. So when Linear claims that issue tracking is dead, it's safe to assume they've got something to sell you. In this case, it's an agent and some capacity for skills and automation.

And though that statement is provocative, it misreads the moment. The truth is that issue tracking isn't dead, but the boundary between planning and building is. The ticket has always assumed a sequence: someone specifies, someone builds, someone reviews. That sequence is what's dissolving. When the cost of building drops to near zero, the handoff that the ticket exists to coordinate stops being the bottleneck and starts being overhead.

This stirred up a productive conversation at Def Method. After all, we are not managing our work the way we used to. The presence of AI tools has impacted how we plan, write stories, manage work in process, and assess our iterations. One big driver of that change is the accessibility of coding tools. Claude Code and Codex are inexpensive relative to hiring engineers. Putting those tools in the hands of designers and product managers — professionals who have always been part of a healthy development process but who largely refrained from coding — has changed team dynamics dramatically. A PM who used to depend on user stories to see a feature completed is now, in some instances, doing the work herself. A designer may use AI to build a design and a coding agent to implement it. Engineers who used to review PRs for other engineers on their team find themselves increasingly reviewing work from other teams entirely.

On one of our clients, designers implement their designs end-to-end in the codebase. They ship the result to the engineering team as a PR. The engineers, rather than implementing a design, are tasked with making that PR workable within the boundaries of the codebase and its best practices. The spec never existed as a separate artifact; the PR is the spec, the implementation, and the first draft of the conversation about what "correct" means here.

The teams handling this well are the ones who've renegotiated what review means when the thing arriving for review is also the first time anyone has articulated the requirements. Review used to ask: did you build what was specified? Now it has to ask: is this what we should have specified, and does it fit? The teams handling it poorly are the ones still running the old sequence with new tools bolted on — PMs writing detailed tickets that designers and engineers bypass entirely, engineers rejecting PRs for not following a process that no longer reflects how the work actually got made. Friction is created by two different mental models of coordination running in the same codebase at the same time.

The "process" touted by these companies is no process at all. Hiring reflects this. Some hiring managers are now looking for engineers with experience building and maintaining product roadmaps. The "product engineer," fluent in both planning and building, is an attractive hire precisely because that role no longer requires a handoff between two people to get the same job done.

What can you expect as you move into this? As with any kind of change, expect things to be rocky. Your team will spend some time in Tuckman's storming phase. But the storming isn't really about AI, and it isn't really about Linear's product. It's about letting go of a coordination mechanism for a world where planning and building were done by different people, at different times, with a deliberate handoff in between. When that handoff disappears, the coordination mechanism built around it stops making sense, whether or not anyone updates the tool.

The question worth asking isn't whether your issue tracker is dead. It's what's coordinating your team now that the handoff it was built for no longer exists — and whether you've designed that, or you're just discovering it one merged PR at a time.