Eat the Software Eating the World

A case for the end of the interface era and the beginning of everything else.

In 2011, Marc Andreessen told the world that software was eating it. He was right. What he didn't say—what none of us could have said then—is that the thing doing the eating would eventually need to be eaten itself.

We spent the better part of two decades building the most complex, most layered, most dense information architecture in the history of civilization. We scaffolded nearly every meaningful workflow in the modern economy onto screens. We gave every department a dashboard, every process a platform, every task a tool. We did it because it worked. Because it was better than paper and phone calls and filing cabinets. Because, for a while, the alternative to software was chaos.

But somewhere along the way, the alternative to chaos became its own kind of chaos. And now we sit inside it, fourteen browser tabs deep, wondering why productivity still feels like war.

The Context Problem

Here is the truth about modern B2B software that nobody in enterprise sales will tell you, but that every human being who has ever been onboarded at a company with more than fifty employees already knows:

There is too much of it. And it is too hard to use. Not because any single application is particularly bad—many of them are, in fact, quite good—but because the sheer accumulation of them has crossed a threshold that the human mind was never designed to manage.

Look at any sophisticated, multi-year software stack built by a real engineering team, and you will find the same set of problems repeating themselves like a geological record. The information density is too high for any one person to navigate. Even when it's been simplified, minimized, segregated, and compartmentalized for different organizational views—I'm looking at you, Salesforce—it's still too complicated. And yet we are expected, as human beings, to memorize seventeen different click paths, learn N+1 interface patterns across however many tools we're forced to juggle, and still manage the execution of whatever core task we're actually paid to do.

This is not a design problem. This is not a training problem. This is a category problem. The entire premise—that humans should spend their working lives navigating other people's interfaces—is the thing that's broken.

Jeff Bezos, in his 2020 shareholder letter, borrowed a passage from Richard Dawkins about how living organisms must constantly work to maintain their distinctiveness against the pull of entropy. The body, left to itself, reverts to equilibrium with its surroundings. It cools. It dissolves. It dies. Bezos used this as a metaphor for companies, and it is a good one. But it applies just as well to the humans inside those companies. Every hour spent context-switching between applications, re-orienting inside unfamiliar interfaces, searching for the right tab or the right field or the right dropdown—that is entropy winning. That is the universe smoothing you into your surroundings. You are not doing your job. You are navigating the tools for your job. And the distinction matters enormously.

The Bolted-On Agent

Every major B2B software provider now has an "agent" of some kind. They have bolted artificial intelligence into their existing products the way you bolt a spoiler onto a sedan—it looks faster, but the engine hasn't changed.

These agents still require you to log in. They still require you to ask questions within the context of that specific tool. They still require you to navigate the existing interface, only now with a slightly more conversational companion riding along in a chat window. The agent helps you use the software. It does not eliminate the need to use the software. And that is the fundamental failure of imagination at work.

My argument is this: the problem was never that the software was hard to use. The problem is that we have to use too much software.

It's a distinction that sounds subtle but is actually seismic. And it echoes something Simon Sinek has spent years articulating in a different context: the difference between what and why. The B2B industry has spent a decade optimizing the what—better features, cleaner UIs, more powerful dashboards. But it has never seriously asked why a human being should have to interact with twelve different applications to do a job that, in its essence, might be described in a single sentence.

"Process this quarter's invoices." "Draft a response to this RFP." "Summarize last week's customer escalations and flag the ones that need executive attention." These are tasks. They have inputs and outputs. The fact that fulfilling them currently requires a human to manually traverse half a dozen platforms, pulling context from each, reformatting it for the next—that is not an inherent feature of the work. That is an artifact of how we built the tools. And artifacts can be replaced.

A Glimpse of What Replaces Them

For those of us in the technical world, the replacement has already arrived. It just hasn't been distributed evenly.

If you are an engineer working inside a properly configured IDE—Claude Code or Cursor, backed by a suite of well-architected MCPs, with a meticulously maintained project file—you have already tasted what comes next. You provide a well-formatted nudge in a specific direction, and without much labor, the code is written, the logs checked, the migrations applied, the tests tested. You have a functioning artifact. Not a plan for one. Not a ticket describing one. The thing itself.

This experience is the closest thing to magic that many of us have encountered in our professional lives. And the reason it feels magical is not because the AI is particularly brilliant—though it is increasingly capable—but because for the first time, the gap between intent and execution has collapsed to nearly zero. You say what you want. It happens. The interfaces, the tools, the configurations—they are still there, underneath, doing real work. But you no longer have to be the one navigating them.

Dan Fein at Vercel described this trajectory well: building agents should feel like shaping an idea rather than fighting a maze of code or infrastructure. The earliest AI features were simple—pick a provider, call an API, stream a response. But real products need something more: the ability to swap models, handle rate limits, call multiple providers, reconcile billing, and most importantly, evolve from a single prediction into a loop that thinks over time, pulls in context, chooses tools, and tries again when it isn't satisfied.

This is not a chatbot. This is a new kind of worker. And the infrastructure to support it—model routing, elastic compute, durable workflows—already exists, at least for those who know where to find it.

The Rest of Us

But here is the uncomfortable truth that the technical community has not yet reckoned with: for the vast majority of working professionals, none of this exists yet.

If you are not an engineer. If you do not live inside a perfectly configured IDE. If you have never heard of an MCP, let alone configured one. If your daily work happens across Salesforce and HubSpot and Slack and Google Sheets and a half-dozen other applications that do not talk to each other—then the AI revolution, so far, has handed you a slightly better autocomplete in your email client and a chatbot that hallucinates your company's pricing page.

This is the gap. And it is the most important gap in technology right now.

The Vercel team discovered something instructive when they turned this lens inward: the strongest near-term wins came not from the most technically ambitious agents, but from the most mundane ones. They asked each team what part of the job they liked least. What repetitive task they wished they never had to do again. The answers mapped directly to agents that now save real time. A support agent that cut tickets by a third. An abuse detection agent that runs visual analysis on flagged URLs. A content agent that turns Slack threads into draft blog posts.

The shared pattern is time returned to the team. Not intelligence replaced. Time returned. The work still requires human judgment. But the scaffolding around that judgment—the context-gathering, the formatting, the cross-referencing, the first drafts—has been automated away.

Now imagine that pattern applied not to a team of developers at a platform company, but to an accounts receivable clerk. A regional sales manager. A compliance officer at a mid-size bank. A school administrator trying to file state reports.

Cursor for Everyone Else

Some have started calling this idea "Cursor for Everyone Else." We call it something different, but the name doesn't matter. The idea does.

The idea is this: there exists a universe where non-technical human beings get the same order-of-magnitude productivity boost that technical engineers are already experiencing. Where the gap between intent and execution collapses for everyone, not just for people who can write a prompt in natural language that happens to compile.

This is a harder problem to solve than the engineering version, for several reasons.

First, engineers like to build for problems they understand well. The result is dozens of excellent agentic applications for developer workflows—and comparatively few for the fuzzy, cross-application, permission-laden world that everyone else inhabits.

Second, the "working model" of a non-technical professional is fundamentally different from the working model of an engineer. An engineer operates primarily within a single environment—the IDE—that has deep, structured access to the codebase, the terminal, and the deployment pipeline. A sales operations manager operates across Salesforce, Outreach, Gong, Slack, Google Sheets, and their company's internal wiki, each with different authentication, different data models, different UIs, and different permissions. The surface area is enormous and heterogeneous.

Third, and most critically, the user experience for this kind of tool has not been formalized. Think of the number of different, highly opinionated layouts across every imaginable B2B application. There is no equivalent of the IDE—no single environment that already serves as the natural home for cross-application work. The closest thing most people have is their browser, and a browser is not an agent. It is a window.

The Geological Clock

Kathryn Schulz, in her reporting on the Cascadia subduction zone, described a concept that has stayed with me: temporal parochialism. It's the tendency to assume that the pace of our own lives is the pace of the world. We struggle to think on geological timescales because our individual allotment is three score years and ten, and everything beyond that feels abstract.

Technology has its own version of temporal parochialism. We tend to assume that the current shape of the software industry—its categories, its interfaces, its business models—represents something durable, something close to a final form. But it doesn't. We are living on a fault line, and the tectonic plates are already in motion.

The Cascadia zone stayed hidden because we couldn't see deep enough into the past. The collapse of the interface era will catch many people off guard because they can't see far enough into the future. The data is there. The tremors are visible. Engineers who use agentic tools daily have already felt the ground shift. But the broader market—the 98% of B2B SaaS that still operates on the assumption that humans will navigate interfaces forever—hasn't yet internalized what's coming.

This is not a prediction about next quarter. It is a prediction about the next decade. And in a decade, I believe the idea that a human being should memorize click paths and navigate dashboards to do knowledge work will seem as archaic as the idea that a human being should hand-calculate payroll.

What Gets Built

Andreessen's techno-optimist manifesto was, above all, an argument about the direction of the arrow. Technology makes things better. Markets allocate that improvement broadly. The upward spiral continues. I believe he is right about the direction, even if I think the manifesto's rhetoric sometimes mistakes volume for precision.

But the relevant insight for our current moment is more specific. Andreessen wrote that there is no material problem—whether created by nature or by technology—that cannot be solved with more technology. The problem of too much software is, itself, a problem created by technology. And it will be solved by technology. Not by simplifying the software. Not by consolidating vendors. Not by training humans to navigate faster. By eliminating the navigation entirely.

What gets built is a layer that sits between the human and the tools. Not another tool. Not another dashboard. Not another agent bolted onto an existing product. A layer that understands what you're trying to accomplish, has access to the systems that contain the relevant data, and can execute the work—or at least draft it for your review—without requiring you to touch any of those systems directly.

Bezos was fond of saying "It remains Day 1." The implication was that the real work of building was always just beginning, that complacency was death, that the most important inventions were always ahead. For this particular problem—the problem of too much software, of too many interfaces, of human beings drowning in the tools that were supposed to save them—it is very much Day 1.

The ground is moving. The question is not whether the old architecture will fall. It's whether we'll have built the new one before it does.

A Note on What This Isn't

I want to be precise about what I am not arguing.

I am not arguing that all software will be replaced. AI-generated video will not replace the human connection of photos shared by people you love. Random LLM agents will not be handling transport protocols for encrypted data signals between network layers. There is a place for the infrastructure we've built—a permanent, essential, load-bearing place.

But I'd argue that 98% of most B2B SaaS, and a very healthy percentage of consumer applications, can either be entirely replaced or at the very least eaten by something better. Something that starts with the human's intent rather than the software's interface. Something that treats the complexity of modern work as a problem to be solved on behalf of the worker, not by the worker.

The Brief Lab's Joe McCormack once framed it simply: "The most important question is 'Why am I here?'" It's the question every worker asks, silently, halfway through their third hour inside a tool that exists to serve them but increasingly feels like the other way around.

We have the technology to answer that question differently now. We have the models, the infrastructure, the frameworks. What we lack is the will to let go of the assumption that the interface is sacred—that the dashboard is the product, that the click path is the workflow, that the human must always be the one doing the navigating.

Software ate the world. It did its job. The world is better for it.

Now something else is hungry.