We Risk Building the Wrong Things Faster

Over the past week, Uber and Microsoft have become early cautionary tales for the next phase of enterprise AI adoption. Uber reportedly exhausted its annual AI budget just four months into 2026, and questioned whether rising Claude Code token consumption was actually translating into more useful consumer-facing features. Microsoft, meanwhile, is reportedly winding down most internal Claude Code licenses, a decision framed partly around standardizing workflows but also reported to have a financial component. Together, these stories point to the same uncomfortable question: what happens when companies can generate more code, consume more tokens, and move faster, but still cannot prove that users are getting more value?

For decades, the dominant belief in technology was simple: ideas are cheap, execution is everything.

It was a useful belief because, for most of software history, execution was the scarce resource. Engineering capacity was expensive. Prototypes took time. Launching features required coordination across design, product, engineering, data, operations, legal, marketing, and support. Even small changes could demand planning, prioritization, and tradeoffs. The difficulty of building acted as a natural constraint. It forced teams to decide what mattered.

AI is changing that constraint.

With modern coding agents, frontier models, and AI-assisted development tools, the cost of execution is falling dramatically. Teams can move from idea to prototype faster than ever. Engineers can generate, refactor, test, and document code at a pace that would have seemed unrealistic only a few years ago. Product managers, designers, and non-engineers can increasingly create working demos without waiting for a full engineering cycle.

By now we all know these tools can generate useful code. The deeper issue is that many companies have not yet adapted to a world where building is no longer the primary bottleneck.

The new bottleneck is knowing what to build.

Companies can now move much faster in the wrong direction.

AI can accelerate strategy, but it can also accelerate confusion. It can help teams produce more, but it cannot automatically tell them what deserves to exist. AI does not solve the problem of weak product judgment.

We are starting to see this tension emerge in the industry.

Uber’s president and COO, Andrew Macdonald, recently questioned whether the company’s rising AI spending is translating into meaningful user value. After Uber reportedly exhausted its annual AI budget just four months into 2026, Macdonald said the company was not yet seeing a clear connection between rising token consumption for Claude Code and more useful consumer-facing features. He put the problem plainly: it is hard to justify AI token costs if a company cannot draw a direct line from that spend to useful features and functionality shipped to users.

Microsoft is facing a related version of the same issue. The company is reportedly winding down most internal Claude Code licenses and moving many developers toward GitHub Copilot CLI. Microsoft has described the decision as a move toward standardizing internal workflows, but reporting also indicates the decision has a financial component, with the cutoff aligned to the end of Microsoft’s fiscal year.

These examples are not evidence that AI coding tools do not work. They are evidence that AI usage, by itself, is not a strategy.

More tokens consumed does not mean more value created. More code generated does not mean more user problems solved. More prototypes do not mean more clarity.

The metric that matters is not how much AI a company used. The metric that matters is whether the product got better for the people using it.

Historically, organizations could hide mediocre product strategy behind the difficulty of execution. When building was slow, expensive, and constrained, the friction created time for debate. Bad ideas often died because they were too costly to pursue. Teams had to make choices. They had to prioritize. They had to ask whether something was worth the effort.

AI removes much of that friction.

That is powerful, but also dangerous. When the marginal cost of building goes down, the temptation to build everything goes up. Every feature request can become a prototype. Every executive idea can become a demo. Every workflow can get an AI layer. Every screen can get a chatbot. Every team can create another tool, another interface, another agent, another internal automation.

Without a strong architectural vision, the result is not innovation. It is accumulation.

The best metaphor for this may be the Winchester Mystery House in San Jose.

Sarah Winchester bought what began as a modest farmhouse and expanded it over decades into one of the most unusual mansions in America. The house eventually became a 160-room structure, known for its sprawling layout and architectural curiosities. The National Park Service describes how continual building and remodeling created a 160-room house spread across six acres. The Winchester Mystery House’s own history describes the home as growing from an eight-room farmhouse into a sprawling mansion with 10,000 windows, 2,000 doors, 47 stairways, 47 fireplaces, and 160 rooms. It also describes the expansion as having happened without a master plan.

That is exactly the failure mode companies should fear in the AI era.

A staircase here. A room there. A door that opens to nowhere. A hallway added because it was possible, not because it served a coherent purpose.

Software can become a Winchester House.

One team adds an AI assistant for support. Another adds an AI summarizer for internal workflows. Another creates a code generation pipeline. Another builds an agent for operations. Another creates a new interface for analytics. Another launches a conversational experience because “we need an AI strategy.”

Individually, each addition might make sense. Collectively, the system becomes incoherent.

That is how companies end up with sprawling software architecture, duplicated workflows, unclear ownership, rising operational costs, and user experiences that feel more complicated rather than more useful. The company is moving faster, but the product is not becoming clearer. The organization is producing more, but users are not getting more value.

The problem is not the hammer. The problem is the absence of a blueprint.

This is why the old product maxim needs to be reconsidered. “Ideas are cheap, execution is everything” made sense when execution was the hardest part. But in a world where execution is increasingly automated, the value shifts upstream.

The scarce resource becomes judgment.

That judgment includes knowing which problems are real. It includes understanding user needs deeply enough to separate expressed wants from actual pain points. It includes knowing when a workflow should be automated, when it should be simplified, and when it should be eliminated entirely. It includes having the discipline to say no, even when saying yes has become cheap.

This is a major change for companies.

Many organizations have built operating models around execution scarcity. Roadmaps are often treated as lists of things to produce. Success is measured by output: features shipped, tickets closed, releases completed, experiments launched. AI fits easily into that mindset because it promises more output.

But more output is not necessarily better product development.

The real question is not whether AI helped a team ship faster. The real question is whether the team shipped the right thing.

That is where many current AI metrics are insufficient. Token consumption, AI tool usage, prompt volume, generated lines of code, and number of active seats may be useful operational signals. They tell a company something about adoption, cost, and behavior. But they are not outcome metrics.

No user cares how many tokens were consumed.

A rider does not care how many coding agents contributed to a new Uber feature. A driver does not care whether a workflow was generated by Claude Code, GitHub Copilot, OpenAI Codex, or a human engineer. A customer does not care how many internal demos were created. They care whether the experience is faster, clearer, safer, cheaper, more reliable, or more useful.

That should be the measurement standard.

If AI is helping a company, it should show up in user outcomes. It should reduce friction. It should improve task completion. It should increase confidence. It should reduce time to resolution. It should make discovery better. It should improve relevance. It should eliminate unnecessary work. It should help users make better decisions with less effort.

If the only thing going up is token usage, the company is not measuring value. It is measuring fuel consumption.

And fuel consumption is not the same thing as progress.

This is where AI forces a strategic reckoning. The companies that win will not simply be the companies that generate the most code. They will be the companies that pair accelerated execution with disciplined direction.

That requires a different kind of operating system.

1. First, companies need sharper problem definition. Before building, teams need to identify the user problem with precision. Who is the user? What are they trying to accomplish? Where does the current experience fail? What evidence do we have? What behavior are we trying to change? What outcome would prove that we helped?
2. Second, companies need stronger product architecture. AI makes it easy to create local solutions, but products are systems. Every new capability has to fit into a larger experience. If teams are not careful, AI features will multiply across the product like disconnected rooms in a mansion with no floor plan.
3. Third, companies need better prioritization. The fact that something can be built quickly does not mean it should be built. In fact, as building becomes easier, prioritization becomes more important. The opportunity cost is no longer just engineering time. It is user attention, product complexity, operational burden, maintenance cost, and strategic focus.
4. Fourth, companies need outcome-based measurement. AI adoption should be tied to product and business outcomes, not just internal activity. The right measures depend on the product, but the principle is consistent: measure the user benefit, not the tool usage.
5. Finally, companies need to preserve human judgment at the right layer. AI can assist with implementation, exploration, summarization, synthesis, testing, and iteration. But someone still has to decide what matters. Someone still has to understand the user. Someone still has to hold the product vision. Someone still has to say, “This is not worth building.”

The irony of AI-assisted development is that it may make product strategy more valuable than ever. When everyone can build faster, speed alone becomes less differentiating. The differentiator becomes the quality of direction.

A company with weak strategy and powerful AI will create more weak output. A company with strong strategy and powerful AI can compound its advantage.

The differentiator becomes the quality of direction.

The frontier tools may be impressive. The demos may be real. The productivity gains may be meaningful in specific contexts. But none of that eliminates the need for clear product thinking. The burden used to be building. Now the burden is knowing what to build.

That shift should change how companies talk about AI.

• The goal should not be to maximize AI usage. The goal should be to maximize user value.
• The goal should not be to celebrate token consumption. The goal should be to connect AI investment to better experiences.
• The goal should not be to produce more software. The goal should be to produce software that matters.

The Winchester House is memorable because it is fascinating, strange, and chaotic. It is a marvel of endless construction. But it is also a warning.

A system can be impressive and incoherent at the same time.

That is the risk facing companies now. AI gives us the ability to build more rooms, faster than ever. But without a plan, without a clear understanding of user needs, and without disciplined measurement, we should not be surprised when we end up with doors that open to nowhere.

In the next era of software, the question is not “Can we build it?”

Increasingly, the answer will be yes.

The more important question is:

“Should we build it, and how will we know it helped?”

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.