10x

Everyone loves the idea of the 10x engineer. The mythical developer who ships features ten times faster, writes code ten times cleaner, and somehow makes everyone around them look like they're standing still. It's Silicon Valley's favorite fairy tale, and for decades, it has shaped how we hire, how we measure ourselves, and how we justify absurd compensation packages. But here's the thing nobody wants to ask: 10x of what?

Where the number came from

The "10x" claim traces back to a 1968 study by Sackman, Erikson, and Grant, published in Communications of the ACM. They studied professional programmers with an average of seven years' experience and found that the ratio of initial coding time between the best and worst performers was about 20 to 1. Debugging times varied by over 25 to 1. Program size differed by 5 to 1. These are real numbers. But look at what they actually measured: coding speed, debugging time, program size, execution efficiency. They compared the absolute best to the absolute worst in a controlled setting, on isolated tasks, in 1968. No team dynamics. No product thinking. No system design. No communication overhead. Fred Brooks picked up on this research in The Mythical Man-Month, and the idea evolved. Over the decades, "some programmers are faster than others at isolated tasks" became "there exist superhuman engineers who are ten times more productive than their peers at everything." That's a massive leap. And it's one that most of the industry made without blinking.

The measurement problem

Productivity in software is notoriously hard to measure. Lines of code? The best solution often has fewer lines. Number of commits? Meaningless noise. Story points completed? Those are made-up numbers teams assign to made-up units of work. Steve McConnell, who literally wrote the book on software estimation, spent years examining the research behind the 10x claim. His conclusion was nuanced: yes, individual variation exists, but it depends enormously on what you measure, how you measure it, and the context in which the work happens. A developer who's "10x" in one environment might be average in another. The Carnegie Mellon Software Engineering Institute ran its own analysis and found that much of the observed variation in programmer productivity can be explained by factors outside the individual, like the tools they use, the codebase they work in, and the quality of requirements they receive. So when someone says "10x engineer," they're usually not making a scientific claim. They're telling a story. And that story serves a purpose.

Who benefits from the myth

The 10x narrative is incredibly useful, just not for the reasons you'd think. For companies, it justifies paying one person a lot instead of hiring three. For venture capitalists, it justifies betting on small teams with big ambitions. For individual engineers, it's aspirational, a status marker that separates the "real" engineers from the rest. But it also creates toxic dynamics. As one retired principal engineer put it after twelve years of hiring and mentoring, the mythology around the 10x engineer "destroys teams and creates the very problems it claims to solve." The brilliant jerk gets a pass because they're supposedly irreplaceable. Knowledge hoarding gets reframed as genius. Collaboration becomes secondary to individual output. Stack Overflow's engineering team wrote about this directly: "Single individuals make less of a difference to the success or failure of a technology project than you might think." The real 10x developer, they argued, is the one who makes their whole team better, not the lone genius cranking out code in a dark room.

Then AI entered the chat

When large language models started writing code, the 10x narrative got a second life. Suddenly every AI coding tool was promising to make every developer a 10x engineer. GitHub claimed 55% faster task completion with Copilot. Blog posts and Twitter threads declared that AI would finally democratize 10x productivity. The pitch was seductive: if 10x engineers exist but are rare, what if AI could make everyone 10x? What if the tool itself was the multiplier? But here's where reality gets uncomfortable. In July 2025, METR (a research nonprofit) published a randomized controlled trial, one of the first rigorous studies of AI's impact on experienced developer productivity. Sixteen developers with moderate AI experience completed 246 tasks in mature open-source projects where they had an average of five years of prior experience. Each task was randomly assigned to allow or disallow AI tools. The result? Developers using AI took 19% longer to complete their tasks. Not 10x faster. Not 2x faster. Slower. The kicker: before the study, developers predicted AI would speed them up by 24%. Even after completing the tasks, they still believed AI had made them 20% faster. The perception of speed was completely disconnected from the measured reality. This isn't an anti-AI finding. It's a finding about how badly we understand our own productivity, and how easily we confuse the feeling of being productive with actually being productive.

The perception trap

This gap between perceived and actual productivity is the real story. It's not unique to AI, and it's not unique to programming. We're drawn to metrics that feel good. AI tools generate code quickly, which creates a sense of momentum. But generating code isn't the bottleneck in most real software work. Understanding the problem is. Navigating a complex codebase is. Making architectural decisions that won't haunt you in six months is. When a developer uses AI to generate a solution, they still need to understand what was generated, verify it works correctly, and integrate it into the broader system. For experienced developers working in codebases they know deeply, this overhead can actually exceed the time saved by the generation itself. As one METR participant noted, the AI-generated code looked plausible but required careful review, and the review process was harder than writing the code from scratch would have been, because now you're debugging someone else's logic.

What actually matters

If the 10x framing is broken, what should we be measuring instead? The honest answer is that there's no single number. Productivity in knowledge work is multidimensional and contextual. But some things matter more than others: Reducing waste matters more than increasing speed. The biggest productivity gains in most teams don't come from writing code faster. They come from not writing the wrong code in the first place. Clear requirements, good communication, and short feedback loops prevent more wasted effort than any tool can recover. System thinking matters more than individual output. An engineer who designs a clean abstraction that saves five other engineers a week each has created more value than one who personally ships five features in a sprint. But that kind of contribution is invisible if you're counting commits. Consistency matters more than peaks. A developer who reliably delivers solid work every week is more valuable than one who has occasional bursts of genius separated by weeks of debugging their own clever code. The 10x framing celebrates peaks while ignoring the variance. Learning speed matters more than current skill. The technology landscape shifts constantly. The ability to learn a new domain, adopt a new tool effectively, or rethink an approach when assumptions change is worth more than raw coding speed on a familiar stack.

The honest conversation

The 10x myth persists because it's a simple story in a field that resists simple stories. Software is complex, teams are complex, and measuring human contribution is genuinely hard. "Some people are way better than others" is easier to believe, and easier to act on, than "productivity is an emergent property of systems, teams, and contexts." But the AI era is forcing the conversation. When the industry's biggest promise is "we'll make everyone 10x," and the best available evidence shows that's not happening, we have to reckon with the underlying assumption. Maybe the question was never "how do we find or create 10x engineers." Maybe the question is: why are we so desperate for a single number to describe something that can't be reduced to one?

References