From Vertical Depth to Horizontal Expansion in the AI Era: A Guide to Shifting Developer Mindset

Fear or Excitement? Developers at a Crossroads in the AI Era

Over the past few years—especially in recent months—the way software is built has fundamentally changed. Many engineers, upon seeing the power of AI tools, react first with fear: work that once took hundreds of hours can now be done in 15, 10, or even fewer. Does this mean developers will have nothing left to do?

Prominent developer Theo offered a strikingly different answer at the CascadiaJS conference: It's not about doing less—it's about doing more, and doing it bigger. This isn't a discussion about specific tools. It's about a fundamental shift in mindset—how we should rethink "what's worth building."

A Mirror to History: Lessons from the Cloud Computing Revolution

To understand AI's impact on the software industry, the best analogy is the rise of cloud computing.

Before the cloud, building software was an extremely capital-intensive endeavor. You had to predict traffic, then purchase and configure physical servers. Underestimate, and your servers crash. Overestimate, and you waste a fortune. This meant experimentation was inherently expensive—the risk of trying new ideas was terrifyingly high.

To appreciate just how expensive, consider the world before cloud computing. Before AWS launched EC2 (Elastic Compute Cloud) in 2006, companies had to perform "Capacity Planning"—estimating peak traffic months or even years in advance, then purchasing server hardware in bulk. This involved not only hundreds of thousands of dollars in upfront investment but also dedicated data center operations teams handling cooling, power, network cabling, and other physical-layer concerns. A startup might need to burn through hundreds of thousands of dollars on infrastructure just to validate a single idea.

Cloud computing changed everything. You could start small and scale on demand. The "Auto Scaling" and "Pay-as-you-go" models introduced by AWS, Azure, GCP, and other cloud platforms slashed startup infrastructure costs from hundreds of thousands of dollars to just a few dollars. You no longer needed top-tier infrastructure engineers to try out a new idea. Amazon-scale capabilities suddenly became accessible to people without Amazon-scale teams or purchasing power.

The result? From Slack to Salesforce, countless software products emerged that simply couldn't have existed in an era where you couldn't easily scale on demand. Cloud computing didn't eliminate engineering jobs—it created an entirely new software ecosystem.

AI Is the New Cloud Computing: Disrupting the Cost of Human Capital

Now, replace "servers" with "engineers" and walk through the same logic.

Before AI tools, building software was equally capital-intensive—you needed to hire enough engineers. You had to predict the future: what if your iOS app turns out to be more popular than Android, but you've hired four-person teams for both platforms? What if users only want the web version and nobody uses mobile—what do you do with those engineers?

Theo candidly shared a pain point that few people talk about: the social cost of experimentation. You hire people to build something, they execute flawlessly, but you discover the direction was wrong—and then you have to lay them off. This experience makes people hesitant to take bold bets, because when the gamble fails, real people get hurt.

Now, AI tools have completely changed this equation. You can build Amazon-scale software with a much smaller team, and the cost of experimentation drops dramatically. This means:

• How we plan projects needs to be rethought
• Team structures and hiring models need to be redesigned
• The criteria for what's worth building and what isn't need to be recalibrated

The Salesforce Paradox: Why Challenging Giants Suddenly Became Feasible

Theo used Salesforce as a compelling example to illustrate how the competitive landscape is shifting in the AI era.

As the world's largest CRM (Customer Relationship Management) platform, Salesforce's product strategy deeply embodies the "feature long tail" phenomenon in enterprise software. This aligns closely with Chris Anderson's "Long Tail Theory"—a small number of core features satisfy most users, but a massive number of edge features each serve a tiny fraction of customers. If you rank these features by usage, you'll find an interesting distribution: a small set of core features that every customer needs (authentication, email notifications, etc.), another set that large companies need but aren't universally essential, and roughly 70% of features that fewer than 1% of users actually use.

But here's the problem: if you're a Salesforce competitor and a potential customer needs 12 features, you already support 10 of them—and your 10 are better—but the 2 you're missing are enough to prevent them from switching. This feature distribution creates powerful "Switching Costs" and "Vendor Lock-in": the custom workflows, Apex code, third-party integrations, and historical data that enterprises accumulate on Salesforce make the actual cost of migrating to a competitor far exceed the subscription fee itself. This is why Salesforce can maintain gross margins above 75%—even dissatisfied customers find it extremely difficult to leave.

In the past, there were only two ways to solve this problem:

1. Build a complex extension architecture and let customers solve it themselves (they won't bother for an unproven product)
2. Hire a massive team to try to cover every feature (a suicide mission—you'll run out of money before you finish)

This is why, for the past 20 years, the standard startup strategy has been to pick a vertical and go deep—just as Vercel beat AWS in the full-stack web hosting vertical. Vercel's success is a textbook case of the "vertical disruption" strategy: AWS offers general-purpose infrastructure—EC2, S3, Lambda, and hundreds of other service components that developers must assemble themselves; Vercel focuses on a single scenario—full-stack web applications—and built a complete experience around the Next.js framework, from development to deployment, including automated CI/CD pipelines, Edge Network distribution, Serverless Functions, Incremental Static Regeneration (ISR), and more. In the startup world, this strategy is known as "Unbundling"—extracting a vertical slice from a giant's sprawling product matrix and redefining it with a 10x better experience.

From Vertical Depth to Horizontal Expansion: A New Paradigm for Software Development

But AI has changed this equation. Theo proposed a bold thesis:

Building a horizontal solution that "works across every category but isn't perfect in any" suddenly makes far more sense than it used to.

The key insight is this: if you can cover a wide enough range of features while designing your architecture so users can go deep where they need to—then a "broad but shallow" strategy suddenly becomes viable. In the past, this strategy would fail because you simply didn't have enough engineering resources to cover that breadth. Now, AI brings that cost down to a manageable level.

There's clear economic reasoning behind this shift. In the traditional model, each additional feature module requires hiring dedicated engineers, conducting code reviews, writing tests, and maintaining documentation—marginal costs are nearly linear. AI tools flatten this cost curve: the 11th feature module might cost only one-tenth of the first, because AI can reuse patterns and auto-generate boilerplate code and tests. This is similar to "economies of scale" in economics, but the driving force isn't increased production volume—it's a technological compression of unit production costs. When marginal costs are low enough, covering a wider range of features becomes commercially viable, even if the depth of each feature doesn't match that of a focused competitor.

This shift from vertical depth to horizontal expansion is essentially the inevitable result of AI lowering the marginal cost of software development.

The Lakebed Experiment: A Bold Attempt to Boil the Ocean

Theo used his own product, Lakebed, to concretely illustrate how this thinking plays out in practice.

Lakebed's positioning is intriguing—"a crappy cloud for crappy apps." It sounds self-deprecating, but the logic behind it runs deep.

The starting point is this: AI has shortened building an app from 30–40 hours to 30 minutes, but deployment still takes 3 hours. Authentication, database configuration, environment setup, various tokens—the work in this "glue layer" hasn't changed, yet it's gone from less than a tenth of total time to the bottleneck of the entire workflow.

The so-called "Glue Layer" is a seriously underestimated cost center in modern software development. When developers use multiple independent SaaS services (such as Auth0 for authentication, Supabase for databases, Vercel for deployment, and Stripe for payments), the configuration, adaptation, and debugging work required to make these services work together often accounts for 30%–50% of total development time. Each service has its own SDK, configuration format, environment variable naming conventions, and error handling patterns. The OAuth 2.0 authentication flow is a classic example—although the protocol itself is standardized, correctly implementing callback URLs, token refresh, and session management across different frameworks and platforms remains one of the most common sources of developer frustration. AI has shortened the time to write business logic, but it has caused the relative proportion of this integration work to spike dramatically, making it the new bottleneck.

Theo's initial approach was to build "glue solutions"—like Shoe (a Google Auth proxy that reduces authentication to two lines of code) and the earlier UploadThing (simplifying file uploads). But he quickly realized that every time he fixed one layer of glue, the next layer broke. He was perpetually living in the gaps between different vertical services, because these services were never designed to integrate with each other.

So he made a radical decision: stop patching the gaps and reinvent everything.

• His own framework
• His own runtime
• His own cloud platform
• His own bundler (one that can bundle without even needing a file system)
• His own database primitives

The code itself becomes the deployment instruction. In his demo, he used Cursor Agent to build and deploy 10 applications from scratch in about 8 minutes—to-do lists, voting systems, recipe managers, and more—all with Google one-click login and real-time sync. Cursor is an AI-native code editor built on VS Code, and its Agent mode represents the latest paradigm in AI-assisted development. Unlike traditional code completion (such as GitHub Copilot's Tab completion), Agent mode allows developers to describe their intent in natural language, and the AI autonomously plans execution steps, creates and modifies multiple files, runs terminal commands, reads error logs, and auto-fixes issues—essentially an autonomous agent that can operate the entire development environment. This mode shifts the developer's role from "writing code line by line" to "describing intent and reviewing results," similar to switching from manual driving to supervised autonomous driving.

Core Takeaway: Push Until You Hit the Wall

Theo admitted that the original motivation for building Lakebed wasn't to ship a successful product—it was to find where the wall is—at what point does the "boil the entire ocean" strategy break down?

What shocked him was: the wall never appeared. The further he went, the more real and viable the project became.

This is the core message he wanted to convey:

Developers are still using AI tools to automate the work they used to do, without realizing that AI actually enables entirely different kinds of work.

If you're not attempting things that "used to be impossible," you're not truly leveraging these tools. Find that idea in your head that "shouldn't be possible," and keep pushing until you hit the wall. You'll be surprised at how far away that wall is.

Conclusion: It's Not About Writing Less Code—It's About Building Bigger Systems

The core of this article isn't about any specific tool or product—it's about a shift in mindset. Just as cloud computing didn't eliminate engineers but created entirely new categories of software, AI won't eliminate developers—it will enable us to build things we previously wouldn't have dared to imagine.

The key isn't "use AI to write less code"—it's "use AI to build bigger systems." From vertical depth to horizontal expansion, from patching gaps to reinventing from scratch—this may be the most important mindset shift of our era.