It's time to bury the "10x engineer"
The term was always a simplification. In 2026, with AI vendors reviving it to sell productivity tools, it has become actively harmful.
👋 Hi, I’m Thomas. Welcome to a new edition of Beyond Runtime, where I dive into the messy, fascinating world of distributed systems, debugging, AI, and system design. All through the lens of a CTO with 20+ years in the backend trenches.
QUOTE OF THE WEEK:
“[the term] can glorify solo heroics over team culture and systems mechanics, and has been used to justify toxic behavior, poor documentation, and knowledge hoarding.” - Prashanthi Padmanabhan, VP of engineering at LinkedIn Talent Solutions
I recently wrote about “shift left” a phrase that started as genuine advice and quietly became a substitute for the hard work it was supposed to describe. The “10x engineer” term belongs in the same category, except the damage it does is worse.
The idea is simple enough: some developers produce ten times the output of an average engineer. Hire enough of them and you can build more with less: smaller teams, faster output, lower headcount costs. It sounds intuitive.
It is also, as anyone who has led an engineering team for more than a year will tell you, mostly wrong, and in 2026, dangerously so.
Where it came from
The origin is a 1968 study by Sackman, Erikson, and Grant: “Exploratory experimental studies comparing online and offline programming performance”
Sackman, Erikson, and Grant set out to determine whether programming online offered any advantages over offline programming. Interestingly enough, they didn’t intentionally set out to show a 10x difference in programmer productivity, but the finding was real: some developers do outperform others.
However, the leap from “individual output varies” to “the lone genius is the ideal to hire for” was never in the data. The 10x myth was essentially a byproduct finding that got detached from its original context and took on a life of its own.
By the time it entered mainstream tech culture, the 10x engineer had become a specific archetype: the solo coder who moves faster than everyone else, guards their knowledge jealously, writes systems only they can maintain, and treats collaboration as overhead.
That is not a description of someone who creates exceptional value. It is a description of someone who creates exceptional personal output, while quietly distributing the costs of that output to everyone around them.
Actual 10x engineers
Ask any senior engineer which colleagues made the biggest difference to their career and their team, and they will not describe a solo genius. They will describe someone who made the people around them better. Who documented their decisions. Who designed systems others could understand and extend. Who spent time mentoring juniors. Who asked the inconvenient architectural question before the sprint started.
Software engineering is a team sport. The engineers who create the most leverage are the ones who multiply the capacity of the people around them, not the ones who maximize their personal commit count.
AI gave it new legs
The term had been fading. Then AI coding tools arrived, and it came roaring back, with even bigger numbers attached.
Venkat Venkataramani, VP of application infrastructure at OpenAI, recently said “there are easily 1,000x engineers now. I don’t even know if that’s the limit. There may be 1,000,000x engineers coming.”
The implication being that AI tools and coding agents have minted a new class of hyper-productive developer whose output so dwarfs their peers that the old benchmark looks quaint. The myth, which had at least been losing cultural ground, got a second wind.
AI tools do change what individual developers can do but the problem is that velocity was never the right measure to begin with, and applying a multiplier to the wrong metric just produce a bigger wrong number.
Lauren Peate, founder and CEO of engineering intelligence platform Multitudes, makes the point directly: “Just because someone moves quicker now that doesn’t necessarily mean they’re producing good quality work, or that they didn’t just create more issues for other people on their team on the way”.
Teams that adopt AI tools and measure success in lines of code shipped, features closed, or PRs opened will see impressive numbers. They will also, if they are not careful, be building a measurement framework that makes it structurally impossible to see the problems accumulating underneath those numbers: the bugs that passed review because the reviewer was overwhelmed, the architectural shortcuts that seemed fine until they didn’t, the junior developers who got less mentorship because everyone was moving too fast to teach.
What to replace it with
The answer is not to pretend individual capability doesn’t vary. It does, and it matters. The answer is to measure the right things.
Team outcomes over individual output. System quality over feature velocity. Knowledge distribution over knowledge concentration. The ability to make the people around you faster and more capable, rather than faster at the expense of the people around you.
If AI tools are genuinely improving engineering productivity, those improvements should show up in outcomes: fewer incidents, faster recovery, better code quality, healthier review queues, stronger engineers at every level of the team. If the only place the improvement shows up is in individual commit metrics, something is being missed.
The 10x engineer was always a simplification. It compressed something real (variance in individual capability) into a framework that drew the wrong conclusions from it and pointed teams toward the wrong goals.
It’s time to bury this term. Measure outcomes instead. Build teams that make each other better.
💜 This newsletter is sponsored by Multiplayer.app, the debugging agent for developers.
📚 Interesting Articles & Resources
96% of Enterprise Permissions Go Unused - Oso research
New research by Oso analyzing 2.4 million workers and 3.6 billion permissions, reveals a massive gap between granted access and real usage. The risk is that AI agents will inherit the unused enterprise permissions and turn dormant access into a security crisis.
Venkat Venkataramani's '1,000x engineers now' claim does exactly what you describe: it repackages the same toxic metric in an AI wrapper. The Oso permissions data is an interesting companion — enterprises already can't audit what their human engineers touch, and now we're celebrating individual engineers who touch more. At theaifounder.substack.com I track AI builder patterns, and the measurement problem gets worse in early-stage teams, where the 10x narrative gets used to justify not hiring and not building systems. What metrics have you seen work for measuring engineering health in teams using AI coding tools, beyond velocity?