What a delivery audit actually looks at
When an engineering leader asks us to look at how their team delivers, the thing they usually want to know is whether AI tooling would help. The thing they usually need to know first is how work actually moves through the team today, because that is rarely how anyone thinks it moves.
A delivery audit is two weeks of finding out. Here is what we look at.
How requirements become stories
We start upstream of the code. Where do stories come from, who writes them, and what do they look like when an engineer picks them up? We read the last fifty stories the team completed, not the templates, the real ones.
This tells us most of what we need to know about how AI tooling will land. If stories are a title and a hope, the tooling will produce plausible wrong answers at speed. If stories carry outcomes and acceptance criteria, the team is already most of the way to a workflow that assistants can accelerate.
How code gets written and reviewed
Then we sit with engineers while they work. Not to judge, but to see. What do they open first when they pick up a story? Where do they go for context? How much time goes to writing versus reading, testing, waiting for a build, waiting for a review?
We look at the review queue closely. Who reviews whom, how long changes wait, how big the changes are, and what reviewers actually comment on. A review process that catches design problems is a strength to build on. A review process that mostly catches formatting is a bottleneck the tooling can remove.
Where quality is enforced, and where it is hoped for
Every team has a story about how quality happens. We look for where it is enforced by the pipeline versus where it depends on someone remembering.
Which tests run automatically, and on what? What blocks a merge, and what only warns? Where do defects actually originate, according to the last quarter of incidents? The gap between the quality story and the quality mechanism is where AI-assisted work is riskiest, because the tooling will produce more, faster, and only the mechanism scales with it.
What AI tools are already in use
By the time we arrive, several engineers are usually already using assistants, each in their own way, with their own configuration, and their own opinion of whether it works. We inventory all of it: which tools, who uses them, for what, with what results, and how much of that is shared.
The pattern is remarkably consistent. A few people use the tools well and quietly. Most use them badly or not at all. There is no shared standard for what good looks like, so the team cannot tell whether the tooling is helping. That is not a tooling problem. It is an installation problem, and it is fixable.
What we measure
We take a small number of measurements and we take them honestly. Cycle time from story start to production, split into its stages so the waiting is visible. Review load per reviewer. The rate at which changes get sent back. Where in the pipeline defects are caught versus where they originated. And a baseline of how the team feels about its own delivery, because that changes too.
These are the numbers that will show whether an installation held, six months later. Without the baseline, nobody can tell.
The readout
The audit ends with a working session for engineering leadership, and a written readout. It has four parts.
A current-state map of the delivery flow with the bends marked: where work waits, where it gets sent back, where quality depends on memory.
The AI tooling inventory, with what is working and what is not.
A target workflow: agent tooling configured for this codebase, evaluations in CI, specification-driven stories, review gates that do not trust the author, and the rituals adjusted for AI-assisted work.
And an install plan: sequence, effort, and the metrics that will show it holding.
What it is not
An audit is not a report card, and we say so on the first day. Teams that feel judged hide the interesting parts. Teams that feel observed show us the workaround they built because the process was in the way, and that workaround is usually the best idea in the building.
Two weeks is enough to see the truth of how a team delivers. Fixing it takes longer, but you cannot fix what you have not seen.