For forty years the 10X engineer was an argument, not an observation. Studies found tenfold differences between programmers on the same task, people disputed the methodology for decades, and the phrase mostly became a way of saying "hire people like me". Everyone argued about whether the person existed, but everyone agreed on what to measure: output.
Put three engineers on the same backlog today and watch them for a morning. The first doesn't use AI at all. Good engineer, reads everything, codes everything. The second has an agent open in one window: prompt, wait, read, prompt again. The third has four git worktrees open with an agent in each, one on a feature, one on a bug, one reviewing a pull request, one writing end-to-end tests, and moves between them checking what each one produced. By lunch the third has done what the first will finish on Thursday.
The next 10X engineer is the third one. What they do is take a vague ticket, turn it into a shipped change they can vouch for, and use agents to compress the part that used to be typing. Two sets of skills make that possible: the fundamentals that were always there, and agent skills that didn't exist three years ago.
The obvious thing needs saying too, and the whitepaper this article draws on says it plainly: AI has made some engineers worse. The second engineer in that morning scene produces more than they did two years ago and sometimes understands less of it.
The numbers behind all this come from our own delivery. On Miyagami builds, 80 to 90 percent of production code is now written by a model, and a project that needed ten engineers in 2024 runs on four engineers today. We didn't arrive there through a pilot; it's what two years of client work converged on, and it's why hiring the right engineers now matters more than it ever did. When four people carry what ten carried, one wrong hire stops being a rounding error.
What does the job look like when lines of code are cheap? Three years ago a senior engineer's day was pick a ticket, write the code, write a test, open a PR, next ticket, and most of the hours went into writing code by hand. Now tickets get split into a plan, the plan into pieces small enough that each PR is readable in one sitting, and those pieces go to agents in parallel. The hours go into deciding what to build, giving the agent the right context, and making sure the result is safe to ship. An agent builds whatever you give it, so a gap in the input shows up in the output within the hour: an unclear requirement comes back as something confident, plausible and built on a guess; missing context comes back as wrong assumptions about your system; weak tests let generated code pass while quietly breaking the behaviour they never covered.
That reframing explains why the second engineer in the morning scene isn't the answer either, and the distinction matters enough to pin down. An AI-native engineer, as we use the term, is a full-stack developer with solid fundamentals in code quality, systems design and security, who directs coding agents on how to produce output and validates that output before it ships. The fundamentals come first in that sentence for a reason: if you can't reason about the system without the agent, you can't tell when the agent is wrong. And if you can't review the code properly, the agent doesn't make you senior. It makes you faster at producing things you don't understand. An AI-native engineer isn't a prompter, someone who uses an agent the way you'd use a search box, one window, one request at a time, accept and on to the next prompt.
The awkward part for engineering leaders is that this difference is invisible everywhere hiring normally looks. It isn't on the CV, because everyone has "AI" on their CV now. It isn't in the take-home, because both submissions were model-written and look identical on screen. It isn't in a conversation about tooling, because the prompter has read the same posts you have. The difference is visible within minutes of watching someone work in a real codebase, and that's the one thing most interview processes never do.
We wrote The Next 10X Engineer because we kept having this conversation one CTO at a time. The paper walks through what the job is now, what AI-native means and what it doesn't, why the old hiring process stopped working, and the two working sessions we replaced it with: one testing the fundamentals with no AI in the room, one testing the agent skills with the tools on, each with the scorecard we fill in during it. It's the process every engineer we place goes through, designed and still run by our CTO.
The question it leaves for a leader is a plain one: if the multiplier is now something you can watch, and your process has never once watched a candidate work with an agent, what is your hiring measuring?
Download The Next 10X Engineer for the full argument, both assessments and both scorecards.
