The 10x Engineer Is Dead. Long Live the Software Factory.

AI is shifting the productivity advantage from individual coders to autonomous engineering systems. Here’s why the old metrics no longer matter. 

What if the best engineer on your team suddenly became one of the least productive? 

Research into AI-driven software development suggests that this is already happening. Roughly half of previously top-performing developers fell into the bottom quartile after adopting AI, while half of those at the bottom rose to the top. AI isn't just making engineers faster. It's changing what makes an engineer exceptional. 

And the implications go far beyond individual careers. As AI takes over more coding, the old ways of measuring developer productivity are already obsolete. The next competitive advantage may belong not to the companies with the best engineers, but to those with the best systems for turning ideas into software. 

We recently brought together Yegor Denisov-Blanch, an AI researcher at the Stanford Artificial Intelligence Laboratory, and Eno Reyes, co-founder and CTO of Factory AI  to explain what engineering productivity looks like in this new era. 

The Great Engineering Shake-Up 

AI was supposed to make every engineer more productive. Instead, it’s creating a new divide. 

Denisov-Blanch's research across dozens of developer teams finds that software engineering productivity has more than doubled since late 2025. His machine learning model analyzes historical Git data, accounting for the volume, complexity, and quality of merged code changes, while controlling for team size, codebase characteristics, and task type. It does not measure the engineering activity, it measures outcomes and their delivery speed.  

These aggregate gains obscure an even more consequential finding: the gap between the highest- and lowest-performing teams using AI has widened twelvefold over three years. Top-performing teams improved productivity roughly 30 times more than the bottom quartile. 

“You can be using AI and not getting a lot out of it,” Denisov-Blanch says. “I expect this gap to continue growing.” 

The tools may be widely available. The ability to extract value from them isn’t. 

And the winners aren’t necessarily the top-performing engineers. Denisov-Blanch’s research — which is responsible for that finding that after AI adoption, roughly half of previously top-performing developers fell into the bottom quartile, while half of those previously at the bottom rose to the top — points to an engineer realignment. 

“AI is reshuffling the whole talent space,” he says. 

The New Engineer Looks More Like a Product Manager and Operates a 100x Factory 

The skills that once made an engineer exceptional aren’t disappearing. They are changing. As AI takes over more coding, the advantage shifts toward people who can identify the right problems, translate business needs into clear instructions, orchestrate agents, and evaluate the results.  

In other words, the most productive engineers are starting to look more like product managers, architects and designers.  

“The role of an engineer and a product manager are merging more and more,” Denisov-Blanch says. “Those engineers who, for whatever reason, can’t become product managers will likely struggle.” 

The reverse is also true. Product managers who cannot use AI tools to build and ship working software, rather than merely prototype it, and who lack the depth of how and why technology works, are falling behind. 

The deeper shift is from execution to judgment. When writing code becomes cheaper, deciding what to build and whether it creates value becomes more important. This shift is bigger than any individual’s productivity. 

The next breakthrough isn’t a faster coding assistant. It’s a software factory. 

Today’s coding agents help developers write, review, and debug code. Factory’s Eno Reyes believes that within two to five years, these tools will evolve into largely autonomous systems that handle the entire software-delivery process. 

Imagine a customer reports a bug. Today, a product manager may prioritize it, then send it over to an engineer, who investigates, writes code, tests it, opens a pull request, waits for review, and eventually ships a fix. 

In Reyes’s world, that bug report triggers a system that investigates the problem, plans the solution, implements it, tests it, deploys it, and monitors the result. Humans steer the loop. AI increasingly executes it. 

“A software factory can deliver so many more projects and have far more shots on target to build things that will be valuable to customers,” Reyes says. 

The opportunity isn’t simply to ship the same amount of software faster. It’s to pursue far more opportunities at once. And that can drive dramatic acceleration of business outcomes, not just software.  

But that creates a new problem: how do you measure productivity when the software-delivery system, rather than the individual developer, is doing the work?

Stop Counting Code. Measure Signal-to-Product Ratio. 

For decades, software engineering productivity was closely associated with developer output. Lines of code, pull requests, and story points became familiar proxies for progress. 

AI is breaking that relationship.  An engineering team can generate more code, consume more tokens, and launch more agents without delivering more value. These metrics still help diagnose how work gets done. They don’t tell you whether the system is producing the right outcomes. 

Reyes proposes a different measure: signal-to-production latency. 

How long does it take to turn a customer need, bug report, or market opportunity into working software? That question captures the performance of the entire system, from requirements and planning to implementation, validation, deployment, and monitoring. 

It also reveals bottlenecks that coding-speed metrics miss. Faster code generation won’t help much if requirements remain unclear, tests are unreliable, team is attempting manual core-review or releases take days. Yet even signal-to-production latency is only part of the answer. Shipping faster matters most when it creates more value. 

That’s where the Google number comes in. 

Find your Google Number. 

In the early days of the web, milliseconds meant millions at Google. 

The company found that additional page-load latency was associated with declines in page views and advertising revenue. Faster pages weren’t simply a better technical experience. Engineering performance had a measurable connection to business results. So much so that Google also began to prioritize websites based on performance in their search results! 

“Engineering metrics were effectively levers for revenue,” Reyes says. And Google optimized that insight at scale. So can you.  

In fact every company needs to find  its own Google number: an engineering outcome that demonstrably moves the business. 

For one company, it might be the time required to resolve a customer issue. For another, the speed of shipping a product improvement or responding to a security finding.  

The right number is measurable, continuously observable, actionable by engineering, and connected to something the business actually values. 

Finding it is the first step. Making it move is where AI ROI becomes real. 

Five Moves to Make Your AI ROI Move 

1. Follow the money. Start with the business outcome, not the engineering activity. Identify the metric that links software delivery to revenue, retention, customer experience, or cost. Define precisely what you’re measuring and why it matters. 

2. Measure the distance from signal to software. Instrument the entire delivery loop, from triage and planning through implementation, validation, deployment, and monitoring. Find where time is actually being lost. The bottleneck may have little to do with coding. 

3. Stop confusing motion with progress. Lines of code, pull requests, token consumption, and agent calls are useful diagnostic signals. They aren’t the scoreboard. Track outcomes such as signal-to-production latency, recovery time, and cost per validated change, then use activity metrics to explain what drives them. 

4. Put guardrails around the gains. Speed without quality, security, reliability, and cost discipline isn’t productivity. Before expanding agent autonomy, establish reliable tests, clear documentation, consistent development environments, and explicit operating constraints. 

5. Spend inference where it moves the number. REPEAT.  Change one variable, measure the result against a baseline, and keep what works. Expand autonomous workflows as they prove their value. 

   “Pick the metric, wire the engineering loop that impacts it, and spend inference until it moves,” Reyes says, “much like Google spent money engineering on page-load speed.” 

The Next 10x Breakthrough 

For decades, software companies competed to hire engineers who could write the best code, the fastest. 

AI is changing the terms of that competition. The unit of productivity is shifting from the individual developer to the entire system that turns needs into outcomes. That demands a different kind of talent, a different operating model, and a different scorecard. 

The teams that win won’t simply give every engineer an AI coding assistant. They’ll redesign how software gets built, measure what actually creates value, and continuously improve the system. 

And it won’t just be the engineering team. Two of Factory’s heaviest internal power users sit in finance. Together, they automate ~99% of their work. Over 2.5 months, they spent $10K on their own product and generated ~$300K in savings, a 30x ROI. 

The next 10x breakthrough won’t be an engineer who writes ten times more code. It may not be an engineer at all. It will be an organization that can turn ten times more ideas into products customers actually want.