Where are your rockstars?

Last week at a meetup, a recruiter asked me where I think software engineering is going. I promised her a proper answer in writing. This is it.

Most of the engineers I talked to that evening believed that AI makes everyone a little faster and that only the juniors have to worry. Nobody in the room seemed bothered. They had the juniors right and everyone else wrong. I have been programming for thirty years. In the last two I haven't written a line of code by hand, and I have built more in that time than ever before. A small group of engineers has pulled so far ahead of everyone else that comparing them no longer makes sense. Most companies haven't noticed yet, and the ones that keep not noticing will lose to ten people with an unlimited token budget.

The studies measure the wrong engineer#

Every large study of AI and developer productivity lands in the same place. In field experiments at Microsoft, Accenture and a Fortune 100 company, developers with AI finished about a quarter more tasks¹. Stanford's data on 100,000 developers puts the typical gain at about a tenth². Teams that went all in merged twice as many pull requests, review time almost doubled, and lead time didn't move³. Nine in ten executives say AI has done nothing for their productivity⁴.

When METR tried to rerun its famous 2025 experiment, between a third and half of the developers it invited refused to work without AI, and the study could no longer be run⁵. The averages are all the measurement we are going to get.

They measure the median engineer inside the median process, and for that engineer AI is a 10% bump that will stay a 10% bump. Companies bought every engineer a Ferrari and kept the speed limit at 30, and most of their engineers would drive at 30 without it. The engineers this article is about disappear in those averages, and they are the only ones whose numbers matter.

Your process is a rationing system#

Developers spend about a sixth of their week writing code⁶. Make that sixth free and Amdahl's law caps the gain at about a fifth. That is the ceiling, and the studies cluster around it.

The other five-sixths is not an accident. Sprints, tickets, estimates, design handoffs, review queues and release trains were built to ration a scarce resource: the few people who could write software, and the time it took them. Tickets exist to cut a product into pieces small enough for one head, because no single head could hold the product and also build it.

Writing code stopped being scarce and the rationing kept running. Scrum still works as designed, which now means holding every engineer to the speed of the coordination around them.

Three kinds of engineer#

The engineers I meet fall into three groups.

The first started after 2020 and feels hypercharged. They produce absurd amounts of code, reject review, and say proudly that they don't know what is in their codebase. They have confused 10x with ten times the lines of code. The moment there are customers and a system that has to survive a few years, that code comes due, as I wrote in Sure thing, here's your solution.

The second group is experienced engineers, mostly in large companies. They distrusted AI until the latest models made it undeniable, and now they are bored. Their job was solving the problems that reached them, and a machine solves those now. Their teams aren't faster, because the process didn't change, so the same tickets arrive at the same pace and take an afternoon. When I told them to go and find problems to solve, they laughed. Most seniors were never engineers in the sense that matters now. They were excellent implementers, and implementation is a commodity.

The third group is small, a fraction of the seniors: the engineers we used to call 10x. I'll call them rockstars here, because the 10x label measured the wrong thing. They always had more problems in view than hours to solve them. If they can describe a problem and the result they expect, they hand it to as many agents as it takes, and by the time those agents finish, the next batch is already running.

The rockstar#

The 10x label goes back to a 1968 study that timed programmers coding and debugging the same problems⁷. That kind of speed is exactly what AI flattened: anyone can produce working code now. The engineers we actually called 10x were rarely the fastest coders in the room. They understood the product well enough to build structures the next feature simply fit into, so they needed less code and left less debt, and they made decisions without asking and fixed problems before anyone else saw them.

Their limit was hours. Every one of them has a list of libraries, tools and frameworks they built because they needed them, and every one of those cost hours the actual product was waiting for. That limit is gone. In the last six months I built Nisc, a full-stack framework, and I now ship applications on it in days. Agents keep improving the framework while I work on the product, so every product starts on better tooling than the one before.

The 10x engineer is a 100x engineer now, measured by what one person can take on alone.

What one person does now#

In August 2024, Microsoft's TypeScript team started porting the TypeScript compiler from TypeScript to Go, a codebase Anders Hejlsberg puts at about a hundred person-years of work. They shipped it as TypeScript 7 in July 2026, almost two years later⁸. In October 2026, Theo Browne took their Go code and ported it to Rust: compiler, type checker and language server. He burned about $400,000 of Codex tokens and got nowhere, then spent about $20,000 on Opus and got there in two weeks. He has not read a single line of the code⁹. That is exactly what I hold against the first group, and here it works for one reason: he had Microsoft's finished compiler to check every result against. It was a side project. He estimates everything he shipped in the 24 days after the model came out at 22 years of conventional work¹⁰.

Peter Steinberger, an Austrian developer, built OpenClaw on his own as a hobby project. Weeks after it went viral, OpenAI hired him to lead its personal agents¹¹. He says he was constrained by tokens until he joined. In October he put his token bill for a single month at about $10 million¹². He is token maxing, and OpenAI pays the bill.

The moat is gone#

Brand, sales and data matter, but for most SaaS products the barrier to entry was the cost of writing the software: it took a lot of people a lot of years to build what they built. That cost is gone.

Three rockstars with unlimited tokens and a good head of product and marketing can rebuild most SaaS products in a quarter. In 2014, Facebook paid $19 billion for WhatsApp, which had 55 employees, 32 of them engineers¹³. Today ten of the right people could build it, faster and with fewer bugs.

What companies have to do#

First, find them. Rockstars don't show up in titles or in sprint velocity. They are the person who rebuilt the internal tool nobody asked for, and the one product calls when no one else can say where a feature belongs.

Then give them a product, not a team. One product, one stakeholder who can decide, a deadline, and a token budget without a ceiling. And get out of the way. They will replace the surrounding process with their own: agents take the tickets, the tests, the bug triage and the docs, and the stakeholder talks to the engineer instead of a backlog. Most bugs become a prompt. Put the same person in a sprint and you cut the product back into tickets, which takes away the one thing AI multiplies: a single head holding the whole product.

Most companies aren't ready to pay for this. Uber spent its entire 2026 AI budget in the first four months of the year¹⁴. The run that worked cost Theo about what a senior engineer costs a US company per month. If nobody in finance has asked about your AI budget yet, you are still trying AI out.

The objection is always the bus factor. Your 40-person team already has a bus factor. It is just spread across people who don't understand the system. The real answer is to make the rockstar's leverage live in artifacts, not in their head: architecture enforced by types and module boundaries, tooling another engineer or another model can pick up, behaviour described in declarative documents a machine can check. That is why Nisc treats the whole application as data validated against rules. The work has to outlive the attention of the person who did it.

Stop routing tickets to your bored seniors and hand them problems instead. The scarce part of the pipeline moved to the front: noticing what is wrong and deciding what is worth doing is the one skill that didn't get cheaper. Some of them will go looking. The ones who wait for the next ticket are writing the spec for their own replacement. And the first group needs code review it isn't allowed to refuse.

A different sport#

The gap between a rockstar and everyone else used to be something people argued about over beers. Everyone now has the same tools, and only a few people use more than a fraction of what they can do. It is no longer the same sport.

The gap will keep growing, and not only because the models keep getting better. Rockstars were made by years of building things by hand, getting them wrong and living with the consequences. That path started with an entry-level job, and AI is taking those jobs: employment for software developers aged 22 to 25 is down by a fifth since 2022¹⁵. I have mentored a lot of young engineers, and I don't know how the next generation of rockstars gets made. Nobody does. The bottom rungs of the ladder are gone and no one is replacing them, so the rockstars working today are the last ones made the old way. They know what that makes them worth.

If you run a software company and don't know who your rockstars are, a ten-person startup does, and it is hiring them.