The Self-Driving Company

The claim: a company that runs its own errands

The essay opens with a big claim: a company can "learn to operate itself." The definition is careful, though. A self-driving company still has people, and those people still choose the destination — which problems matter, the hard trade-offs, who carries the outcome. What changes is that they stop performing every step to get there.

The driving metaphor is doing real work here. A self-driving car doesn't take away your choice of where to go; it takes away the steering. The claim has the same shape: humans set direction, an expanding system of agents gathers context, does the work, checks the result, and escalates when human judgment is needed.

That last clause is the load-bearing one. The story isn't "agents replace people"; it's agents drive the route and hand back the wheel at the moments that need a human. Hold onto "escalates when needed" — it's the hinge that separates this from the automation stories that quietly break.

Engineering went first — now read the numbers twice

The company proved it in engineering before anywhere else, and led with the figures. Over six months: 5.8× the lines of code overall, and 2.9× on a fixed group of 30 engineers, which strips out the effect of simply hiring more people. Review time stayed flat because an agent now reviews code changes and only pulls a second human in when the risk warrants it — over a third of merged changes are approved by an agent.

Read those twice, because lines of code is a famously gameable number. More code is not more value, and can be the opposite. This is Goodhart's law waiting to happen: the moment a count becomes the target, it stops measuring what you cared about.

The essay half-answers the objection. It also reports revert rates and incident counts staying flat-to-down while volume climbed — outcome signals, not just output. That's the right rebuttal to make. It's still the company's own dashboard, trimmed of outliers, so treat it as an existence proof, not a benchmark.

The three parts that make it actually work

Under the metrics sit three mechanisms, and the essay is unusually clear that none works alone. First, a manager agent that spawns swarms: any employee can hand a verifiable task to an agent that fans out into many sub-agents running in loops until it's done. One stalled migration to a new styling system landed as 309 merged code changes over two months this way.

Second, an agent that improves itself — a continual-learning loop that reads user feedback, proposes changes, and validates them against benchmarks and A/B tests before shipping. In their words, "each piece fails alone. Together they are an engine."

Third, and easy to skim past: the safety scaffold came first. Access policies, token proxies, audit logging and a zero-trust network were in place before the agent got the keys to code, cloud accounts and chat. The order is the lesson — containment before capability, not after the first incident.

Build-beats-buy, with teeth

The most consequential claim isn't about coding speed. It's that the more you build internally, the less you buy. The company says it cancelled a seven-figure software subscription because its own agent-built app was better and staff had already migrated to it.

It goes further: its internal agent beat specialist vendor tools it evaluated — an alert-triage tool and an automated penetration-tester — at roughly a tenth of the running cost. For a finance or operations reader this is the line that should prick up your ears, because build-vs-buy is a call you make constantly, and the default has always been "buy, because building is slow."

The honest caveat sits right next to it: this only became true after there was a full platform and a security scaffold to build on. It's the payoff of owning your stack, not a weekend script. The math flips once the foundation exists, and not a moment before.

Doers into directors — the reading, and the limits

The framing the essay lands on is that nobody got automated away; they got promoted. "Self-driving turns doers into directors." In operations terms this is a span-of-control change: each person now directs a fleet of agents instead of doing each step, the way ERP once automated a slice of the back office — except this reaches all of knowledge work, not one process.

The quality-control angle translates cleanly across worlds. A second human reviewer, four-eyes sign-off in finance, and an agent that reviews another agent's code are the same idea in three costumes: independent checking before something ships. The move is to let the agent do the routine check and reserve the human for the risky cases.

Now the limits, because the strongest case against this deserves stating plainly. This is an AI-native company whose product is agents; it is the easiest possible place for it to work, and its data is its own marketing. The enterprise reality is harsher — at a dinner of large-company IT leaders the same week, the recurring blocker wasn't model quality but change management, messy data and permissions. The pattern is real; the magnitudes and the ease are not yet yours to assume.

Vocabulary

• self-driving company — agents woven into every function; people set direction, agents do the steps
• loop engineering — a manager agent spawns a swarm of sub-agents to run a verifiable task to done
• continual learning — an agent that improves itself from feedback, tested before each new version ships
• zero-trust (network) — trust nothing by default; every access is verified, even inside your own systems

If you're building — what to watch for

• Containment before capability: put access controls, audit logs and a zero-trust boundary in place before you hand an agent the keys, not after the first incident.
• Watch your success metric. 'Lines of code' or 'tasks done' will get gamed; pair any volume number with an outcome number (rework rate, defect rate) or you're measuring motion, not progress.
• The gate that scales: let agents handle the reversible, routine work and reserve human judgment for the irreversible minority — 'agent reviews, human takes the risky cases.'
• Build-vs-buy flips only after you have a platform. Owning your stack beats buying once the foundation and security scaffold exist; before that, buying is usually still right.
• Treat any vendor's own numbers as an existence proof, not a benchmark — the pattern can be real while the magnitudes stay unverified.

Reading it critically

• It's first-party marketing: every figure is the company's own platform data, outlier-trimmed, with 'illustrative' cost comparisons — an existence proof, not an independent benchmark.
• Lines of code is a gameable metric; the flat error and revert rates are the real defence, but they're self-reported too.
• Survivorship bias: this is an AI-native company whose product is agents, the easiest possible place for it to work. At large traditional firms the blocker is change management, messy data and permissions, not model quality.
• The essay is silent on failure modes — what the agents missed, how often escalation was wrong, what a swarm going wrong cost. A story with no scar tissue is a sales story.