When Walmart announced that it was introducing limits on the usage of its internal AI coding assistant, the discussion immediately drifted toward infrastructure costs. Predictably, most of the commentary focused on tokens, inference expenses and whether enterprise AI would eventually become too expensive to scale.
That reaction says more about the way we currently think about AI than it does about Walmart’s decision.
If you’re one of the largest companies in the world, token consumption is not a strategic concern. AI infrastructure costs are measurable, certainly, but they’re still insignificant compared to labor, logistics, inventory, procurement or transportation. Companies of that size don’t redesign the way they build software because an inference bill increased by twenty percent.
What caught my attention wasn’t that Walmart introduced limits.
It was the explanation.
According to Suresh Kumar, Walmart’s Global CTO, employees across the organization were repeatedly asking AI to solve essentially the same problems. Similar scripts. Similar automations. Similar internal applications. The company wasn’t trying to reduce experimentation; it was trying to reduce duplication.
That distinction matters because it points to something much bigger than token optimization.
It suggests that enterprise AI has quietly shifted the fundamental economics of software development.
For decades, software organizations optimized around execution. Today, they’re beginning to optimize around coordination.
Those are two completely different problems.
Software Has Always Been an Exercise in Avoiding Duplication
Modern software engineering is, in many ways, the history of organizations trying to stop smart people from solving the same problem twice.
Shared libraries exist because maintaining twenty implementations of the same functionality is irrational. Design systems emerged because every product team designing its own buttons eventually becomes impossible to scale. Internal platforms, platform engineering, reusable APIs, service catalogs and engineering enablement all follow exactly the same economic principle: every time a solution becomes reusable, the marginal cost of future work decreases.
Organizations didn’t build these practices because engineers enjoyed documentation.
They built them because duplication is extraordinarily expensive.
Generative AI changes one variable in that equation.
Creating something new has become dramatically cheaper.
Ironically, discovering whether something already exists has not.
That’s a subtle shift, but it completely changes organizational behavior. When generating a new SQL query takes thirty seconds and searching Confluence takes ten minutes, most people will simply generate another SQL query. When asking GPT to build an internal automation feels easier than navigating three different knowledge repositories, they’ll generate another automation.
Individually, every decision is rational.
Collectively, the organization becomes increasingly fragmented.
That’s the paradox AI introduces.
AI Doesn’t Eliminate Organizational Friction. It Relocates It.
One of the most common assumptions surrounding generative AI is that software development has always been constrained by engineering capacity. If only we could write code faster, document systems faster, or build prototypes faster, software teams would naturally become more productive.
For most of the last thirty years, that assumption was largely correct. Writing software was expensive because implementation itself was expensive. Every additional feature required engineering time, every new integration consumed developer capacity, and every release represented weeks—or months—of coordinated effort. Improving execution was therefore the obvious optimization target, which explains why software organizations invested so heavily in Agile, DevOps, CI/CD, platform engineering and developer experience.
Generative AI doesn’t invalidate those investments. It changes where they create value.
Once implementation becomes dramatically cheaper, the limiting factor is no longer the ability to produce software. It’s the organization’s ability to decide what should be produced, whether somebody else has already solved the same problem, and how those solutions become shared capabilities instead of isolated artifacts.
That’s a fundamentally different optimization problem.
Building another internal tool is no longer difficult. Deciding whether the organization actually needs another internal tool has become the difficult part.
The paradox is that AI makes every individual significantly more productive while simultaneously increasing the amount of coordination required across the organization. The faster every team can build independently, the more important it becomes to prevent those teams from unknowingly solving the same problem in parallel.
Seen from that perspective, AI doesn’t eliminate organizational friction.
It simply relocates it.
The Industry Is Measuring the Cheapest Part of the Equation
One of the unintended consequences of enterprise AI is that it makes duplication feel almost free.
Generating a new solution has become so inexpensive that very few people stop to ask a more important question: should this solution exist at all?
Imagine an engineer who spends thirty seconds asking an LLM to generate an internal automation. From their perspective, that’s an extraordinary productivity gain. The task is complete before they even considered opening an internal repository or asking whether another team already solved the problem.
Now multiply that behavior by five hundred engineers.
Suddenly, the organization doesn’t have one automation.
It has hundreds.
Some solve exactly the same problem. Others differ only slightly. None of them were intentionally duplicated; they simply emerged because generating a new solution was easier than discovering an existing one.
That’s the cost almost nobody includes in the AI business case.
Inference is a marginal cost.
Duplication is a compound cost.
Every additional version needs to be understood, maintained, updated, secured and eventually replaced. Six months later, the organization isn’t paying for prompts anymore. It’s paying for every decision that those prompts silently created.
From an accounting perspective, AI may have reduced software development costs.
From an organizational perspective, it may have just created a much larger maintenance problem.
That’s why I find Walmart’s decision so interesting.
They’re not trying to save tokens.
They’re trying to prevent entropy.
Governance Is Becoming a Knowledge Problem
Much of the conversation around enterprise AI has become centered on governance. The term appears in almost every board presentation, strategy document and consulting framework. Yet it’s often used to describe a surprisingly narrow set of concerns: which models employees are allowed to use, how many tokens they can consume, what data can leave the organization or which prompts should be audited.
Those controls matter, particularly in regulated industries.
They are also the least interesting part of the problem.
The difficult question isn’t how to control AI. It’s how to ensure that every interaction with AI makes the organization more capable than it was the day before.
Imagine an engineer discovers a remarkably effective workflow for generating migration scripts. Another designer develops an evaluation framework that consistently improves UX research. A product manager creates an agent capable of producing high-quality PRDs in a fraction of the usual time.
What happens next?
In most organizations, absolutely nothing.
Those workflows remain personal assets. They’re buried inside someone’s chat history, forgotten when that employee changes projects, and eventually recreated by somebody else who has no idea they already exist.
That’s not a governance failure.
It’s a knowledge architecture failure.
AI has dramatically reduced the cost of creating expertise, but it has done almost nothing to reduce the cost of distributing that expertise across an organization. As a result, companies are becoming increasingly productive at the individual level while remaining surprisingly inefficient at the organizational level.
The companies that extract disproportionate value from AI won’t necessarily be the ones deploying the best models. They’ll be the ones capable of converting thousands of individual interactions into shared organizational capabilities.
That’s a much harder problem than selecting between GPT and Claude.
It’s also a much more valuable one.
What We’re Actually Building at Revolt
This realization has significantly changed the way we approach AI adoption with our clients.
We spend surprisingly little time discussing models.
Instead, we spend time designing how knowledge moves.
Every successful experiment should have the potential to become shared infrastructure. Prompts evolve into playbooks. Individual automations become organizational workflows. Specialized agents become reusable capabilities. Evaluation criteria become standards instead of tribal knowledge.
In practice, this means building repositories of prompts, agent libraries, orchestration layers, review processes and shared contexts that allow every successful interaction with AI to compound instead of disappear.
The objective isn’t to reduce experimentation.
It’s to ensure experimentation produces institutional memory.
That’s a very different problem.
And, in my opinion, a much more interesting one.
The Companies That Win Will Not Have Better Models
Every model will improve.
Context windows will continue growing. Inference costs will continue falling. Agents will become more autonomous, more capable and more reliable. Those trends are almost inevitable.
The organizations that outperform over the next decade, however, won’t necessarily be the ones with access to the best models.
They’ll be the ones that become exceptionally good at converting individual intelligence into collective intelligence.
Because execution is no longer scarce.
Knowledge is.
And if AI continues reducing the cost of creating new work while organizations fail to improve the way they discover, reuse and evolve existing work, they will find themselves solving the same problems faster than ever before.
That’s an impressive technical achievement.
It’s also a remarkably inefficient way to build a company.
