Velocity
See whether your engineering team is getting faster in ways that hold up through review, and what AI changes about the work.
Velocity shows whether your engineering team is getting faster in ways that survive review, tests, deploys, and customer use. It answers the questions engineering leaders get asked most: how much is the team shipping, where does work wait, and is AI actually helping? It builds all of it from your source control history, so nobody has to track anything by hand.
Velocity reads from GitHub or GitLab. Connecting one takes the right permissions, so if you cannot, ask an admin.
Connect your source control
Step 1: Connect GitHub or GitLab
Open Velocity and choose GitHub or GitLab. You can also connect from Org Settings, then Integrations.
Step 2: Choose which repositories to sync
Pick the repositories Velocity should read. Nothing syncs until at least one is chosen. To change the list later, open the menu at the right end of the controls and choose Configure.
Step 3: Wait for the first sync
Proxon fetches your recent history first, then keeps reaching further back. The page fills in once the first sync finishes. An organization with many repositories can take a day or more to sync completely.
Each date range needs twice its length in history, because every figure is compared with the period before it. A range you cannot pick yet unlocks on its own as more history arrives.
Step 4: Map authors to people
From the same menu, choose Map people to match source control accounts to people on your Proxon roster. This is what lets Velocity show output by engineer and by team.
Focus on the work you care about
Every figure on the page answers to the controls at the top. Narrow the view to particular repositories, departments, or teams, and look back over the last 7, 14, 30, 60, or 90 days by day, week, or month. Velocity counts people and AI agents such as Devin by default and leaves out bots such as Dependabot, so routine dependency updates do not pad the numbers. You can add bots back in when you want the full picture.
Output that rewards reviewed work
A count of pull requests or lines of code rewards the wrong things. Velocity measures output instead, a normalized unit of engineering work that compares fairly across people, languages, and repositories.
Each merged pull request earns its changed lines (additions plus deletions), capped at 2,000 so one large refactor cannot dominate. That figure is multiplied by 1.25 when the pull request earned an approving review, so work that survived peer review counts for more. The results are added up per engineer, per team, or per time period.
The Overview report
Overview opens on what is worth acting on. Insight cards point out patterns such as a stage of the cycle that slowed down or a person whose results others could learn from. Open a card to see the people it names.
Output shows how much got built and how it compares. Headline figures track output, pull requests merged, and reviews submitted, each against the previous period. Output over time adds dashed lines for the median and top 10% of teams your size, so you can see where you stand. Split the same work by type to see how much went to features and how much to bug fixes, or by AI tool to see which tools are pulling their weight. Rankings show your top engineers and teams, and a separate chart shows how much output came from AI agents and bots.
Cycle time shows where work waits. It follows each change from the moment an issue is started, through the first commit, the pull request, the first review, and approval, with the typical time each step takes. Review turnaround shows how long a pull request waits for its first review, and flow efficiency shows how much of the elapsed time the work was actually moving.
The first step of the cycle and flow efficiency need a work tracker such as Jira or Linear. Without one, the rest of Cycle time still works from source control alone.
AI in each repository shows which AI tools work where and how their work holds up. Merged with AI is the share of merged output an AI tool helped with. Opened by a bot or agent counts the merged pull requests an automated account opened. AI work sent back is the share of reviewed AI pull requests that a reviewer sent back for changes. The section also shows which repositories carry a rule file that tells AI tools how to work there. A busy repository without one is an easy place to improve.
Metrics puts every measure in one table, from the whole organization down to each person. Expand a row to go a level deeper, and sort by any column. Each row counts the people beneath it once, so a person on two teams never inflates the organization's total. The table fills in once source control authors are mapped to people on your roster.
The AI impact report
AI impact answers the question behind every AI investment: does it make the team faster without making the work worse? It compares your team's work with AI against the same team's work without it.
Five headline figures lead the report. The charts below them track pull requests opened, merge frequency, and code changes over time, each split between With AI and Without AI. Two more charts watch quality: the typical pull request size, and the share of pull requests merged without a review from anyone other than the author.
Click any point on a chart to open the pull requests behind it.
How Proxon decides work used AI
Proxon counts a pull request as AI work when one of its commits names an AI tool as a co-author, the way tools such as Claude Code mark the commits they help write. Treat the result as a floor rather than a full count. A tool that does not mark its commits is not seen, so the real share of AI work can be higher than the page shows.