Is It Actually Done? Verifying Project Status Against the Code
By Fahad Ijaz · · 5 min read
Every CTO has asked some version of one question: are we actually on track? The answer usually comes from the board, the milestone view, or a status meeting, and all three share the same flaw. They report what people remembered to write down, not what the code actually does. The map is not the territory, and in engineering the gap between the two is exactly where bad decisions get made.
Your Tracker Is a Claim, Not a Fact
An issue marked Done is a claim that something shipped. An issue still sitting open is a claim that it did not. Both are routinely wrong. Teams merge work and forget to close the ticket, so real, shipped features look like untouched backlog. Other tickets get closed optimistically and then the change is reverted, superseded, or only half implemented, so the board shows finished work that no longer exists. If you make roadmap and staffing calls off those labels, you are reasoning about a fiction.
The Failure Mode Nobody Catches
The most expensive gap is the one a board can never show you: work that shipped in the opposite direction of what was asked. A ticket asks to relax a constraint and the code that lands tightens it. A ticket specifies one approach and a different one gets built partway through. The status field still flips to Done, because someone genuinely did work, but the thing the business wanted did not happen. No amount of staring at columns surfaces this. You only find it by reading the actual change against the original intent, and almost nobody has time to do that across a whole backlog.
Grounding Status in the Code Itself
Our approach starts from a simple principle: the tracker tells you what people say, and the code tells you what is true. So for any status question we reconcile the two. We take each item that matters, locate the real implementation behind it across commits, pull requests, and releases, and read what the code actually does rather than what its label or its name implies. A status is only reported when there is concrete evidence behind it. When the evidence is not there, the honest answer is that it is not there, not a confident guess.
Why This Is Harder Than It Looks
Pointing a language model at a tracker and asking what shipped is easy, and almost always wrong. Models are eager to agree with a label, to treat a matching file name as proof, and to fill gaps with plausible narration. The real engineering is the discipline around that: requiring every status claim to be backed by code that was genuinely examined, checking each requirement of a ticket against the specific logic that satisfies it, and refusing to call something done, or not started, without actually looking. The value is not the model. The value is everything that stops the model from bluffing.
What a CTO Actually Gets
The output is a status you can act on without a manual audit. Not a column count, but a reconciled picture: what truly shipped versus what merely got marked done, what is genuinely stuck versus what is quietly finished and waiting to be closed, which tickets are now stale and should be rewritten, and the one item that is actually blocking real users. It also names who did the work, so you know who to talk to. In short, the answer a senior engineer would give you after an afternoon of digging, in the time it takes to ask the question.
The Takeaway
Status that is not grounded in code is just a rumor with a timestamp. As engineering organizations lean harder on AI to summarize and report, that distinction only matters more, because a confident wrong answer is worse than no answer at all. Verifying against the code is slower and more expensive than reading a label. It is also the only version worth trusting.
Written by Fahad Ijaz. About Figorit.