Every status report goes stale the moment it's written down. Not because the person writing it is careless, but because of the mechanics: a developer implements, then updates the ticket; a Scrum Master chases ten repositories, puts everything together over a few hours, and by the time the report reaches management, the code has already moved on. We've spent years treating this as a discipline problem, so we implemented better hygiene, stricter board updates, and smaller stories. But it was never a discipline problem. It's a data-collection problem, and it has a different kind of fix.
We're testing that fix right now, with a real client, on a large existing codebase. It is an experiment, not a polished way of working, and I'll be honest about that throughout. But the reasoning behind it is strong enough that I think it's worth laying out while it's still in progress, because if it works, it changes how the whole reporting ritual works.
The numbers nobody quite trusts
Ask an engineering team where they are on a feature, and you'll get a number. Eighty percent. Everyone the number is soft, but nobody can say by how much, and there are four reasons why.
The first is multi-repo blindness. A single feature can span multiple repositories, and once it does, no one person holds the whole picture. The information is scattered, which is its own issue, because scattered information looks retrievable right up until you actually try to retrieve it.
The second is staleness. Most developers update the board after they implement, not while they work. That builds a structural lag into the process: a permanent gap between what's actually done and what the board says is done. The report is a snapshot of the recent past pretending to be the present.
The third is subjectivity. "Eighty percent done" carries almost no information. Eighty percent of what? Which parts are implemented, which are blocked, which are at risk? A percentage is a feeling rather than accurate reflection.
The fourth is overhead. Assembling all of this by hand takes time, and because it takes time, it's often stale before it lands.
Underneath all four is something we don't say out loud often enough. Standups share knowledge but write nothing down. Confluence pages are old within hours of being written. And people have varying methods for estimating their own progress. The reporting mechanism guarantees the number is old before anyone reads it. No amount of discipline fixes that.
For most of us, the status is already there
Here's what to do instead. If your team is already doing spec-driven development (SDD), the agent commits as it works. The implementation leaves a trail in the repository in real time without anyone stopping to write a status update. The current state of the work is already in the repo. It's just sitting there, unread.
So the problem was never that the data was missing. It was that we were collecting it the wrong way: by hand, after the fact, from places no single person could see end to end. If the data already lives in the repositories, the job stops being a gathering task and becomes a query.
What this actually requires
That reframe is only as good as the systems underneath it, so let me be concrete about what has to be in place first, because this is not free.
Three things. First, an agent needs access to the repositories: branches, commits, pull requests. Second, it needs a metadata layer that maps features to the people, teams, and components responsible for them. We keep that as structured YAML, which is deliberately agent-readable rather than human-pretty. It's not documentation for us; it's context for the agent. Third, information needs two new homes: a central repository holding business requirements, high-level designs, sprint planning, and task tracking (taking over much of what Jira used to do) and per-feature specifications that live right next to the code they describe.
The mechanism that ties it together is a target repositories table. Every task in the central repository carries a mapping: which component it affects, which team owns that component, and which repository it lives in. That table is the thing that lets a single agent read everything and glue the fragments back into one picture. Without it, you have the same scattered repos you always had.
How the report gets built
In practice, it runs like this. A sprint.yaml sits in the center of it all; it holds dates, goals, team capacity, etc. Task files carry the repository, team, and component mapping. The agent walks the repositories along that mapping, pulls the commits and pull requests and the context and metadata that SDD leaves behind, and assembles a report.
And because it's reading the actual code rather than a ticket, it can retrieve the output however you need it, for example, per business requirement, per repository, per person, per team. It reports what's genuinely finished because the tests pass and the PR merged. It reports what's blocked because the integration tests are failing. It reports carryovers because it can see what didn't work. The thing that used to take hours takes minutes, and it's current.
Traceability is the biggest advantage
If I had to name the single biggest payoff, it wouldn't be speed. It would be traceability.
Once the mapping exists, you get a chain that runs in both directions: business requirement to engineering requirement to feature requirement to code to tests, and all the way back up. "Show me the code for requirement X" becomes a question you ask the agent, not a favor you ask a developer who happens to remember. You can trace the impact of a requirement downward, and you can trace a line of code back up to the business reason it exists.
This is excellent at drift detection. Code written by hand, outside the SDD flow, doesn't carry the context and metadata the agent leaves behind, so it visibly diverges from the intent it's supposed to serve, and the agent can flag exactly where the code and the requirement have come apart. That's the difference between a flashy headline and a durable capability. Fast reports are nice. Knowing, continuously, whether your codebase still matches what it was meant to do is the future.
What doesn't get automated
It's worth being clear about the boundary. Sprint goals stay human. Estimation stays human. The standup conversations, the actual sharing of knowledge and blockers between people, stay human. Retrospectives, architectural decisions, high-level-design review, code review: all human.
This approach automates the reporting of the work, not the judgment about it. It changes how you see the work. It doesn't change who decides what the work should be.
The org changed too
One thing we didn't expect: the tooling reshaped the team, not just the reporting. Making component ownership explicit and version-controlled pushed us toward smaller units, from teams of six to ten down to two or three, with one person accountable per team. When "who owns this component" becomes a fact stored in a file rather than mapped in someone's head, you can ask it, and once you can ask it, the org tends to organize around the answer. Reporting infrastructure turned out to be team-topology infrastructure too.
An experiment, said plainly
I want to end where honesty requires. This is in trial with a client. It is not a shipped result. On paper it looks promising, which is exactly the kind of sentence that should make you cautious, because paper isn't production. Real feedback is a few months away, and we're deliberately attempting it on a large brownfield codebase even though everything about the approach is easier on a greenfield.
The known costs are real. There's a setup burden: the metadata and the sprint YAML have to exist before any of this pays off. Also, it is not a forecasting tool; it tells you whether something is done and where it's blocked, not when it will be finished. There's a genuine question of security surface in giving an agent read access to every repository. And the adoption curve is unforgiving: everyone has to run extended SDD. Half-adoption produces half-truths, delivered with the same confidence as the whole ones.
So I'm not claiming we solved status reporting. I'm claiming the logic is sound enough to bet on, and we're making the bet in the open. If the reasoning holds up under a real brownfield with real deadlines, then this is a plausible default for how teams will operate, where the report is never something you build, only something you ask for. We'll know for sure in a few months.
