A response to Julien Bek’s Services: The New Software (Sequoia, March 2026). Bek’s framing is one of the cleanest pieces of writing about the autopilot wave so far. It’s also a snapshot of a moving target, written by an actor with a vested interest in the snapshot staying still. Both can be true.

The thesis Bek is selling

The next $1T company, Bek argues, will be a software company masquerading as a services firm — selling not the tool, but the work itself, finished.

The core distinction:

  • Intelligence (rules, translating spec to code) — AI can now do this autonomously.
  • Judgment (experience, taste, strategy) — stays with humans.
  • Copilot sells the tool to a professional. Harvey to law firms.
  • Autopilot sells the result directly to the buyer. Crosby to companies that need an NDA.
  • “For every dollar spent on software, six are spent on services.” — entry wedge through outsourced work.

It’s a clean frame, and a useful one. It also has three structural problems that don’t show up at this resolution, and this post is about those three.

The three angles don’t carry equal weight, so I’ll say upfront where I’m spending it. Angles 2 and 3 are points about Bek’s market that someone was going to make sooner or later. Angle 1 is the reason I sat down to write this. It isn’t analysis of the autopilot market from the outside — it’s about whoever is reading this. If you’re building a personal agentic stack, “autopilot” isn’t a category to invest in. It’s a fairly literal description of what you’re already turning into. So angle 1 gets the space; the other two are here mostly to set it up.

Angle 1 — Autopilot is a B2B wrapper over the agentic solo engineer

If you look at an early-stage autopilot startup as an organism rather than a corporate form, something interesting happens. It looks structurally identical to what I’ve been calling the agentic solo engineer — a single human running their work through an agentic stack — except that it sells the finished work to a B2B market instead of selling itself on the labor market.

The line between “one person with agents” and “an autopilot company” isn’t qualitative. It’s legal, and it’s a question of scale. One is a freelancer with an agentic stack who sells executed work as a service. The other is a startup with the same stack selling the same executed work under a brand and an SLA. Same stack, same metabolism, different wrapping.

Three things follow from this once you’ve seen it.

The first is that the product-or-service question dissolves. If you’re an agentic solo engineer agonizing over whether to make a product or sell a service, you’ve already answered it: you’re running a service, and every client task is a unit of sale. The only thing left to decide is whether you package that work into something repeatable or keep doing it bespoke.

The second is that those weirdly-small autopilot startups stop being weird. Bek is describing companies of two or three people that pull revenue you’d expect from a services firm of dozens. That’s not an unusually efficient team — it’s a solo engineer plus a co-founder plus one operator. The scaffolding is the solo practitioner’s; what we’re calling a “company” is mostly the contract paperwork sitting on top of it.

The third is that the career path changes shape. It stops being “freelance, then join a startup, then climb to a senior role,” and becomes: freelance with agents, then a paid subscription from a handful of clients, then your first operator, then your own autopilot. That isn’t a thought experiment — the companies in Bek’s piece have walked it, each from a slightly different starting point.

The transition itself doesn’t happen when you hire someone. It happens the first time you put a second copy of your agentic stack into someone else’s hands. That’s the moment your .claude/, your MCP servers, your delegation habits stop being personal tooling and start being the operating system of a company. Everything after that is adding operators, not rebuilding the stack.

Which reframes what you’re doing right now. If you’re building a personal agentic stack, you’re not building a productivity setup and you’re not building a “personal practice” — you’re building a prototype of an autopilot company. Most of what you put in — the configs, the skills, the review loops — carries over intact when the transition comes. The hook you set up “just for myself” is really the first version of a production function for a company that doesn’t exist yet.

The same picture, flipped, names a failure mode: founders who never built their own agentic stack by hand tend to fall into the old trap of hiring a team to build the platform for them. What comes out the other side is a services firm with a coat of AI paint, not an autopilot.

I want to be honest about how solid this is. The autopilot market is too young for real statistics — the companies with legible trajectories are still in the single digits, most of them founded between 2024 and 2026. So this isn’t an empirical claim; it’s a hypothesis I’m reading off a few patterns:

  • In classic services, the textbook way to fail is the visionary founder who delegates execution without ever understanding the operating model from inside. Apply that mechanically to “stack and process” and you’d expect the same outcome.
  • Stripe, Figma, Linear — the product companies where the founders built the core function with their own hands seem to outrun the ones that outsourced it. But that’s classic software, not agentic autopilot.
  • From what’s public about Harvey, Crosby, and Cresta, at least one founder in each looks to have been hands-on inside the stack. That’s a couple of data points, not a distribution.

So “you can’t hire an autopilot, you have to build it yourself” is, for now, an intuition borrowed from neighboring industries plus a handful of cases. It’s a bet, not a fact. If you’re building an autopilot and you, the founder, aren’t sitting inside the stack, I’d treat that as something to check rather than something to ignore. Eighteen to twenty-four months from now there’ll be enough wins and wreckage to know whether the pattern holds. Until then it’s a working hypothesis.

Angle 2 — The copilot/autopilot boundary is a moving line, not two markets

Bek runs the whole piece on the intelligence/judgment pair: AI takes over intelligence, judgment stays human, and so copilot domains (where taste matters) and autopilot domains (where taste is formalizable) look like two separate markets.

That split only holds on a first pass. Judgment isn’t an inherent human property — it’s calibrated intuition built on fresh data. As a domain piles up “decision → outcome” records, the judgment in it starts to formalize: yesterday’s expert taste becomes today’s tuning dataset and tomorrow’s default model behavior. ICD-10 coding, one of Bek’s own examples, was a judgment task five years ago and is autopilot work now. Tax consulting, insurance brokerage, and legal discovery are lined up behind it.

So these aren’t two markets. They’re one trajectory. Every domain begins as copilot territory and drifts toward autopilot as the data accumulates — Karpathy’s “today’s judgment will become tomorrow’s intelligence,” pointed at a market. The boundary only moves one way.

The consequence is quick to state. A copilot that tracks expert work faithfully is harvesting the exact dataset its future autopilot will train on; it’s funding its own replacement out of its own revenue. An autopilot has the mirror problem: it can’t sit still, because it needs a feedback loop that hands edge cases back to humans as the main source of new data, or it ages out the moment the domain shifts. Both sides are standing on the same moving line, just at different points along it.

Angle 3 — “$1 software : $6 services” is a vanishing arbitrage, not a model

Bek’s wedge: for every dollar spent on software, six go to services, so the autopilot market is roughly six times the copilot market, and that’s where the next $1T company is hiding.

But 1:6 is a snapshot, not a constant. Services cost what they cost today because they’re labor-intensive. If autopilot genuinely works in a domain, the services budget there shrinks — the thing that cost $6 falls toward $0.60, then $0.06. That isn’t a side effect; it’s the point of the pitch. The arbitrage holds only while autopilot is a thin slice of the services market it’s measured against. Once it becomes the default way the work gets done, there’s no $6 anchor left to discount from, and the price drops well below the unit economics in today’s decks — the same thing that happened to SaaS once “ten times cheaper than on-prem” had nothing left to be cheaper than.

A few things follow. Pricing power for early autopilots is on a clock, and the better the niche, the faster the clock runs. The real danger isn’t one autopilot beating another; it’s the pie collapsing — ten players carving up a market they jointly squeezed from $6 down to $0.60. And “huge TAM because services are huge” quietly misleads, because the autopilot is the thing eating those budgets; the number that matters is the post-disruption TAM, which is often 10–50x smaller. The way out is to treat the first domain as a bridgehead into adjacent ones where 1:6 still holds — the Office and AWS move. Worth keeping in view, too, who’s holding the pen: Sequoia is paid to sell the 1:6 frame while the window is open. That doesn’t make it wrong today; it just means the reader has to supply the second layer about what happens when the window shuts.

Pulling it together

So if you’re reading this from inside a personal agentic stack rather than from a VC’s desk, here’s what I’d actually do on Monday.

Stop treating your stack as a hobby setup, and start treating it as version zero of a company. That changes small decisions: write your .claude/, your skills, your review loops so a second person could run them, not just you. The cost of doing this now is roughly zero; the cost of retrofitting it the day you hand the stack to your first operator is the whole transition.

Sell the work before you sell a product. The cleanest path through the next year isn’t “build a SaaS” — it’s take a few paying clients on executed work, watch which tasks repeat, and let the product fall out of the repetition. You don’t have to guess what to productize; the client log tells you.

Pick a first domain by how fast its judgment is formalizing, not by how big its services budget looks today. A fat budget (angle 3) is exactly the budget you’re going to collapse, so don’t price your plans on it lasting. Better to enter where “decision → outcome” data is already piling up (angle 2) — that’s where one person plus agents can actually clear the bar — and treat the first domain as a doorway into adjacent ones, not as a place to settle.

And if you ever do raise or hire: stay inside the stack with your own hands. The moment you hand the core function to a team to “build the platform,” you’ve quietly become a services firm with AI paint, which is the one outcome this whole piece argues against.

That’s the through-line in one line: autopilot isn’t a destination, it’s a station on a moving line — so build the thing that moves with it, which is you and your stack, not a frozen snapshot of today’s market. Bek’s piece is a good photograph. Don’t mistake it for the territory.