The Work

This book has been tracking a single force as it moves through layers. Features commoditize. Teams reorganize around factory infrastructure. The individual role compresses to judgment. The previous chapter laid out six concrete implications — changes to budgets, metrics, hiring, and strategy that follow from the industrialization thesis. Those implications all assume that software companies are still, fundamentally, software companies. They sell the tool.

This chapter asks what happens when that assumption breaks.

Stripe merges a thousand agent-written PRs a week. But Stripe sells payments, not pull requests. The factory's output isn't the product. The product is the work those PRs enable: moving money, reconciling accounts, catching fraud. The pull request is overhead.

Julien Bek at Sequoia published a piece arguing that the next trillion-dollar company will be a software company masquerading as a services firm. Not selling the tool. Selling the work. I've been writing about what happens when code gets cheap. Bek is writing about what happens next: the work itself gets cheap enough to sell directly.

The factory makes the wrong thing

But software was always a proxy. Nobody buys Salesforce because they love databases. They buy it because managing customer relationships by hand is slow and error-prone. The software automates the work. What happens when AI can do the work without the software?

That's the next domino. The factory stops producing software-as-product and starts doing the work that software was built to enable. The production line turns outward.

The pattern is visible if you squint at the last twenty years of SaaS. Every successful software company was really an arbitrage on human labor — taking something that required people (bookkeeping, customer management, project tracking, design iteration) and replacing it with a tool that made fewer people necessary. The tool was never the point. The reduced headcount was the point. AI removes a step from the arbitrage: instead of selling a tool that makes the work cheaper, sell the completed work directly.

Copilots and autopilots

Bek draws a clean line. A copilot sells the tool. An autopilot sells the work.

Harvey sells AI to law firms. The lawyers use it, the lawyers take responsibility, the lawyers bill the client. That's a copilot. Crosby drafts NDAs for the company that needs them, not for outside counsel. WithCoverage sells insurance to the CFO, not to the broker. The professional is no longer the customer. The professional is the cost being removed.

For every dollar companies spend on software tools, they spend six on services — on the people doing the work the tools were supposed to make easier. Copilots capture the tool budget. Autopilots capture the work budget.

The operational difference between copilots and autopilots is sharper than it sounds. A copilot augments a human workflow: the lawyer still reads the brief, the engineer still reviews the PR, the accountant still signs off on the reconciliation. The tool makes them faster, but the human remains in the loop and owns the outcome. An autopilot removes the loop. The customer specifies what they want — "close the books," "draft the NDA," "find me a policy that covers this risk profile" — and the system delivers a finished result. No professional in the middle. No tool the customer needs to learn.

This distinction maps directly onto the business model. Copilots price like software: per seat, per user, per month. Autopilots price like services: per outcome, per transaction, per deliverable. The economics are different by an order of magnitude. If you're selling a $50/month copilot seat to a law firm, you're competing for the tool budget. If you're selling completed NDA drafts at $200 each, you're competing for the work budget — which is six times larger.

I've spent time onboarding people to AI tools across two companies. That's copilot work. I teach someone to use Claude Code, they get faster, they own the output. The autopilot is what happens when the customer never touches the tool. They're buying the outcome.

The wedge is outsourcing. If a task is already outsourced, the buyer has already accepted three things: the work can be done externally, there's a budget line for it, and they're purchasing an outcome. Replacing an outsourced vendor with an AI-native service is a vendor swap. Replacing headcount is a reorg. Vendor swaps close in weeks. Reorgs take quarters and require executive sponsorship. That's where autopilots start — not by disrupting employment, but by eating outsourcing contracts. The politics are simpler. Nobody inside the company loses their job. A line item on a vendor spreadsheet just gets cheaper.

The addressable markets are in the hundreds of billions — insurance brokerage, accounting, healthcare billing, IT managed services — and those are just the categories where the outsourcing wedge already exists.

Intelligence and judgment

Bek splits work into intelligence and judgment. Intelligence is rule-following at scale: translating a spec into code, coding clinical notes into ICD-10 categories, filling out insurance applications. The rules are complex, but they are rules. Judgment is knowing which spec to write, which diagnosis matters, whether the policy actually fits the client's risk profile. Experience and taste built over years.

This maps onto the defensibility matrix from Chapter 1 with uncomfortable precision. Intelligence work lives in the upper-left quadrant: digital, copyable, commodity. It's the same quadrant where features live. Judgment work lives on the right side: built on accumulated experience, embedded in relationships, resistant to replication. The stuff you can't paste into a prompt.

The parallel is worth pausing on. Chapter 1 argued that features are indefensible because they're digital and copyable — anyone with factory tooling can rebuild them. Intelligence work is indefensible for exactly the same reason. The rules, however complex, can be encoded. An agent that processes insurance applications is doing intelligence work: following elaborate rules at speed and scale. That work is valuable, but it's commodity valuable. Any competitor with the same model access and domain rules can replicate it. The defensible part — the judgment about whether the application makes sense for this client, this risk profile, this market condition — sits in the right-hand column of the matrix. It's accumulated, embedded, and hard to copy.

The higher the intelligence ratio in any field, the sooner autopilots win. Software engineering got there first. Over half of all professional AI tool usage is in software development. Every other category is still in single digits. That's why the factory exists in our industry before it exists anywhere else.

But here's the complication I keep running into in practice. The factory is excellent at intelligence work. An agent can write correct code, pass tests, ship a PR. The gap between "agent writes correct code" and "agent knows what the customer actually needs" is the judgment gap.

The blank input problem

I've seen this gap in every onboarding session I've run. The primary blocker is never model quality or cost. It's what I've started calling the blank input problem: people stare at an empty chat and freeze. They don't know what to ask.

A PM with access to the best tools in the world sits there with a blinking cursor because specifying intent — knowing what you actually want, clearly enough for a machine to do it — is judgment work. I watched a Center of Excellence with 65 people at a major enterprise where everyone had tool access and nobody knew what to hand off. The tools can do the work. The bottleneck is knowing what work to hand them.

This is more revealing than it appears. We tend to assume that the hard part of work is execution — the doing. The blank input problem exposes that a significant portion of what professionals do isn't executing tasks but figuring out what the tasks should be. A lawyer doesn't just draft contracts; she decides which clauses matter for this deal, this counterparty, this jurisdiction. An engineer doesn't just write code; he determines which technical approach fits the constraints he's learned to see through years of watching systems fail. Strip away the execution and what's left is a person staring at a blank prompt, realizing that the execution was the easy part all along.

The blank input problem also reveals something about how professional expertise actually works. Most experts can't articulate what they know — their judgment is embedded in thousands of micro-decisions they've internalized to the point of automaticity. Ask a senior engineer why she chose one database over another and she'll give you a reason. Ask her to enumerate all the factors she weighed, in order, with confidence levels — the kind of specification an agent would need — and she stalls. The knowledge is real. It's just not in a format that transfers to a prompt.

Internally, that's an onboarding problem — you can train people to decompose their work into handoff-ready chunks. Externally, it's an existential one. The autopilot company has to solve the blank input problem for every customer in their domain. They have to encode enough judgment about what "good" looks like that the customer can say "close the books" and walk away. That's a harder problem than building the agent.

And it's the problem where the defensibility actually lives. The autopilot that can accept "close the books" as a complete input has encoded a massive amount of domain judgment — what accounts to reconcile, which discrepancies matter, what the regulators expect, how this company's chart of accounts differs from the standard template. That encoded judgment is the moat. It took years of accumulated data and operational experience to build. A competitor can clone the agent infrastructure in a weekend. They can't clone the judgment layer.

Today's judgment becomes tomorrow's intelligence. As autopilots accumulate proprietary data about what good work looks like in their domain, they build exactly the data flywheel I described in the first chapter. Crosby processes thousands of NDAs. Each one teaches the system what "good" looks like for that contract type, that industry, that jurisdiction. The autopilot doesn't become defensible through its code. Code is commodity. It becomes defensible through accumulated judgment-data, the same way Google's search quality compounds through usage data. The right-hand column of the matrix, built one transaction at a time.

What the factory changes

This series tracked what AI does to products, teams, individuals, and production. The business model is the last domino.

The factory doesn't just change how software gets built. It changes what software companies are. The trillion-dollar outcome Sequoia is betting on is a software company that looks like a services firm: AI-native infrastructure doing the work that armies of professionals used to do, priced on outcomes, not seats. This book explains why the timing works. The factory makes code free. Free code makes features free. Free features make the tool layer commoditize. And when the tool layer commoditizes, the value migrates to the work the tools were supposed to enable.

The copilot companies face a classic innovator's dilemma during this migration. Harvey sells to lawyers. Rogo sells to investment banks. Their customers are the professionals. To become an autopilot means selling the work directly to the company, which means the professional — your current customer — is now your competitor. You're cutting them out. The fastest-growing AI companies in 2025 were copilots. Many are now trying to become autopilots. They have the product knowledge and the customer relationships. But the transition means cannibalizing the people who pay you.

The professionals using copilots are the steersmen of their industries — still steering, still reviewing, still signing off. The autopilot is what comes after the steersman. And the steersman, understandably, doesn't want to hear that. If you're Harvey and your best customers are the lawyers who adopted your tool earliest, telling them "actually, we're going to sell legal work directly to your clients" is a conversation that ends the relationship. The pure-play autopilots skip this conversation entirely because they never had it to begin with.

That's the opening for pure-play autopilots — companies that start by selling the work from day one, without a copilot customer base to protect. Crosby didn't start by selling to law firms and then pivot. They went straight to the company. WithCoverage went straight to the CFO. They don't face the dilemma because they never had the professional as a customer in the first place.

The uncertainty is the judgment question. Bek's entire framework rests on the intelligence/judgment split holding long enough for autopilots to accumulate the data that lets them handle judgment too. I've been honest throughout this book that the layers keep collapsing. Problem selection, constraint definition, drift correction. Each was supposed to be durably human. Each is partially automating. If judgment automates faster than expected, the autopilot doesn't just replace the outsourced worker. It replaces the firm that replaced them. And then it replaces whatever replaced that.

The factory made the guns faster. Now it's aiming them for you.