For a long time, I thought the problem with issue tracking was mostly tooling. Some systems felt too heavy. Some felt cleaner. Some made the work feel more bureaucratic than it needed to be. But the more I worked on real engineering problems, the less I believed the interface was the main issue. The deeper problem is **drift**. By drift, I mean the gap between what the tracker says is happening and what is actually happening. The board says the project is moving. The ticket says “in progress.” The hierarchy still looks tidy. The milestone still has a shape. But the real work is already somewhere else. It is in the side conversation that changed the scope. It is in the dependency nobody modeled clearly. It is in the meeting where everyone realized the original plan was wrong. It is in the Slack thread that now contains more truth than the ticket ever did. The tracker still looks fine. Reality has moved. I do not think this is a weird edge case. I think it is one of the default failure modes of project tracking once the work becomes real enough. Issue tracking works best when the work is already stable. Clear owner. Known path. Bounded scope. Predictable dependencies. A lot of important engineering work is the opposite. It changes shape while you are doing it. You discover the real problem halfway through. The “small task” turns out to be three different tasks, or one giant messy one. The blocker is not even technical. It is hidden in coordination, ambiguity, or timing. Static systems do not love that kind of work. They want clean parents, clean children, clean statuses, clean rollups. But real work does not stay clean for very long. That is why I think the deeper problem is not hygiene. It is representation. The system is trying to hold still while the work keeps moving. **The map is not the work** Early in my career, I spent a surprising amount of time learning how work was supposed to be tracked. Not just how to write a ticket, but how to move it properly. Which state to use. How much detail to include. What belonged under what. When to split work. When to update status. How to keep the board healthy. Then I spent years following that process pretty strictly. The assumption underneath all of it was simple: if work was tracked correctly, then the project was under control. I believed that for a while. Now I think that assumption breaks in a very predictable way. The issue tracker is a map. The work is the terrain. When the terrain is calm, the map looks pretty good. When the terrain starts shifting, the map falls behind. That does not make the tracker useless. It just means people often expect it to be more truthful than it really is. A clean board can be one of the most misleading things in engineering. Not because cleanliness is bad. But because a clean board can create the feeling of control long after the system stopped reflecting the full state of the work. **Why it gets worse on the work that matters most** This gets worse on the kinds of work that are hardest to reduce into neat execution steps. Platform work gets weird. Infra migrations get weird. Cross-team projects get weird. Incidents definitely get weird. These are usually not just delivery problems. They are discovery problems. You are not simply executing a plan. You are learning what the work actually is while doing it. The original issue might say one thing. Then someone finds a hidden dependency. Then the risk changes. Then the actual blocker turns out to be another team. Then the “small cleanup” becomes a larger design decision. Then half the meaningful context moves into a doc, a meeting, or a chat thread. At that point, the board is still there. The labels are still there. The hierarchy is still there. But the truth is scattered. That is drift. The official structure stays still while the actual work keeps moving. Teams usually respond in one of two ways. Either they spend a lot of energy manually cleaning the tracker to keep it believable. Or they quietly stop trusting it and let the real project state live somewhere else. Neither feels great. One creates admin overhead. The other creates invisible work. **Why AI changes the conversation** What feels different now is that AI changes which part of this problem matters most. A lot of AI discussion around project management is about making issue management easier. Write the ticket faster. Summarize updates. Move workflow states. Assign the next owner. Let an agent keep the board fresh. All of that is useful. I just do not think it gets to the deepest problem. The more interesting shift is that AI makes the exact issue-tracking taxonomy less important than the underlying structure of the work itself. Humans care a lot about these categories: initiative project issue sub-issue milestone cycle We argue about where work belongs. What should roll up into what. Whether something should be one ticket or five. Whether this belongs under a project or should be tracked separately. To AI, those categories matter a lot less than we think. A parent-child hierarchy is just structure. Text, status, owners, labels, dependencies, comments, timestamps, links, filters, related docs, related code changes — these are all just pieces of connected context. What we call an issue tracker is really a partially structured graph of work. Some of it looks like a tree. Parent and child. Project and sub-task. Initiative and issue. Then labels, dependencies, comments, shared owners, linked docs, pull requests, and other relationships add more edges. Now it is not just a tree anymore. It is a graph. And I think that matters. Because once you start looking at it that way, the question changes. The question is no longer just: did we maintain the board correctly? It becomes: is the structure rich enough for AI to reason over the real state of the work? That is a much more interesting question to me. **To humans, it is a workflow. To AI, it is a graph** Traditional issue tracking was designed for humans. That makes sense. Humans need simplification. Humans need a usable interface. Humans need some way to roll up complexity into something navigable. So we built systems full of containers, categories, states, boards, filters, milestones, and rollups. That works reasonably well when the abstraction stays close enough to reality. But AI does not need the same simplification. AI does not care much whether you call something an initiative or a project. It does not care emotionally whether a task should be a sub-issue or its own item. It does not care about the ceremony around moving an issue from one column to another. What it can do, if the structure is good enough, is traverse the whole thing. It can compare parent state against child state. It can notice when an “active” project has no meaningful movement. It can detect contradictions between comments and status. It can connect discussion happening outside the issue hierarchy back to the work. It can find the missing edge that humans forgot to model explicitly. It can notice when the board still looks organized but the real state has drifted. That is the part I keep thinking about. Maybe AI’s biggest contribution to project management is not better ticket writing. Maybe it is not even better issue automation. Maybe it is drift detection. Maybe the real value is telling us when the system of record has stopped matching reality. **Tracking starts to matter differently** I do not think issue tracking disappears. Humans still need ownership. Prioritization. Planning boundaries. A common language for discussing work. But I do think the center of gravity shifts In the old model, a lot of value came from manual maintenance of the board. Keep it clean. Keep it current. Keep it believable. In the AI model, I think the value shifts more toward representation. How well does the system capture the shape of the work? How well does it capture relationships? How well does it connect artifacts, decisions, dependencies, and actual movement? How much truth is available in the structure, even if the board itself is imperfect? That seems more important than whether the workflow taxonomy is perfect. The naming matters less than the shape. The board matters less than the graph underneath it. The process matters less than whether reality is still legible. **Why I keep coming back to this** I think I keep circling this idea because I have seen too many situations where the official picture lagged behind the real one. That is true in incident response. It is true in platform work. It is true in migrations. It is true in almost any project where uncertainty is high and the state changes faster than documentation can keep up. We are used to treating the tracker as the source of truth. More and more, I think it is better described as a negotiated approximation Useful, but partial. Helpful, but lossy. Structured, but always at risk of drift. Maybe that was always true. What feels new now is that AI gives us a chance to care less about perfect manual hygiene and more about whether the structure is good enough to recover the truth. That feels like a better direction. Not cleaner issue tracking for its own sake. Not more ceremony wrapped around a slightly nicer board. But systems that can tell us, earlier and more honestly, when the board has already stopped being true.