The Long Game for All: Counting What Frontlines Know
The Long Game for All: Counting What Frontlines Know · Oct 13, 2026 · 15:11
Listen in the Podli app 🎧
Follow your favourite podcasts, listen offline and in the car with CarPlay and Android Auto, and always pick up where you left off. Free to try.
Trim 2 was the bottleneck at Lansing Delta Township. Night shift, nine hours, and most nights it gave up fifty or sixty minutes of downtime. Supervisors had tried. Everyone above them had tried. I had tried.
Then Abdelhak Radjai came to run Trim 1 and Trim 2 on nights.
He had been one of the best team leaders on that floor, and he never stopped acting like one. He would jump on any job on his line so someone could take a bathroom break, which is the highest-value currency on a factory floor. And he watched. He saw a new team leader drowning in repairs before she had mastered the six jobs on her own team, so he had another team leader cover them and sent her back to build her footing. He saw team leaders who never left their zone to chase a repair, and he parked them off the line, inspecting and fixing the defects coming out of his team and the four others in Trim 2.
Within a month the shift was closing under ten minutes.
Look at what he did. He observed the system, changed it, tested the change, and kept what worked. And the thing he improved was the people who improve the line. The improver improved the improvers.
Then Abdelhak moved on. One of the team leaders who had pulled for him went out on sick leave. Another left for the pilot team. The people who came in behind them held the line anyway, because Abdelhak had set the standard.
Now look for that standard in the plant’s books. The downtime number moved. The capability that moved it, and kept it moved after he was gone, appears nowhere.
That loop now has a name and a funding round. On August 5, Jeff Dean, Sanjay Ghemawat, Oriol Vinyals, and Quoc Le founded Discovery Loop to automate the experimental loop of research, including using AI to build more powerful AI. The field calls it recursive self-improvement. Another firm, Recursive Superintelligence, raised some $650 million within months of its founding.
We are ready to afford that loop to machines, in both senses of the word. We will pay for it and we will permit it. The people who already run it, in the frontlines of six industries across the United States and India, get neither. That’s the argument.
What the machine is given
Look at what a self-improving system requires, and what its builders gladly provide.
It gets its own performance data, in full, in real time. It gets permission to change itself; the whole design assumes it will propose changes and some will be adopted. It gets a protected budget for experiments, and the failed runs are understood as the cost of learning. It gets a memory that keeps the gains, in the weights and the next version. And it gets an evaluation it can trust, a test that tells it honestly whether it got better.
Data, permission, budget, memory, evaluation. We build all five for a model before we ask it to improve.
What the operator is given
Now check the same five against a machine operator, a maintenance tech, a line lead.
Her performance data goes up the chain. The Pareto charts and downtime codes are analyzed in a conference room she is not in.
Her permission to change the work is nil. Standard work belongs to engineering. She learns early to run it the way it’s written and keep the better way to herself.
Her experiment budget is zero. Every hour she spends learning lands as labor variance, and the Monday call asks why the number is red.
Her memory isn’t kept by the enterprise at all. Her capability appears on no ledger. When she leaves, it walks out the gate with her, and the accounting never registers the loss, because it never registered the asset. At best it is folded silently into goodwill on the day someone buys the company.
Her evaluation is a review written by someone who watched her work a few hours all year.
Deny a machine those five conditions and it would not improve either. We would call that bad system design. When the same outcome shows up in people, we call it a skills gap.
Three reasons we give, none of them true
The case against extending the loop to people is rarely stated out loud. It rests on three quiet assumptions.
The first is capacity: that frontline workers can’t do this kind of thinking. Abdelhak answers that by himself. Every plant I have run had operators who knew the machine better than the drawings did: which fixture drifted in the afternoon heat, which supplier’s lot ran soft, which alarm could be cleared and which meant stop now. That is a model of the process, built from observation and revised under pressure. In Already Paid For I estimate roughly 30 percent of frontline capability is deployed and 70 percent is stranded. We are not short of intelligence on the floor. We are wasting most of what we have already paid for.
The second is flight: why invest in someone who may walk out the door? A model’s gains stay in the weights, and the weights belong to the company. A person’s gains belong to the person. True. But it gets the causation backwards. People walk out because nothing holds the capability in place: no runway, no wage that rises with what they can do, no record that it exists. We build the exit and then cite it as the reason not to invest. The Germans settled this long ago. A Meister certificate is fully portable, and German firms form tradespeople anyway, because a system that forms everyone is worth more than a firm that hoards a few.
The third is credentials: the degree as a stand-in for cognitive capacity. The worker who could run the loop often lacks the paper that would let anyone believe it, usually because she couldn’t afford the time or the tuition. So the proxy screens out the people with the most floor intellig
Episodes: The Long Game for All: Counting What Frontlines Know