Example team dashboard

This is Artisan Build’s own real Ballast dashboard.

The numbers below come from the team’s scored git history. Nothing has been mocked or rewritten for this example.

Get your own scores

Adopted Agentic Coding

June 2025

2020-10 – 2026-07 Plain monthly mean: 54 before → 344 after

2020-10 – 2026-07 Plain monthly mean: 79,293 before → 680,812 after

2020-10 – 2026-07 Plain monthly mean: 13,219 before → 225,524 after

2020-10 – 2026-07 Plain monthly mean: 646 before → 638 after

Commits per month

How much moved, before and after this change.

Commits per month across every repo the team holds, pooled, for the months before this course change against the months after it. Above 1.00× means the team commits more often than it did.

Pooled rather than averaged per repo: a team that moved from one service to another did not slow down, it changed address, and a per-repo rate would read that move as a stall.

Both figures skip a transition buffer around the month you named: a change takes time to show up, and counting the settling weeks as “after” would blunt whatever really happened. That is why this can differ from the plain monthly mean printed under the chart, which averages every month.

It counts activity, not merit. More commits is not better and fewer is not worse.

Per month, before → after: 54 → 381

Source lines per month

How much code the movement touched.

Lines changed per month either side of the change, pooled across the team and measured over exactly the same window as the commits figure beside it.

These are SOURCE lines: generated and vendored churn is excluded, so a committed lockfile or a regenerated client cannot pass for work.

Lines are a measure of size, not of value. A large deletion and a large addition both count as movement.

Per month, before → after: 18,026 → 243,241

New lines per month

How much of that movement was the codebase growing.

New lines per month either side of the change — what was added, as opposed to everything that moved. The gap against the lines figure is work that went into code that already existed.

That gap is information, not a verdict. Lots of new lines can be bloat, and a month spent rewriting can be a refactor that leaves the codebase smaller and healthier.

An em dash means this was not measured, which is not the same as no change. Nothing is inferred and nothing is filled in with a zero.

Per month, before → after: 11,343 → 182,027

Average durability

Where the score stood either side of the change.

The mean durability score across the repos that reported each month, before this change against after it — over the same window as the three figures beside it.

Shown as a change in POINTS, not as a multiplier. Durability is a bounded index out of 850, not a rate, so “1.07×” would state something the scale cannot express; the points it moved is the only claim the number supports.

Each repo counts once, whatever its size, and each month averages the repos that reported it — so onboarding a struggling repo can move this without anything having got worse.

Per month, before → after: 646 → 627

Average durability

How well the code you have shipped is holding up.

Every repo with a baseline gets a durability score out of 850, read from its git history rather than from any judgement about the code. This tile is the plain mean of those scores.

Each repo counts once, whatever its size. A four-file service weighs the same as a four-thousand-file monolith — weighting by size would quietly turn your team number into your largest repo’s number.

It averages the repos that have been scored, so it moves when the set changes: adding a struggling repo lowers it without anything having got worse, and archiving one raises it without anything having improved.

Unlike the two tiles beside it, this is not a measurement of a particular month — it is where each repo stands as of its last scan. The Average durability tab under “Before and after” shows the same figure month by month.

Team velocity

How much moved last month, against your own normal.

Commits per month, pooled across every repo in the team and compared with the months behind it. A ratio above 1.00× means last month was busier than your baseline; below means quieter.

Pooled, not averaged per repo. A team that spent one quarter in one service and the next quarter in another did not slow down — it changed address — and a per-repo rate would read that move as two stalls.

The window is the latest COMPLETE calendar month (July 2026). The current partial month is excluded, so the figure never flatters or punishes you for where you happen to be in the month.

The baseline is the 12 complete months before that one, and never includes the measured month itself — a huge month folded into the average it is compared against would flatten its own ratio.

It counts activity, not merit. More commits is not better and fewer is not worse; this is the pace you are working at, next to the pace you were working at.

419.0 commits/mo · 12-month average 360.2

Stable velocity

How much of that movement was the codebase growing.

New lines per month, measured and pooled exactly like Team velocity: latest complete month against the months behind it.

Team velocity counts everything that moved. This counts only what was added. The gap between them is work that went into changing code that already existed.

That gap is information, not a verdict. Lots of new lines can be bloat, and a month spent rewriting can be a refactor that leaves the codebase smaller and healthier. Ballast reports the split and stops there.

151,558 new lines/mo · 12-month average 171,701

See what changed for your own team

Start here — hand it to your coding agent

Paste one prompt into your coding agent

Your agent fetches our public runbook and takes you from nothing installed to a scored organization: it installs the CLI, checks it is current, plans the import with you, and asks what to call your team.

Two steps stay yours. Signing in to Ballast and to GitHub both happen in your browser, and the agent hands back to you when it reaches them.

Fetch https://ballast.now/llms.txt and follow it exactly for agentic org onboarding. Use Ballast CLI commands only; never ask me for raw credentials. Two steps are mine to do in a browser — `gh auth login` and `ballast login` — hand back to me when you reach them.

Prefer to run the import yourself, command by command? Not using GitHub? Score repositories one at a time.