Why staff augmentation broke, and what comes next
Labor arbitrage delivered 30–40% efficiency. AI arbitrage delivers more than 100. The teams positioned to capture it are not the ones you'd expect.
The question I get asked most often now is whether AI changes any of this.
Whether the practices I have built over twenty years, the hiring rigor, the belonging work, the local leadership, the visibility infrastructure, are still relevant when an engineer can generate a pull request in an afternoon that would have taken a week a year ago.
My answer is yes. But not for the reason most people expect.
From labor arbitrage to AI arbitrage
I spent time talking with Karthik Krishnamurthy on the PreVetted Podcast. He’s the CEO and founder of Ascendion, a company that operates AI-native engineering teams across twelve countries including Mexico, Brazil, and Colombia. He has watched more AI transformations inside enterprises than almost anyone I know. He clarified something I had been circling around for months.
The old model of international software delivery, the one I built my early career around, was labor arbitrage. Find a labor pool where skilled engineers cost less. Deliver faster, better, cheaper. The efficiency gains were real: 30, 40 percent. That model is not wrong. But it is no longer where the frontier is.
The next model is what Karthik calls AI arbitrage. An engineering team that is truly integrated with an AI-native process can deliver outcomes that don’t improve the old benchmarks by 30 percent. They obliterate them. “Labor arbitrage helped you deliver 30, 40 percent,” he told me. “But now you’re talking about percentages which go over 100.”
He’s not talking about automating repetitive tasks. He’s talking about compressing the time between idea and shipped software by an order of magnitude.
The question I had to sit with was: which distributed teams are positioned to capture that, and which ones are not? The answer, when I thought it through, was not the answer I expected.
Context is the advantage
The teams that will not be able to capture AI arbitrage are the ones built on pure staffing logic. Engineers who rotate in and out, who do not accumulate institutional knowledge, who are not integrated into the client’s product thinking. Agents do not improve the output of a team that has no context to transfer. You cannot contextualize an agent around a domain the team has never understood deeply.
Karthik is relentless on this point. He called contextualization the highest-effort, most-overlooked part of enterprise AI: “We spend 25 to 30 work streams on contextualization before we open the platform for everybody to use.” The accumulated business definitions, the decision logic, the edge cases that were never documented because everyone just knew them, all of it has to be ingested before agents can operate at production quality.
That work requires people who have been there long enough to know what the context is. Engineers with two-year tenure on one client. Engineers who sat in the architecture discussions. Engineers who absorbed the product reasoning, not just the ticket acceptance criteria.
I have been building those teams for twenty years without calling it that. The low turnover wasn’t just a retention metric. It was the accumulation of context that an agentified process can now amplify.
The senior developer’s dilemma
Everyone is focused on what AI does to junior engineers. The fear is that AI will close the entry-level gap, that the path from bootcamp graduate to productive contributor will be automated away. That is a real concern.
But Karthik identified the more immediate problem. “I worry a lot for the senior developers now,” he told me. “The people that have held on to their Python code for too long, who haven’t spent enough time understanding domain, who haven’t spent enough time understanding the functions in which they belong so that they can actually validate the outputs of the agents more effectively.”
The senior engineer who built an identity around deep implementation expertise, who is the go-to person because they know the codebase better than anyone, is the one whose position is most at risk. Not because they’re being replaced. Because the codebase fluency they accumulated is increasingly reproducible by an agent that has been given the context they carry in their head.
The engineers who are not at risk are the ones who built their career on judgment, not implementation. The ones who understand why the system works the way it does, not just how to make it work.
Charlene Li, who came on the podcast, she’s tracked technology disruptions from the internet to social media to AI, made the same point from a different angle. “AI will give you the answers that are as good as the questions that you ask it,” she told me. “People who are experts in their fields do so much more with AI than somebody who is just starting out.”
This is another reason why distributed teams that invest in long tenure and career development are better positioned than the ones that optimize for cost and replaceability. The engineer who has been on the same product for four years and understands why the payment flow works the way it does can use AI to go ten times faster. The engineer who rotated in six months ago and is still reading the documentation cannot.
Speed is the advantage
Charlene’s core argument is that the competitive advantage in an AI world is not adopting the tools. Everyone adopts the tools. The advantage is how fast an organization can adapt itself around them.
“Speed is the new moat,” she told me. “And what I mean by that is not just the adoption of AI, but the adaption of your organization. How quickly can you change your organization?”
An organization that deploys Copilot but does not redesign its review process, its QA culture, its approach to documentation, has not adapted. It has added a tool to an unchanged system. An organization that asks what it would look like to restructure how engineers spend their time, how product and engineering align, how decisions get made when AI handles implementation, that organization has adapted. The tool is the same. The lead is not.
The distributed teams I’ve built are, structurally, faster at this kind of adaptation than most co-located organizations. They have already had to design for async. They have already had to build explicit communication infrastructure rather than relying on proximity. They have already had to create the documentation and context-sharing practices that AI now rewards. The discipline that distributed work required turned out to be a rehearsal for what AI-native work requires.
Every engineer becomes a manager
Swati Swoboda, also a podcast guest, manages Vault at Shopify’s Office of the CEO. She described what this shift looks like inside a company that has already crossed into it. Her team of eight generates over one hundred pull requests in a single day. She reads far more than she writes.
“Every engineer has become a manager effectively,” she told me. “They are understanding a business use case and then telling it to a bunch of agents.”
The code is still being written. But the person writing it is increasingly the agent, and the person directing the agent is the engineer. The engineer’s job has become closer to a product manager’s job: understand the business problem, frame it precisely, evaluate the output against reality.
What that requires is the opposite of what most technical hiring has screened for. “The skills that are shining right now,” Swati said, “are the folks where they have paid attention to their communication skills. Being able to express a problem. Understanding why we are doing something.”
She framed the future in terms I found more honest than most AI predictions: more companies with engineers, fewer engineers per company. The accountant parallel, when Excel arrived, we did not need fewer accountants. We needed more, because more companies could now afford an accountant’s function. The same logic applies here. AI will not reduce the total number of engineers in the world. It will reduce the number required per company while expanding the number of companies that need engineering capability. The field will grow. Each company’s team will shrink.
What replaces staff augmentation
What’s breaking is the model where a vendor sends you bodies and bills you hourly, where engineers rotate every twelve to eighteen months, where the relationship is transactional and the context resets with every change.
What replaces it is something that looks more like a partnership. Long-tenured teams. Engineers who own a domain for years. Local leadership that holds context across cycles. An operational discipline that treats accumulated understanding as the asset, not the headcount.
That model is harder to sell on a spreadsheet because the unit economics aren’t “engineer-hours × rate.” The unit economics are “what can a team that has been integrated for four years do that a team integrated for six months cannot.” That number is not in any benchmark, but it’s the only one that matters now.
The teams that figure that out get the AI compounding effect. The teams that don’t keep paying labor-arbitrage rates for outcomes that no longer benchmark to a market.
Staff augmentation isn’t dying because of AI. It’s dying because AI exposes what the model was actually missing: context. The replacement is the kind of team you build when you stop treating engineers as interchangeable.