What are ghost engineers?
Engineering culture and software practice
Ghost engineers is a contested label from 2024 research by Yegor Denisov-Blanch and colleagues at Stanford University for software engineers whose measured contribution to a codebase is close to zero. Circulated first through a social-media thread, it claimed that roughly one in ten engineers do almost no work. That figure drew heavy criticism of its method, so the term is best treated as an argument about measuring engineering work rather than as an established finding.
What this means
A ghost engineer, in the sense the term acquired in late 2024, is someone on an engineering payroll whose recorded activity in the code, chiefly the commits they make, is so low that the researchers behind the claim treated them as producing almost nothing. The word is deliberately vivid: it suggests a person who is present on the org chart but absent from the work.
The idea travelled fast because it married a familiar suspicion, that some people coast, to an apparently precise number. It is important to separate two things. There is the reasonable question of whether an organisation is staffed as it thinks it is. And there is the specific, disputed answer offered by the research: that a fixed share of engineers can be identified as near-idle by analysing their code activity.
The term has a name because it names a measurement argument, not because a phenomenon has been settled. Whether ghost engineers exist as described depends entirely on whether commit-based measurement sees what its proponents say it sees.
Why it matters
Any organisation that employs or contracts software engineers eventually wants to know whether it is getting value. That is legitimate. The danger is reaching for a single, tidy proxy and treating it as truth. The ghost-engineer framing is attractive precisely because it promises a clean percentage, and clean percentages travel into board decks and redundancy plans.
The practical stakes are highest when a proxy metric is used to rank or remove individuals. Commit counts and similar activity data miss a great deal of real engineering: code review, mentoring, incident response, design, architecture and the coordination that keeps a team moving. A senior engineer who unblocks five colleagues a day may commit little themselves. Penalising that pattern damages the very work that holds a team together.
The arrival of AI-assisted coding makes commit-based measurement even less reliable. When a tool can generate hundreds of lines in seconds, volume decouples further from effort and value, and the reviewing, prompting and checking work that AI shifts onto people is largely invisible to a commit log. A measure that was already weak becomes weaker.
There is also an employment-practice dimension. Measuring individuals, and acting on those measurements, carries obligations that vary by jurisdiction and contract. This article does not advise on those obligations; it simply flags that individual measurement is not a neutral technical act.
How it works
Where the term came from
The phrase entered wide circulation on 20 November 2024, when Yegor Denisov-Blanch, a researcher at Stanford University, posted a social-media thread stating that around 9.5 per cent of software engineers do, in his words, virtually nothing, and calling them ghost engineers. Because that thread sits on a blocked platform, the institutional record matters more: the research group is the Software Engineering Productivity project, and the peer-reviewed component is a September 2024 Stanford working paper and arXiv preprint, Predicting Expert Evaluations in Software Code Reviews, by Denisov-Blanch, Ciobanu, Obstbaum and Kosinski.
It is essential to be precise about what has and has not been published. The arXiv paper describes a model that estimates coding time, implementation time and complexity from commits, calibrated against ten expert raters who assessed 70 commits from 18 authors, producing 4,900 judgements. It reports strong correlation with human judgement on time (r values of 0.82 and 0.86) and weak correlation on maintainability (0.30). That paper never states the 9.5 per cent figure. The ghost-engineer statistic, and the related claim that the share rises among fully remote engineers, was presented in talks such as the DPE Summit in 2024 and amplified through the thread and the press, including the Washington Post. As of 2026 the headline percentage does not appear in a peer-reviewed publication, so there is no formal correction or retraction to report; it simply remains an unpublished working claim.
What the method can and cannot see
The underlying technique analyses source code changes and scores them, aiming to move past crude counts like lines of code. That is a genuine improvement on counting keystrokes. But it remains anchored in what lands in version control. It can see the shape and size of commits. It cannot see a well-run incident bridge, a design decision taken in a meeting, an afternoon spent pairing with a struggling colleague, or the review comment that prevented an outage. The ACM Queue paper that introduced the SPACE framework makes the point plainly: developer productivity cannot be measured by a single metric or dimension, and much valuable work is invisible to activity metrics.
The objections, in full
The criticism is substantial and comes from several directions. First, the calibration set is small: a model tuned on 70 commits assessed by ten raters is a slim basis for claims about tens of thousands of engineers. Second, the companies that connected their repositories were invited and opted in, which risks selection bias. Third, the model itself performs weakly on the more subjective dimensions such as maintainability, where the raters also disagreed with one another. Fourth, and most fundamental, low commit activity is not the same as low contribution; the two are conflated when a near-zero score is read as near-zero value. Critics also note that the headline figure was publicised ahead of peer review of any paper that contains it.
Why the framing spread
The claim spread because it is emotionally satisfying and numerically crisp. It arrived during a period of tech-sector layoffs and public argument about remote work, and it was reshared by high-profile figures. A striking statistic that confirms an existing suspicion needs little help to travel. None of that makes it wrong; none of it makes it right. Speed of spread is not evidence of validity.
The legitimate question underneath
Underneath the noise is a fair question: is our engineering effort going where we think it is? Good practice answers that with a balanced set of measures rather than one proxy. The SPACE framework recommends looking across several dimensions at once, including satisfaction, performance, activity, collaboration and flow, and pairing system data with what people report. Professional bodies that study performance management, such as the CIPD, stress that measurement should support development and be tied to agreed objectives, not reduced to a single ranking number.
Examples
Consider a professional services firm with a small internal development team building client portals. A director reads about ghost engineers and asks for a commit league table. The team lead points out that the two lowest committers are the person who runs the on-call rota and resolves incidents, and the person who does most of the code review. On the proposed metric, the two most load-bearing people look idle. The firm drops the league-table idea and instead asks each engineer what slows them down.
A mid-sized retailer has adopted an AI coding assistant across its web team. Commit volumes jump, and a manager wonders whether this proves some prior underperformance. On inspection, the extra volume is largely generated boilerplate that now needs careful human review. The real change is a shift of effort from writing to checking, which the commit graph flatters rather than measures. The manager abandons the volume comparison.
A charity with a two-person data team is asked by a trustee whether it is over-staffed, citing the one-in-ten figure. The team explains that most of their week is data cleaning, stakeholder conversations and documentation, little of which touches a code repository. The trustee accepts that a proxy designed for large commercial repositories tells them almost nothing about a two-person charity team.
Common misunderstandings
The first misconception is that the 9.5 per cent figure is a peer-reviewed finding. It is not. The peer-reviewed paper describes a code-review model and does not contain the statistic; the figure came from a social-media thread and conference talks and remains unpublished in that form.
The second is that a low commit count means a person is not working. It means their work is not showing up as commits. Review, mentoring, incident response, design and coordination all leave little trace in a commit log.
The third is that ghost engineers are the same idea as the 10x engineer, just inverted. This term is not simply the mirror of the 10x engineer. The 10x-engineer claim is about extraordinary individual output; the ghost-engineer claim is about measuring the absence of it. Both stumble on the same rock, which is that individual code activity is a poor proxy for individual value, but they are different arguments and should not be collapsed into one.
The fourth is that AI coding tools make measurement easier by producing more countable output. They make it harder, because volume decouples further from effort and the human work shifts to reviewing and directing the tool.
The fifth is that naming a pattern proves it exists at the stated scale. A vivid label and a precise-sounding number are rhetorical strengths, not evidence.
Risks and boundaries
The main risk is Goodhart's law in action: the moment a proxy such as commit activity becomes a target, people optimise the proxy rather than the work, and the measure stops meaning what it did. Splitting commits, padding trivial changes and avoiding invisible team work all become rational responses to a bad metric.
The term is misapplied whenever it is used to describe or rank named individuals on the basis of activity data alone. It does not cover the many legitimate reasons a person's commit trace is thin in a given period, from parental leave to a quarter spent on architecture or incident work. The folklore outruns the evidence when a disputed, unpublished percentage is presented as a settled fact about a workforce.
The live debate is genuine and unresolved. Proponents argue that analysing code downstream reveals real patterns that intuition misses. Critics argue the method cannot see most of the job and that publicising individual-level conclusions before peer review is irresponsible. A careful reader should hold both positions in view rather than adopt one.
What to do next
Start by separating the question from the answer. If the real worry is staffing or delivery, say so, and resist the pull of a single percentage that promises to settle it.
Measure across several dimensions rather than one. Combine delivery signals, such as how reliably work reaches production, with what engineers report about friction and flow, following the balanced approach set out in the SPACE literature. No single number should decide anything about a person.
Ask teams directly what slows them down. The most valuable information about wasted effort usually comes from the people doing the work, not from their commit graphs.
Treat any individual-level measurement with caution and get proper advice before acting on it. Measuring people carries obligations that differ by jurisdiction and contract, and this is a matter for qualified HR and legal input rather than a metric dashboard.
Where AI tools are in use, expect commit-based measures to become less informative, not more, and plan to measure the review and direction work that AI creates.
FAQs
Who coined the term ghost engineer?
It was popularised by Yegor Denisov-Blanch, a researcher at Stanford University, in a social-media thread on 20 November 2024, drawing on the group's software-productivity research.
What exactly did the research claim?
The widely shared claim was that around 9.5 per cent of software engineers produce almost nothing, measured as less than a tenth of a median engineer's output, with a higher share among fully remote staff.
Is that claim peer-reviewed?
No. The related peer-reviewed paper covers a code-review scoring model and does not contain the figure. As of 2026 the percentage remains an unpublished working claim.
Why do critics object so strongly?
Because the model was calibrated on a small sample, the participating companies opted in, it performs weakly on subjective measures, and low commit activity is not the same as low contribution.
Does this mean nobody underperforms?
No. Underperformance exists, but it is a management question best handled through direct observation and balanced measures, not through a single activity proxy.
How does AI change the picture?
AI-assisted coding inflates code volume while shifting human effort to reviewing and directing the tool, making commit-based measurement even less reliable.
What should we measure instead?
Use several dimensions together, pairing delivery signals with what engineers report, and tie any measurement to agreed objectives rather than a ranking.