How DevGhost assesses developer productivity
Updated October 23, 2026
DevGhost independently assesses each developer’s productivity from the content and cognitive complexity of their Git changes. Business owners and CTOs can see the return on their investment in development: identify persistently low contributions and recognize strong developers whose work has gone unnoticed.
The size of a change is not the amount of work
Adding a ready-made library can take a few minutes and produce thousands of added lines. Yet a small behavior change across a few files may require understanding dependencies, designing a solution, and checking it carefully. DevGhost estimates the engineering work behind a change, so visible activity does not stand in for contribution.
Machine learning grounded in code
DevGhost combines machine learning and its own neural network with structural analysis of Git changes and specialized algorithms. Together, they estimate cognitive effort on a common reference-developer scale.
DevGhost does not use LLMs to analyze code. Its own trained models and algorithms calculate the estimate.
- Changes are considered in the context of existing code, including relationships between changed parts and evidence of reuse.
- Recognized mechanical changes and generated artifacts are handled separately so their volume does not stand in for new engineering work.
- Substantive AI-assisted code is assessed on the same scale. What matters is the result represented in the code.
Two changes, different work
These public commits show why diff size alone is not enough to assess contribution.
k6: ready-made React files for tests
The change adds more than 33,000 lines, mostly ready-made React files, so tests no longer depend on unreliable network access. DevGhost separates the supplied files from the work needed to integrate them. DevGhost’s estimate: about 0.8 reference hours.
View the public commitRedis: asynchronous I/O
About 2,300 added and deleted lines change how Redis threads interact: handling network events, passing work between threads, and synchronizing access to data. This is a substantive architectural change that requires several parts of the system to work together correctly. DevGhost’s estimate: about 23 reference hours.
View the public commitWhat reference hours mean
The reference is a mid-level developer with 3–4 years of experience who knows the project and works without AI. The estimate covers the work they would need to understand the relevant code, design and implement a solution, check it, and make the necessary corrections. Self-testing is included: running appropriate tests and interpreting their results, manually checking behavior when needed, and reviewing their own change before finishing.
A common scale lets you compare developers’ contributions and observe how they change over time. Reference hours describe the estimated work represented in the code, not the time the author actually spent.
From reference hours to Ghost%
The distribution of estimates over time is based on empirical research and practical measurements. DevGhost uses a common reference scale to compare results. Ghost% shows output relative to the baseline, accounting for Share and the selected day-counting method. At 100%, output matches the baseline; above 100%, it exceeds it. AI assistance may be one reason, but the number alone does not prove AI use.
Consider the context
Look at sustained results across several periods, then examine the changes and the person’s responsibilities. DevGhost does not measure actual hours, code quality, or a developer’s full professional value. Work outside the analyzed changes matters too. Employment decisions require an independent, substantive human assessment; Ghost% must not be their sole or primary basis.
Check the history of a project you know
Choose a repository and a period whose team results you know well. Compare DevGhost’s assessment with your experience: who made a strong contribution, where development consistently fell short of expectations, and which difficult tasks went unnoticed in activity statistics. Open individual changes and examine both matches and discrepancies. This lets you judge how useful the system is for your management decisions using work you already know.