The original claim was simple: some engineers produce roughly ten times the output of an average peer. Whether or not that ratio was ever measurable, AI tooling has changed what the multiplier is made of and who can achieve it.
Where the idea came from
The 10x label appeared in software mythology long before large language models. It described engineers who combined deep knowledge, fast decision-making and an ability to avoid dead ends. The advantage was personal and largely cognitive. A slow typist with the right mental model could still outperform a fast typist with the wrong one.
The evidence behind the original ratio was thin. Productivity studies in the 1960s and 1980s showed wide variation between programmers, but estimates vary considerably depending on how output was measured and what task was used. The number ten stuck because it was vivid, not because it was precise.
What has changed
AI coding tools, agents and code-aware assistants now handle a large share of the mechanical work: boilerplate, test scaffolding, documentation, refactoring, searching across a codebase. This compresses the gap at the bottom end. An average engineer with good tooling moves faster than an average engineer without it.
The practical effect is that raw typing speed and pattern recall matter less. What still separates engineers is the quality of their judgement: knowing which output to trust, which to reject, and which problem was incorrectly specified in the first place. An AI-native engineer is not simply faster at existing tasks; they restructure which tasks need doing at all.
Where the multiplier sits now
A few categories of skill have become more valuable, not less, as tooling has improved:
- Specification quality. AI models produce code proportional to the clarity of the input. Engineers who can decompose a vague requirement into a precise, testable description extract far more from their tools than those who cannot. This connects directly to context engineering.
- Review under pressure. Generated code arrives quickly and reads fluently. Catching the subtle logic error or the incorrect assumption requires the same skill it always did, applied faster and more often. See how to review AI-generated code.
- System thinking. Generating individual functions is easy. Deciding how components fit together, where failure modes live, and what the architecture will cost to change in six months remains a human task.
- Knowing when to stop. Over-building with AI assistance is a new failure mode. Generating ten abstractions where two would suffice creates debt rather than multiplying anyone's output.
The multiplier is now a team-level question
One consequence of better tooling is that outsized impact has become harder to isolate in a single individual. An engineer who raises the output of the whole team, by improving prompts, reviewing generated code effectively, or catching a model that has confidently produced the wrong answer, creates more value than one who simply ships faster alone.
The older version of 10x was individual and mostly invisible. The current version tends to show up in pull request quality, incident rates and how quickly a team recovers from a wrong turn. It is more legible, which is one reason hiring for it has become more deliberate.
What this means in practice
If you are hiring, the question is no longer who can produce the most code. It is who exercises the best judgement per unit of output. That includes knowing when a model is wrong, when a spec is incomplete, and when the simple solution is the correct one. How to assess an engineer's AI ability covers what that evaluation looks like.
What we test for
Miyagami's vetting process is built around judgement rather than throughput. Candidates sit two sessions: a fundamentals assessment without AI tools, and an AI-native assessment with them. The criteria that best proxy for real impact today are judgement by risk, which neither session skips, and ownership, which covers everything after the merge whether a person or an agent wrote the code. Full details of both sessions and every scored criterion are at how we vet.
Short answers
Is the 10x engineer idea still credible?
The productivity gap between engineers is real and documented, though the ratio of ten was always approximate. AI tooling has shifted what drives the gap: judgement and system thinking now matter more than speed or pattern recall.
Can AI tools make any engineer a 10x engineer?
Tooling raises the floor for everyone but does not eliminate the gap. Engineers with stronger judgement extract more from the same tools, catch more errors in generated output and make better architectural decisions. The gap persists, just through different skills.
How do you identify a 10x engineer in an interview?
Look for how they handle ambiguity, review generated code and explain trade-offs. Raw coding speed is a poor signal. Structured tasks around incomplete specs and AI output review are more reliable. See how-to-assess-an-engineers-ai-ability for a practical framework.
