Hunting Ghosts: How to See What Developers Really Contribute

“Ghost engineers”—one in ten developers does almost no useful work, merely putting on a convincing show of being busy. The real reasons for that inactivity—moonlighting, burnout, or plain old slacking—can remain hidden from management for a very long time. (2024 Stanford study: original thread)

Developers don’t like it when their performance comes up. After a long “golden age” for the profession, the industry developed a taboo around one simple question: does the engineering output justify the time and money invested in it? But developers are just as frustrated by ghost engineers—and it is usually the team, not management, that notices the problem first.

Here in Russia, there is a long-standing aversion to “snitching.” So plenty of people may know there is a problem, yet no one wants to say anything. Why get dragged into someone else’s mess? It all comes out only when everyone’s patience has already run out.

But maybe we should just let them be—these ghosts. After all, it’s not as if the company will miss the money.

But here’s the catch…

When I say low performance, I don’t mean Alex is working away, sweating over the task, and getting 10% less done than Ben. I mean something else: at every stand-up, the whole team has to sit through the latest sob story—the other team let them down, the ticket was vague, the stars didn’t align. But tomorrow the task will definitely be done. Scout’s honor.

Except this “tomorrow” was already yesterday, and the day before—and by now it has become a tradition.

Teams notice this kind of thing quickly. The people actually carrying the workload naturally start to wonder: why work yourself into the ground if you can tell tall tales and face no consequences?

But noticing the problem isn’t enough. Without numbers and facts in hand, the conversation quickly turns into an argument: the team says, “They’re underperforming”; the developer replies, “They won’t let me do my job.” Usually, no one starts investigating until patience has already run out and the team asks the manager to replace the developer.

That is when the long saga begins: gather the facts, hear both sides, give the person feedback, and allow time for the situation to improve. In my experience, it most often ends with the ghost moving on to a new—and very lucky—employer.

The problem isn’t merely that one person does less. The company pays twice: first for work that never gets done, then for the time colleagues and managers spend double-checking, covering the gaps, and trying to understand why. In the end, it is no longer one developer underperforming. The whole team is.

Can a manager spot the problem earlier—notice the anomaly, ask for context, and investigate before the team runs out of patience and the company loses time and money?

With enough experience, you can often recognize these situations in advance from a few characteristic behavior patterns:

• Credit for every success is mine; blame for every failure is yours.
• Excuses for a task’s failure before work on it has even begun.
• Lack of competence compensated for with excessive talking.
• Over time, the manager in particular is cast as the “culprit.”
• Unlike someone who is genuinely struggling, this behavior does not improve even after direct feedback.

But suspicions need a digital trail.

Let’s look at the most common tools for measuring engineering performance and whether they can help uncover ghosts.

Before comparing them, I should state the obvious conflict of interest: you are reading the official DevGhost blog, and I am the product’s founder. This is an author’s perspective, not an independent study.

To assess software engineering itself—not the business or the product as a whole—I use a simple triad: speed, quality, and volume. DORA metrics tell us about speed; tests and defects tell us about quality. Volume is harder. This is the least well-trodden ground—and where the ghosts we are looking for tend to hide.

DORA: speed and release reliability

DORA shows how quickly and reliably a team gets changes into production. The model uses five metrics: time from commit to production, deployment frequency, the percentage of deployments that cause failures, time to recovery, and the share of unplanned rework.

It is a good measure of the delivery process, but not of individual contribution. If one person is doing the work of three while another hides behind the team’s overall result, DORA won’t tell you.

These metrics are also wonderfully convenient KPIs. At one company I worked for, we had been milking them since 2018—successfully painting every dashboard green while everyone stayed happy. The current DORA model.

Tests and defects: how well the work was done

The methods are well established and work in practice. Quality is controlled through code review, tests, and static analysis; the consequences are tracked through defects and incidents.

But these signals say nothing about volume. One tiny, flawless patch will turn every indicator green—and the ghost will remain invisible.

Jira and story points: how many tickets were closed

Jira shows closed tickets and story points, but the estimates come from the team itself. The same piece of work can be estimated at three points or thirteen, split into five tickets or bundled into one.

Story points are useful for planning, but unreliable as a measure of individual contribution. Once points become the target, people start optimizing for points.

They make convenient KPIs too. Data gets entered and tickets get moved around solely to clear quality gates. A great deal of pointless manual work.

Commits and lines of code: facts without context

Git does not depend on team estimates, so counting commits and lines is tempting. But five commits may represent one tiny patch, while a single squash commit may represent a week of work.

Formatting, generated code, copying, and moving code around all inflate the line count, while a difficult fix may be only ten lines long.

Swarmia, LinearB, and Waydev: the whole engineering system in one place

Swarmia, LinearB, and Waydev bring together Git, issue trackers, and CI/CD. Managers can see DORA metrics, review queues, change lead times, and survey results.

They provide a useful picture of the engineering system—and often reveal that the problem lies in the process rather than in a person. But measuring an individual developer’s volume of work on a comparable scale is not the central question these platforms try to answer. Swarmia, LinearB, Waydev.

GitClear: what remains after the code noise

GitClear distinguishes between added, moved, and copied code, excludes generated files, and accounts for whether new code was later rewritten or deleted.

That produces Diff Delta—GitClear’s own unit for meaningful changes that remain in the codebase. Copied code, or code that is quickly thrown away, carries less weight than a compact change that continues working in production. How Diff Delta works.

Diff Delta does not answer how much work was required. It answers how much meaningful change remained after the noise and rework. GitClear is strongest at measuring code durability and quality, and at analyzing AI’s impact.

Now we’re getting warmer. The service publishes benchmarks, but Diff Delta remains its own unit: a figure like 10,000 tells you little without the right comparison and an understanding of the methodology. There is no clear anchor such as “100% is normal.” Diff Delta benchmarks.

BlueOptima: the same question at enterprise scale

I know BlueOptima firsthand. I started working with the platform in 2019. That experience was what inspired me to build my own product.

The Coding Effort algorithm analyzes every source-code change using a set of static metrics, accounting for its size, complexity, and relationship to the rest of the code. It then expresses the result in hours.

This makes it possible to compare developers across teams and technology stacks, including against a global benchmark. For me, it was the first convincing attempt to answer not “How many lines did this developer write?” but “How much substantive work do these changes represent?” BlueOptima’s methodology, global benchmark.

In my case, getting those enterprise capabilities required a fairly heavy rollout: an agent had to be deployed inside a closed network environment, the price was high, and the results required expert interpretation.

For a company with thousands of developers, that may be justified. For a startup or small team, probably not. That gap later became one of the reasons DevGhost exists.

The same yardstick, without the RFP

When I built DevGhost, I wasn’t trying to create yet another all-in-one platform packed with every engineering metric imaginable.

I wanted the same answer BlueOptima provided—how much substantive work lies behind the changes—but in a form a startup owner or small team could use without an RFP, a lengthy rollout, or a team of consultants.

The logic is straightforward: DevGhost analyzes the changes themselves—what was added, deleted, and restructured, and how difficult the result was to create and verify. Formatting, code moves, bulk automated replacements, and generated code are separated from substantive work.

The result is an effort estimate expressed in equivalent hours: how long it would take a mid-level developer who knows the codebase and works without AI to write the same code. It is not the actual time spent at the keyboard, nor an assessment of the code’s quality or business value. It is a common yardstick for comparing changes. Learn more about the DevGhost methodology.

Ghost% compares that estimate with the expected output of a mid-level developer, accounting for how much of the person’s time is actually devoted to development. A result of 100% means they are in line with the norm. A lower result is a reason to investigate; a higher result is something worth studying and perhaps turning into best practice.

The benchmark deliberately assumes work without AI. DevGhost does not try to determine who wrote a particular piece of code—a person, Copilot, or an autonomous agent. It evaluates the final changes: how much effort a mid-level developer would have needed to create and verify them without AI.

That means the effect of AI does not disappear inside the metric. It becomes visible. If, during one period, a developer creates and verifies work that would previously have required two or three times as much effort, Ghost% reflects it. Formatting, bulk generation, and other forms of code noise should not produce the same effect.

Who judges the judge?

The most obvious question is: why should anyone trust a machine-generated estimate? The short answer is that no one should trust it blindly.

Assessing the difficulty of work is subjective by definition. We tested this by asking several experienced developers to estimate the same changes—and received noticeably different numbers. Everyone has a different pace, different experience, and a different sense of what is difficult.

DevGhost can be wrong too. Its advantage is not access to some absolute truth. Its advantage is that every change is assessed against the same yardstick—without favoritism, fatigue, or a pre-existing opinion of its author.

That is why Ghost% is a signal, not a verdict. A low result may indicate a weak contribution, but it may also be explained by team lead responsibilities, architecture work, mentoring, incidents, or blockers.

The number tells you where to ask a question. The manager still has to find the answer—but now they have an independent second opinion, rather than intuition alone.

“I already know how everyone on my team is doing”

One DevGhost client is the engineering leader of a fast-growing AI company. At first, he was skeptical of the very idea of measuring engineering performance. His position was simple: a good engineering leader already knows how everyone is doing without a dashboard.

We analyzed the history of a repository he knew well. There had already been concerns about three developers: their tickets were moving slowly, but they worked on a separate service, which made comparison with the rest of the team difficult. DevGhost showed consistently low results for all three over roughly six months.

Later, as the developers began to leave, it emerged that throughout that period they had also been building products of their own. DevGhost could not know the reason. It simply surfaced something that commit counts, pull requests, and daily conversations in Slack had failed to show: their volume of work was noticeably lower than expected.

But the analysis did not turn into a firing list. For two other developers, a low result made it possible to give specific feedback, investigate the causes, and improve performance. Both remained on the team.

The developers he considered strong also showed up exactly where he expected. And now he could see not only who was outperforming, but how consistently they were doing it.

One case, of course, does not prove that the method is accurate. What surprised the client was how closely the overall picture matched what had previously been known only at the level of intuition—and, in some cases, became obvious only in hindsight.

What if one developer delivers the output of three?

Hunting ghosts is the most attention-grabbing part of this story. But the top end of the chart may be more useful.

If a developer consistently delivers several times the average output, it is worth finding out exactly how they do it.

Today, the question is no longer whether a developer uses AI—for many people, it has become a normal part of the job. The question is how effectively they turn agents into additional delivery capacity.

One person stops at autocomplete. Another knows how to give agents the right context, define clear rules, run several tasks in parallel, and review the output carefully. The same access to AI can therefore produce radically different productivity gains.

A high Ghost% helps identify developers who are already getting strong results from that human-agent setup—and understand which practices the rest of the team could adopt.

If the high result is backed up by the quality of their work and their manager’s assessment, that developer should be valued, retained, and considered for promotion. Their practices should be studied and spread across the team.

Don’t turn the yardstick into a weapon

Every metric meets the same fate: sooner or later, someone tries to turn it into a KPI. Ghost% is not suited to that.

Make Ghost% a team KPI, and people will start optimizing their work around it. Publish a leaderboard, and trust will disappear. Turn the score into a firing button, and mistakes will become inevitable.

I would establish four rules:

• Don’t draw conclusions from a single measurement or a short period.
• Account for the person’s role, the share of their time devoted to development, and work that happens outside the code.
• Show the result to the developer and give them an opportunity to explain the context.
• Don’t use Ghost% as the sole basis for an employment decision.

If a low result persists, the manager should first investigate the reasons. Perhaps the person is genuinely struggling to perform. Or perhaps they are doing architecture work, dealing with other people’s incidents, or blocked by the team’s processes.

If the problem is confirmed, there should be a specific improvement plan and another assessment after an agreed period.

Rejecting metrics does not eliminate the evaluation of people. It simply leaves you with gut feelings, stories told at stand-ups, and the manager’s personal preferences.

Speed, quality, and volume require different tools. DORA shows how changes move into production. Tests and defects show quality. DevGhost adds an estimate of the work behind the code changes.

None of these metrics should make decisions for the manager.

The value of a number is not that it delivers a verdict. It is that a difficult conversation starts earlier—and is grounded in facts.

How do you assess the volume of developers’ work, and where do you draw the line between useful transparency and surveillance?