Ask an engineering leader how well tested their codebase is and you’ll usually get a pause. The number exists, but it’s scattered across pipelines, repositories and pages. CodeAnt AI has tracked test coverage per repository for a while. Today it adds the view leaders have been asking for: coverage across the whole organization, on one page.
This post walks through both. First, how code coverage works in CodeAnt AI. Then the new Organization Coverage view, which is the part worth your attention. To show it with real-looking data, we’ll use a fictional company, Northwind Labs, with 12 repositories.
Part 1: Code coverage in CodeAnt AI
It starts in the pipeline you already run
Your tests already produce a coverage report. CodeAnt AI reads it. Add one step to your CI that uploads the report, and coverage starts showing up for that repository. It works with GitHub Actions, GitLab CI/CD, Azure Pipelines, Bitbucket Pipelines, Jenkins and CircleCI, using Cobertura or JaCoCo XML.
Every new push to the branch gets a coverage check, and the result is linked to the pull request. In a monorepo, each module can upload its own report and is tracked separately, so the frontend’s number never hides the backend’s.
Each repository gets its own history
Open Code Quality, then Coverage, and pick a repository. You see its latest coverage, how it changed over the date range, and a trend of every upload. A branch selector lets you look at main or any other branch, and the Commits tab lists every commit that uploaded coverage.
Down to the exact line
Open any upload’s report to see coverage file by file. Lines your tests ran are green. Lines they never touched are red.
That’s where a refund bug would hide, and now you can see it before it ships.
The catch: one repository at a time
All of this worked well for a team that owns one service. It didn’t work for the people who answer for the whole codebase. With fifty repositories, the org-wide answer meant opening fifty pages and building a spreadsheet. There was no single number, no org-wide trend, and repositories that never uploaded coverage didn’t show up anywhere. Those are often the riskiest ones.
Part 2 · New: Organization Coverage, your whole org on one page
The new Organization Coverage view puts every repository’s coverage on one page. Open Code Quality, then Coverage, and pick Organization · all repositories from the repository selector.
Three numbers that answer the first question
9 of 12 repositories report coverage; 57.6% of lines are covered; coverage is up 9.2 points in 30 days.
Repositories. 9 of Northwind’s 12 repositories send coverage. That’s the first thing a leader needs to know, before trusting any percentage.
Organization Coverage. 216,872 of 376,370 lines are covered by tests: 57.6%. It’s covered lines over total lines, so every line counts the same.
Coverage Trend. Up 9.2 points since 16 September. Whatever the team did this month is working.
Why line-weighting matters
A simple average of Northwind’s nine repositories would say 59.4%. The real figure is lower, because one repository is big and barely tested. legacy-billing has 71,930 lines, about a fifth of the codebase, and only 22.5% of them are covered.
Legacy-billing: 22.5% covered across 71,930 lines, with every folder in amber or red.
Leave it out and the rest of the org sits near 66%. That’s exactly what a leader needs to see: the biggest risk isn’t spread evenly, it’s concentrated in one service.
The trend, day by day
Organization coverage by day, 16 September to 15 October: from 48.4% to 57.6%.
Pick any range from Today to This quarter. The chart shows org coverage for each day, so a drop after a big merge or a jump after a testing push is easy to spot.
Date range presets, from Today to This quarter.
Every repository, side by side
Coverage, covered and total lines, latest upload, branch and change for all 12 repositories.
The table lists every repository with its coverage, lines, latest upload, branch and change since the previous upload. At Northwind, notifications gained 3.1 points while data-pipeline lost 1.8. Both are visible at a glance.
Sort by coverage, by latest upload to find stale reports, or by name. Click any repository to open its own coverage history from Part 1, with the same dates.
Sort by coverage, latest upload or repository name.
The gaps, out in the open
Three Northwind repositories upload no coverage, each with a Setup guide link.
admin-portal, ml-recommendations and infra-terraform send no coverage at all. Before, they simply didn’t appear anywhere. Now they sit in the same table, marked “No coverage”, with a link straight to the setup guide.
Who it’s for
Engineering leaders get one number to report, a trend to show progress, and a clear place to invest.
Platform and DevEx teams see which repositories aren’t reporting coverage and can fix the CI setup.
Team leads see how their services compare and whether their tests are keeping up.
Everyone sees only the repositories they already have access to.
Why it matters
Code quality is easier to improve when you can see it. Repository coverage tells a team how they’re doing and where the untested lines are. Organization coverage tells leaders where to invest, and whether last quarter’s push actually moved the number. Together with AI code review on every pull request, it gives engineering one place to see how healthy the codebase really is.
Get started
Already uploading coverage? Open Code Quality, then Coverage, and choose Organization · all repositories. Not yet? Set up uploads for GitHub Actions, GitLab CI/CD, Azure Pipelines, Bitbucket Pipelines, Jenkins or CircleCI.
Northwind Labs, its repositories and all numbers in this post are fictional examples.
