How to Run a Code Gap Audit in Under 5 Minutes

A gap audit compares what your user stories say should be built against what's actually in your codebase, and tells you exactly where the two disagree. This is a practical walkthrough of running one on your own repo: connecting it, running the first phase of analysis, reading what comes back, and knowing what to do with it. 

Before You Start 

• A connected repository. GitHub, GitLab, Bitbucket, or Azure DevOps, cloud-hosted or self-hosted. Repositories up to 10GB and 100,000+ files are supported, and multi-repo projects get analyzed together with results aggregated into one view. 

• User stories or requirements already in the project. Gap analysis works by semantically comparing stories against code, so you need stories with acceptance criteria in place first, imported from Jira or Azure DevOps, or entered directly. 

• A WalnutAI account. Sign up, or use an existing workspace if your team already has one. 

Step 1: Connect Your Repository 

Authenticate WalnutAI against your repository host and select the repo, or repos, you want analyzed. If your project spans multiple repositories, connect each one, WalnutAI aggregates results across all of them into a single gap analysis view instead of forcing you to review each repo separately. 

Step 2: Run Phase 1 Analysis 

Phase 1 is a semantic comparison of every user story and acceptance criterion against your actual source code. For each story, it returns a gap category, Missing, Incomplete, or Outdated, a confidence score from 0 to 100 percent, and the exact code snippets it's basing that judgment on. This runs automatically once your repo and stories are both connected, no manual mapping between requirements and code required. 

Step 3: Read the Score 

The three gap categories mean specific things, not just "good" or "bad": 

• Missing. No code was found implementing this story at all. This is the highest-priority category, it usually means either the work genuinely hasn't been done, or it exists somewhere the analysis didn't have visibility into. 

• Incomplete. Some implementation exists, but it doesn't cover the full acceptance criteria. Read the linked snippet against the story's criteria to see specifically what's missing before treating it as done. 

• Outdated. Code exists and once matched the requirement, but the story has since changed and the implementation hasn't caught up. This is the category most likely to represent silent scope drift, work that was correct when it shipped and quietly stopped being correct. 

The confidence score tells you how sure the analysis is about its own categorization. A Missing result at 95 percent confidence is worth acting on immediately. The same category at 60 percent is worth a quick manual check first, the code might exist in a place the semantic comparison didn't weight heavily, like a shared utility or a recently merged branch. 

Step 4: Act on the Findings 

Each gap links directly to the relevant code, so triage doesn't require a separate search through the repo. Start with high-confidence Missing results, since those represent the clearest gap between what was promised and what was shipped. From there, Outdated results deserve attention before Incomplete ones in most cases, since outdated code was correct once and is now quietly wrong, which is a different kind of risk than code that was always partial. 

Phase 1 is the starting point, not the whole picture. Once you've triaged what it finds, Phase 2 validates whether the stories themselves are still accurate, catching duplicate or stale requirements, and Phase 3 scores the code quality behind each story across complexity, security, test coverage, and documentation. Running all three in sequence turns a single gap audit into a full picture of what's built, what's missing, and how safe what's built actually is to ship. 

A Worked Example 

Say your backlog has a story: "users can export their order history as a CSV." Phase 1 runs, and the result comes back Incomplete at 88 percent confidence, with a linked snippet showing an export function that handles the CSV generation but has no route or button wired up to trigger it from the UI. Without a gap audit, that story likely gets marked done because the underlying function exists and passes a quick manual check, until a user actually tries to find the export button and can't. With the audit, the gap is visible before it ships: the code exists, but the acceptance criteria, a user being able to trigger the export, isn't actually met. 

That's the pattern gap audits are built to catch, code that's real and even correct in isolation, but doesn't add up to the requirement it was supposed to satisfy. A Missing result is an obvious gap. An Incomplete result like this one is the kind that's easy to miss without something explicitly checking the code against the criteria rather than just checking that the code exists. 

What a Good vs. a Bad Result Looks Like 

A healthy gap audit result on an actively maintained project usually shows a small number of Incomplete or Outdated stories clustered around recently changed requirements, and very few or no high-confidence Missing results. That pattern means the team's implementation is mostly keeping pace with its requirements, with normal drift at the edges. 

A concerning result looks different: a cluster of high-confidence Missing stories, especially on older tickets that were presumably closed out sprints ago, or a large number of Outdated results concentrated in one module. Either pattern usually points to a process gap rather than a one-off miss, stories getting marked done without implementation being verified, or a part of the codebase where requirements changed faster than anyone updated the code. 

Common First-Run Gotchas 

• Stories need to exist before code does, or at least alongside it. Running a gap audit on a repo with no connected stories has nothing to compare against. Connect your requirements source first. 

• Large, multi-repo projects take longer to analyze than a single small repo. Scale expectations to the size of what's being analyzed rather than assuming every run behaves like a demo on a small sample project. 

• A Missing result doesn't always mean nobody did the work. Check for implementations in a repo that wasn't connected, or in a branch that hasn't merged yet, before treating every Missing flag as a dropped ticket. 

• Vague acceptance criteria produce vague gap results. A story with a one-line description gives the semantic comparison very little to work with, which shows up as lower confidence scores across the board. Tightening acceptance criteria before your next audit run tends to sharpen the results more than any setting inside the tool itself. 

Start your audit: run a gap audit on your own repo, or book a demo to see it walked through on a sample project first. For the traceability side of this same picture, see what requirements traceability actually connects.