Issue Tracking Is Dead. The Ticket Is Just a Receipt.

Last month I opened Jira to file a ticket for something I had already shipped. The branch was merged. The fix was in production. I sat there filling in a summary, a description, an acceptance criterion, and a story point estimate for work that was finished, deployed, and already forgotten by everyone including me.

I did it anyway. Because that is the process.

That is when it clicked. The ticket was not an instruction. It was a receipt. Proof that a transaction occurred, generated after the fact, filed somewhere nobody will look again unless something goes wrong.

First, the concession

Issue tracking is not going away, and I am not going to pretend otherwise. Neither are receipts. That is the point, and it is the half people skip when they quote the punchy version of this argument.

Something can be mandatory and still be dead. Dead does not mean unused. Dead means it stopped being the thing that does the work and became the thing you keep in case someone asks.

Linear said it first, and got laughed at

In March 2026, Linear, a company that sells issue tracking, put "Issue tracking is dead" on its own homepage. Karri Saarinen, their CEO, said trackers were built "for an era of handoffs." Their COO Cristina Cordova put it more bluntly: "process became the work."

They brought numbers. Coding agents are deployed in over 75% of their enterprise workspaces. Agent-completed work volume grew 5x in three months. Nearly a quarter of all new issues are now authored by agents rather than people.

Hacker News was not impressed. The thread called it awkwardly premature, rebranding dressed as revolution, a company adding LLM features and declaring a category dead to get attention. The recurring objection was some version of but we still need a system of record: long-term history, cross-team visibility, decisions captured somewhere durable.

I think Linear is right and the thread is wrong, and I think the reason is sitting in my own git history. So I went and pulled it.

What my commit history actually says

I want to be careful about what counts as evidence here, so one thing up front: side projects prove nothing. Nobody files tickets for their own weekend repo, and never having had a tracker is not the same as a tracker dying. Issue tracking is a workplace phenomenon. It only means anything where there is an actual Jira instance, actual sprints, actual grooming, and an actual expectation that you use them.

So this is all work. Fifteen repositories at my day job, everything I have authored across the last eighteen months. 1,737 commits, every one of them produced inside a process that formally requires a ticket.

Here is what happened to it.

The part that contradicts me

Look at that right-hand column. Ticket referencing did not collapse. It did not decline. It sat between 16% and 31% for eighteen straight months and never moved.

If my thesis were "agents are killing tickets," this table refutes it. So let me state the honest version instead.

Tickets did not decline. The work outgrew them.

My throughput roughly quadrupled between March and July, from under a hundred commits a month to three hundred. Ticket coverage stayed flat. Which means the number of commits with no ticket behind them went from about 40 a month to about 230 a month.

Jira was always only catching a quarter of my work. Nobody noticed, because a quarter of 60 looks close enough to all of it. A quarter of 300 does not.

The tracker did not fail recently. It was always this partial. Agents just widened the gap until it was too big to keep pretending about.

The detail that actually settles it

I split those ticket references into two kinds: the ones git generated automatically, by stamping a branch name into a merge commit, and the ones an actual human typed into an actual subject line.

For ten consecutive months, I hand-wrote a ticket number exactly zero times.

Every single reference in that entire span was git, mechanically, inheriting a string from a branch name. Not one was a person deciding that the ticket number was worth communicating.

Then hand-written references appear again this April, and climb: 21, then 50, then 35, then 57. Precisely when my volume quadrupled. Those are agent-authored commit messages: an agent reading the branch name and dutifully carrying the ID forward, because that is what the pattern looks like.

So the sequence is: humans stopped writing the ticket number over a year ago. Git wrote it for ten months. Now an agent writes it.

The only entity that reliably writes the ticket number is a machine. The ID survives by being copy-pasted forward. That is not information. That is a fossil. I have a repository directory named after a ticket number to prove it, a folder that has now long outlived whatever it once described.

One honest limit: commit references are a proxy for Jira usage, not a measurement of it. There is plenty of ceremony that never touches a commit message. What this data proves is narrower and still damning: the ticket has no connection to the code.

Why the ticket stopped meaning anything

A ticket was never a to-do item. It was a vehicle.

It carried knowledge across a gap, from the person who knew what was needed to the person who was going to build it. That gap is the entire reason it had to be written down, stored, assigned, prioritized, and tracked. The ceremony existed because the information had to survive a journey between two humans who could not see each other's screens.

Now the person who knows and the thing that executes are inside the same loop. Nothing travels. So the ticket has no cargo. You are still addressing the envelope and still mailing it to yourself, about something already done.

That is why it feels stupid. Not because it is slow. Because it is empty.

What actually died: filing, not rigor

Here is the part that keeps this from being another "process is dead" post by someone who has never maintained anything.

I did not stop writing tickets. I write more specification than I ever have. Constraint documents. Acceptance criteria. Context files. Handoff notes. Some days I write more words of intent than lines of code, and the quality of that writing is now the single biggest lever on whether the output is any good.

Rigor did not die. Filing died.

The tracker was always two products bolted together: a place to think, and a place to store. Agents made the thinking half more valuable than it has ever been. A vague spec now produces confidently wrong code at 300 commits a month instead of quietly stalling. And they made the storage half worthless, because a spec that gets consumed in ten minutes has a shelf life measured in hours.

Jira is a warehouse for things that no longer keep.

The artifacts that replaced it all share one property: they are versioned with the code instead of running parallel to it. The spec in the repo. The pull request. The commit message. And increasingly, a working file that holds the current state of a task and gets overwritten rather than appended, then deleted when the work lands.

That last one is the tell. It is a ticket in every functional sense: intent, constraints, status, next action. It just has no ID, no assignee, no column, and no afterlife. I did not set out to build a Jira replacement. I built one by accident, and then noticed what I had left out.

Answering the objection properly

The strongest counter, the one that ran through that whole Hacker News thread, is organizational memory. History, cross-team visibility, decisions captured somewhere durable, an audit trail when someone asks what happened in Q2.

I concede all of it. Completely.

And notice what every single one of those is. History. Audit. Visibility. Traceability. Not one of them is building anything. Every item on that list is a record kept against a future question: what happened, who decided, why it cost that much, was anyone paying attention. That is the definition of a receipt, and it is a real reason to keep one.

That is not a rebuttal to my argument. That is my argument, stated by the people who disagree with me.

There is a real cost to what replaced it, and I will name it: ephemeral state means no archaeology. Six months from now, nobody can reconstruct why. That is a genuine loss and I do not have a clean answer for it yet.

But I would rather solve that problem honestly than keep pretending the board was ever doing it.

What is actually ending

Jira was never a productivity tool. It was a translation layer between people who could not see each other's screens. Its value has always scaled with the number of people who are not in the room.

At two hundred engineers that number is large and the tax is worth paying. But agents are steadily shrinking how many people need to be in the room for any given piece of work. A feature that used to move through a product manager, two engineers, and a reviewer now moves through one person and a loop. The tax does not disappear. The taxable population does.

That is what those 230 untracked commits a month actually are. Not sloppiness. Just work that no longer has a gap wide enough to need a ticket to cross it.

So keep the tracker. Keep the audit trail. Stay compliant. File the receipt.

Just stop confusing the receipt with the purchase. Nobody has ever built a company out of its filing cabinet, and right now there are people whose entire job is the filing cabinet. That is the part that is actually ending.