For Engineers
GitVelocity scores every PR you merge. If you are wondering what those numbers mean and how to think about them, this page is for you.
The short version: your score measures the complexity of the code you shipped. It does not measure your skill, your value, or how hard you worked.
Understand What Your Score Measures
Each PR gets a score from 0 to 100 based on six dimensions: Scope, Architecture, Implementation, Risk, Quality, and Performance/Security. These dimensions evaluate the complexity of the change itself -- how many systems it touches, how much design judgment it required, how much risk it introduced.
The score is then adjusted by the Effort Scale Factor (ESF), which accounts for the size of the PR in lines and files changed. The result is a Final Score that represents the total complexity of what shipped.
A high score means the PR was complex. A low score means it was simple. Neither is inherently good or bad.
A Low Score Does Not Mean Bad Work
A score of 8 means the PR was small and straightforward. That is often exactly what it should be. A well-scoped bug fix, a config change, a dependency update -- these are low-complexity by nature, and scoring them low is the system working correctly.
In fact, we actively encourage low-scoring PRs. Big PRs are scary -- they carry higher risk, are harder to review, and are more likely to introduce regressions. Small, focused changes are easier to review, safer to deploy, and faster to ship. The best engineering teams ship a high volume of small, well-scoped PRs.
The real power of low-score work shows up at scale. An engineer consistently shipping many small PRs in parallel -- bug fixes, improvements, focused features -- accumulates significant total velocity. That consistency is more valuable than occasional high-score spikes. Volume and consistency matter more than any single PR score.
If every PR you submit is a 50+, that might actually indicate a problem with how work is being scoped. The healthiest engineering patterns tend to show a mix of scores, weighted toward the lower end, with complexity spread across many well-defined changes.
Use Your Profile to Demonstrate Impact
Your GitVelocity profile provides an objective record of the work you have shipped over time. This is useful in several contexts:
- Performance reviews -- show the complexity and volume of your contributions with data, not just narratives
- Promotion cases -- demonstrate a trend of increasing complexity as you take on harder problems
- Team transitions -- give a new manager concrete evidence of your recent work
The data speaks for itself. Instead of arguing that a project was hard, you can point to the scores and let the numbers back up the story.
Leverage AI Tools Effectively
GitVelocity scores the complexity of what ships, not how it was written. Code written with AI assistance is scored identically to hand-written code. This means you can use AI tools to handle boilerplate, tests, and routine implementation while you focus on the work that actually drives complexity: architecture decisions, system design, and cross-cutting concerns.
Engineers who use AI tools effectively tend to show a specific pattern in GitVelocity: their PR volume increases while their average complexity stays the same or goes up. They are not shipping more trivial code -- they are shipping more complex code by offloading the routine parts.
Scores Increase Naturally With Harder Problems
As you grow as an engineer, you take on work that touches more systems, requires more design judgment, and carries more risk. That progression shows up in your GitVelocity scores without you doing anything deliberate to change them.
Junior engineers working on well-scoped tasks will naturally see lower scores. Senior engineers designing cross-service features will naturally see higher ones. This is the system reflecting reality, not a ladder to climb.
Do Not Optimize for Score
If you find yourself thinking "how do I make this PR score higher," stop. The score is a measurement, not a goal. Artificially inflating your PRs -- combining unrelated changes, adding unnecessary complexity, or avoiding small focused fixes -- makes your code worse and your team slower.
Ship the right code in the right way. The scores will follow.
Keep Perspective
Velocity scores can be motivating -- it feels great to see your output quantified and recognized. But remember that scores measure one dimension of your work. They capture what ships to production, not the design thinking, code reviews, mentoring, architectural discussions, and collaboration that make you a complete engineer.
Be mindful of cognitive overload. AI tools let you move faster, but there is a real limit to how many concurrent workstreams you can manage effectively. Parallelization is powerful, but more is not always better.
If you find yourself optimizing for score at the expense of code quality, team dynamics, or your own wellbeing, step back. That is not what GitVelocity is designed to encourage. The best engineers ship consistently AND invest in the less visible work that makes teams successful.