SpaceX launched the first Starlink satellites in 2019. Joe Marino-Bill Cantrell/UPI/Alamy

By

Ben Cohen

May 21, 2026 9:00 pm ET

The mission of SpaceX is to “make life multiplanetary, to understand the true nature of the universe and to extend the light of consciousness to the stars.” 

Starlink was born of more earthly concerns. 

“What’s needed to create a city on Mars? Well, one thing’s for sure: a lot of money,” Elon Musk said in 2015 at the launch event for his latest moonshot. “So we need things that will generate a lot of money.” 

Musk laid out his radical vision of the future long before SpaceX had its sights on the biggest IPO in history. Even then, he knew that rockets alone wouldn’t get his company to Mars. His only hope of establishing society on a freezing rock far, far away was blasting thousands of satellites into orbit.

A decade later, Starlink is now generating enough money to bankroll a company that burns through it at warp speed.

Created with Highcharts 9.0.1SpaceX annual revenue by divisionSource: the companyNote: Starlink is part of the Connectivity division

Created with Highcharts 9.0.12023'24'25024681012141618$20 billionAIStarlinkSpace

SpaceX may be known for building majestic rockets, firing those giant beasts of marvelous engineering into the skies and catching them with chopsticks. What’s less known is that the company’s extraordinary ambitions are fueled by an incredibly ordinary product: SpaceX has become an internet-service provider that also explores space.  

The prospectus that it filed as SpaceX prepares for a massive initial public offering makes it clear that colonizing Mars and cracking AI is going to depend on selling Wi-Fi. 

SpaceX consists of three segments: space, AI and connectivity, which is primarily driven by Starlink. Last year, the Starlink division was responsible for $11 billion of revenue, which amounted to more than 60% of the company’s total sales. It was the most valuable part of the business—and the only profitable one. And for years, it has been absolutely essential to the success of SpaceX. As it turns out, even companies that defy the laws of gravity are bound by the laws of economics. 

The mysterious finances of Musk’s company were detailed this week in SpaceX’s IPO filing, which is far more bonkers than financial paperwork has any right to be.

The highlights include the company describing itself as “the most ambitious, vertically integrated innovation engine on (and off) Earth,” claiming a total addressable market of $29 trillion, revealing that Musk’s pay package is tied to “the establishment of a permanent human colony on Mars with at least one million inhabitants” and declaring: “We do not want humans to have the same fate as dinosaurs.” 

But when it’s not discussing existential perils of the universe, the document also happens to explain the business model of SpaceX. 

It shows that the whole company is built on a powerful flywheel: SpaceX rockets launch Starlink satellites, and those Starlink satellites are the reason SpaceX can launch more rockets.  

That virtuous cycle was Musk’s vision from the earliest days of Starlink, as he told a room full of engineers that night more than a decade ago. 

Before it provided a lifeline in dead zones, before it restored communications after natural disasters, before it beamed Wi-Fi into the middle of nowhere and metal tubes at 35,000 feet, Starlink was the solution to SpaceX’s money problems. 

At the time, SpaceX was basically a trucking business that charged governments and private companies to haul stuff into orbit. But that wasn’t going to pay for civilization on another planet, so Musk went exploring for other spaces. There was nothing glamorous about selling internet access. The market was so large, though, that grabbing even a small percentage of it would produce revenue that exceeded NASA’s entire budget, Musk told biographer Walter Isaacson. 

But if it were easy to do, others would have done it. In fact, getting into the business of shooting satellites into low-Earth-orbit had always been a good way to wind up in bankruptcy. To him, the mission of Starlink was simple. 

“We want to be in the not-bankrupt category,” Musk said in 2020. “That’s our goal.” 

Created with Highcharts 9.0.1Starlink total subscribers by yearSource: the companyNote: 2026 data through March 31

Created with Highcharts 9.0.12023'24'25'26024681012 million subscribers

To achieve this audacious goal, Musk’s top engineers had to make satellites faster and cheaper—so they applied “The Algorithm.” 

In the IPO paperwork, the company formally defines “The Algorithm” as a five-step process with the guiding principles of SpaceX: make less dumb, delete, optimize, accelerate, automate. 

When he found out that Starlink satellites were being released individually, for example, Musk wondered why they couldn’t be released at once. “I was too chicken to propose that,” said SpaceX rocket engineer Mark Juncosa, according to Isaacson’s 2023 book. “Elon made us try it.” And it worked. SpaceX says it has reduced the average manufacturing cost of a Starlink kit by 59% since 2022.

The rest of the business has been through its own dramatic transformation in that time. 

Starlink had about 2 million subscribers back in 2023. Now there are more than 10 million. 

In the early days, Musk dreamed of a network with 4,000 satellites, which was more than the total number of satellites in known existence. Now it has almost 10,000. 

It took roughly five years of development before Starlink launched its first satellites and many of them failed. Now they’re launching every three days and they always work. 

All of which added up to one of the many eye-popping disclosures in the company’s prospectus. SpaceX has plans to discover “trillion-dollar markets on the Moon, Mars and beyond,” it said. But it didn’t have to look that far to find the first one. 

“We founded Starlink,” the company bragged. 

Starlink has already carried SpaceX farther than even Musk predicted. Now that it’s landing on Wall Street, there’s only another 140 million miles to Mars.

A time exposure of SpaceX's Falcon 9 rocket as it launched the first Starlink satellites. Joe Marino-Bill Cantrell/UPI/Alamy

Science of Success

More from columnist Ben Cohen about why people, teams, strategies and ideas succeed or fail

The Genius Whose Simple Invention Saved Us From Shame at the Gas Station

Apple Showed Me 50 Years of History That Nobody Has Ever Seen

You Have No Idea How Much You Still Use BlackBerry

The $40 Billion Game of Youth Sports Has Only One Winner

Why There Are 29,000 People on a Waitlist for Beans

America Finally Made Getting a Passport Simple

The Hot Toy Made by a Tech Startup You’ve Never Heard Of

It’s Waymo’s World. We’re All Just Riding in It.

Copyright ©2026 Dow Jones & Company, Inc. All Rights Reserved. 87990cbe856818d5eddac44c7b1cdeb8

Hypershell’s new X Ultra S motorized exoskeleton is aimed at outdoor enthusiasts who want to cover more distance with less effort.

By

Nicole Nguyen

| Photography and Video by Poppy Lynch

May 20, 2026 9:00 pm ET

I strapped my two-year-old in a hiking carrier, and went for a walk up a winding dirt trail. The robotic hip motors whirred and a mechanical force tugged at my quads.

As the incline got steeper, I opened the companion app on my phone and pressed “Boost.”

 My stride quickened. The whirring got louder. As the AI marched me toward the summit, I enjoyed the view. Thirty seconds later, the surge of power was over, and the legs returned to the gentler Eco mode.

These motorized supports were once reserved for military, heavy industry and mobility rehabilitation. Now, they are light and affordable enough for regular folks—regular folks who want to feel superhuman, that is. These hip-based systems start at $900, and I tried the latest, Hypershell’s $1,999 X Ultra S.

Two weeks of testing didn’t transform me into Iron Man. But the rig did make me want to sprint everywhere—and I hate running.

A bionic puppet master

Like its competitors, Hypershell’s exoskeleton consists of a waist band and a pair of hinged thigh braces. Twin hip motors draw up to 1,000 watts to power the carbon-fiber arms that apply force to your leg. Theoretically, at its top supported speed, the X Ultra S could help you run an elite four-minute mile.

Before you read on, watch me using it in this video:

See how the Hypershell X Ultra S works. Photo: Poppy Lynch for WSJ

Long nature walks are more my speed, so I took the bionic legs on San Francisco’s hilliest trails. Passersby stared at the unsubtle contraption. If I looked like a dork, at least I could zoom quickly past the judgment.

The first time I wore them, the contraption felt like a puppeteer controlling my legs. The motors can jerk you around, especially if you start, stop or change direction suddenly. Once you get into a constant, repetitive motion, the push-and-pull sensation fades.

I used the mobile app to calibrate the power—25% on Eco mode was just right to start.

AI software the company calls Hyperintuition interprets your movements to deliver the right force. Going uphill, with the torque notched up, I really felt the exoskeleton at work. Climbing up stairs was like walking up an escalator. The e-assistance really shines on sand, where you normally feel your energy sapped away.

But as I crossed a rocky section with some loose boulders, I worried one wrong jerk could send me tumbling, so I dialed down the power. A Hypershell spokesman said that a snug, proper fit and a lower level of assistance can help on unstable terrain.

I was disappointed with my downhill experience. Descents can be exhausting but the AI isn’t smart enough to detect them. You have to dig into the app, and activate Downhill mode yourself.

A couple of power-walking hours later, I removed the legs. My body felt slow and heavy. I was like an astronaut returning to Earth, getting reacquainted with my own muscles.

The cyborg cyclist

On a bike ride, the puppet effect was even more dramatic. At one point I was barely moving my legs myself. On certain climbs, I topped out panting and exhausted, then realized my bike was in its hardest gear.

The Spandex-clad cyclists who tackle San Francisco’s iconic Hawk Hill have a saying: “The climb doesn’t get easier, you just get faster.”

That’s also true of riding with battery-boosted legs. I was out of breath because I was pedaling at my regular cadence, but each stroke had a lot more power.

Hypershell’s app lets you set the exoskeleton’s assistance intensity.

The exoskeleton’s AI-enabled software can detect movement and deliver the appropriate amount of power—more for running, less for walking.

Hypershell’s companion app, left, lets you set the assistance intensity of the exoskeleton, which can output a max of 1,000 watts of power.

The device is mostly intuitive but comes with some dangers. After my ride, I unstrapped the unit thinking it was off, but an active arm snapped back with full force. I wasn’t hurt, but it was a stark reminder of the risks of robotics in our everyday lives. Hypershell’s app includes reminders for responsible use, including the proper way to disengage.

Minutes after I returned home, the battery died. I was relieved I wasn’t stranded on a mountain, hauling 5 pounds of dead robot weight. I think in my testing I overtaxed the battery by relying on the Boost too much. The company says you can generally walk 18 miles in the X Ultra S, twice that with the included extra battery pack.

Who needs magic legs?

I’m not sure exoskeletons are ready for prime time, though early-adopter gearhead types with a couple thousand dollars to burn will have fun with them. I do look forward to taking them backcountry skiing come winter. Those long uphill climbs (not to mention keeping up with my much fitter husband) can be grueling.

Many of us could explore motorized legs as they become lighter, cheaper and more discreet: especially people who are just getting active, or older folks who want support while hiking. And there’s a case for serious athletes, who could use the Fitness setting to actually add resistance during workouts.

One side effect: My calves were sore for days. The exoskeleton made me feel like I had infinite endurance so I kept going, and my other muscles paid the price. Fortunately, another company makes a bionic system for the lower leg. Maybe I’ll wear them together for my next review—and let the bots do all the work.

Copyright ©2026 Dow Jones & Company, Inc. All Rights Reserved. 87990cbe856818d5eddac44c7b1cdeb8

For the last few months, we've been testing a range of security-focused LLMs on our own infrastructure. These LLMs help identify potential vulnerabilities in our own systems, so we can fix them – and they also show us what attackers are going to be able to do with the latest models.

None of these LLMs has captured more attention than Mythos Preview, from Anthropic. A few weeks ago, we were invited to use Mythos Preview as part of Project Glasswing. We soon pointed it at more than fifty of our own repositories – to see what it would find, and to see how it works.

This post shares what we observed, what the models did well and what they didn't, and how the architecture and process around them needs to change, so they can be used at scale.

Mythos Preview is a real step forward, and it's worth saying that plainly before getting into anything else. We've been running models against our code for a while now, and the jump from what was possible with previous general-purpose frontier models to what Mythos Preview does today is not just a refinement of what came before.

It's a different kind of tool doing a different kind of work, and that makes a clean apples-to-apples comparison to earlier models difficult. So rather than trying to benchmark Mythos Preview against general-purpose frontier models, it's more useful to describe what it can actually do, and two features that stood out across the work we did with Mythos Preview:

• Exploit chain construction - A real attack rarely uses one bug. It chains several small attack primitives together into a working exploit. For instance, it might turn a use-after-free bug into an arbitrary read and write primitive, hijack the control flow, and use return-oriented programming (ROP) chains to take full control over a system. Mythos Preview can take several of these primitives and reason about how to combine them into a working proof. The reasoning it shows along the way looks like the work of a senior researcher rather than the output of an automated scanner.

• Proof generation - Finding a bug and proving it's exploitable are two different things, and Mythos Preview can do both. It writes code that would trigger the suspected bug, compiles that code in a scratch environment, and runs it. If the program does what the model expected, that's the proof. If it doesn't, the model reads the failure, adjusts its hypothesis, and tries again. The loop matters as much as the bugs it finds, because a suspected flaw without a working proof is speculation, and Mythos Preview closes that gap on its own.

Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too. Where they fell short was at the point of stitching the pieces together. A model would identify an interesting bug, write a thoughtful description of why it mattered, and then stop, leaving the actual chain unfinished and the question of exploitability open. What changed with Mythos Preview is that a model can now take those low-severity bugs (which would traditionally sit invisible in a backlog) and chain them into a single, more severe exploit. 

The Mythos Preview model provided by Anthropic, as part of Project Glasswing, did not have the additional safeguards that are present in generally available models (like Opus 4.7 or GPT-5.5).

Despite this, the model organically pushes back on certain requests - much like the cyber capabilities that made it useful for vulnerability hunting, the model has its own emergent guardrails that sometimes cause it to push back on legitimate security research requests. But as we found, these organic refusals aren’t consistent - the same task, framed differently or presented in a different context, could produce completely different outcomes as illustrated in the examples below.

Example of Mythos Preview pushing back on building a working proof of concept 

For example, the model initially refused to do vulnerability research on a project, then agreed to perform the same research on the same code after an unrelated change to the project’s environment. Nothing about the code being analyzed had changed. In another case, the model found and confirmed several serious memory bugs in a codebase, and then refused to write a demonstration exploit. The same request, framed differently, got a different answer, and even the same request can produce different outcomes across runs due to the probabilistic nature of the model. Semantically equivalent tasks can produce opposite outcomes depending on how and when they’re presented to the model.

This matters because while the model’s organic refusals/guardrails are real, they aren’t consistent enough to serve as a complete safety boundary on their own. That’s precisely why any capable cyber frontier model made generally available in the future must include additional safeguards on top of this baseline behavior - making it appropriate for broader use outside of a controlled research context like Project Glasswing.

One of the hardest parts of triaging security vulnerabilities is deciding which bugs are real, which are exploitable, and which need fixing now. This was a hard problem even in the pre-AI world. AI vulnerability scanners and AI-generated code have made it worse, and at Cloudflare we've built multiple post-validation stages to deal with it.

Two factors dominate the noise rate:

• Programming language - C and C++ give you direct memory control and, with it, bug classes - buffer overflows, out-of-bounds reads and writes - that memory-safe languages like Rust eliminate at compile time. We saw consistently more false positives from projects written in memory-unsafe languages.

• Model bias - A good human researcher tells you what they found and how confident they are. Models don't. Ask a model to find bugs, and it will find them, whether the code has any or not. Findings come back hedged with "possibly," "potentially," "could in theory," and the hedged findings vastly outnumber the solid ones. That's a reasonable bias for an exploratory tool. It's a ruinous one for a triage queue, where every speculative finding spends human attention and tokens to dismiss, and that cost compounds across thousands of findings.

Mythos Preview represents a clear improvement here, particularly in its ability to chain primitives - combining multiple vulnerabilities into a working proof of concept rather than reporting them in isolation. A finding that arrives with a PoC is a finding you can act on, and it means far less time spent asking "is this even real?"

Our harnesses are deliberately tuned to over-report, so we see more (and miss less), which comes with a lot more noise. But at triage time, Mythos Preview's output has noticeably higher quality: fewer hedged findings, clearer reproduction steps, and less work to reach a fix-or-dismiss decision.

When we first started AI-assisted vulnerability research last year, our instinct was the obvious one: point a generic coding agent at an arbitrary repository and ask it to discover vulnerabilities. This approach works, in the sense that the model will produce findings, but it doesn't work in producing meaningful coverage of a real codebase and identifying findings of value. There are two main reasons for this:

• Context - Coding agents are tuned for one focused stream of work: building a feature, fixing a bug, writing a refactor. They ingest a lot of source code, hold a single hypothesis at a time, and iterate against it. That's exactly the wrong shape for vulnerability research, which is narrow and parallel by nature. A human researcher picks one specific thing to look at and investigates it thoroughly. That one thing might be a single complex feature, transitions across security boundaries, or a specific vulnerability class like command injections, where attacker input ends up being run as a shell command. Then they do it again, for a different feature, security boundary, or vulnerability class, several thousand times across the codebase. A single agent session (even with subagents) against a hundred-thousand-line repository can cover maybe a tenth of a percent of the surface in a useful way before the model's context window fills up and compaction kicks in - potentially discarding earlier findings that would have mattered.

• Throughput - A single-stream agent does one thing at a time, but real codebases need many hypotheses against many components at once, with the ability to fan out further when something interesting turns up. You can drive a single agent harder, but at some point you stop being limited by the model and start being limited by the shape of the interaction itself. Using the model directly in a coding agent turns out to be fine for manual investigation when a researcher already has a lead and wants a second pair of eyes. However, it's the wrong tool for achieving high coverage. Once we accepted that, we stopped trying to make Mythos Preview do the wrong job and started building the harness around it instead.

Four lessons came out of running the work at scale, and each one pointed to the need for a harness that manages the overall execution:

• Narrow scope produces better findings - Telling the model "Find vulnerabilities in this repository" makes it wander. Telling it "Look for command injection in this specific function, with this trust boundary above it, here's the architecture document and here's prior coverage of this area" makes it do something much closer to what a researcher would actually do.

• Adversarial review reduces noise - Adding a second agent between the initial finding and the queue - one with a different prompt, a different model, and no ability to generate its own findings - catches a lot of the noise that the first agent would miss if it just checked its own work. It turns out that putting two agents in deliberate disagreement is way more effective than just telling one agent to be careful.

• Splitting the chain across agents produces better reasoning - Asking "Is this code buggy?" and "Can an attacker actually reach this bug from outside the system?" are two different questions, and the model is better at each one when you ask them separately, because each question is narrower than the combined version.

• Parallel narrow tasks beat one exhaustive agent - Coverage improves when many agents work on tightly scoped questions and we deduplicate the results afterward, rather than asking one agent to be exhaustive.

Each of those observations is about model behavior, and put together they describe something that isn't a chat interface anymore. It's a harness that helps you achieve the final outcomes. The first steps to building a harness are simple, as you can ask the model to help, which is what we did. We used Mythos Preview to build on, tailor, and improve our original harnesses to suit its strengths. An example of what a harness looks like in practice is described below.

Here's what our vulnerability discovery harness looks like, stage by stage. It was used to scan live code across our runtime, edge data path, protocol stack, control plane, and the open-source projects we depend on.

Stage	What it does	Why it matters
Recon	An agent reads the repository from the top down, fans out to subagents responsible for each subsystem, and produces an architecture document covering build commands, trust boundaries, entry points, and likely attack surface. It also generates the initial queue of tasks for the next stage.	Gives every downstream agent shared context. Cuts the wander problem.
Hunt	Each task is one attack class paired with a scope hint. Hunters (the agents that actually look for bugs) run concurrently, typically around fifty at once, each fanning out to a handful of exploration subagents. Each hunter has access to tools that compile and run proof-of-concept code in a per-task scratch directory.	This is where most of the work happens. Many narrow tasks in parallel, not one exhaustive agent.
Validate	An independent agent re-reads the code and tries to disprove the original finding. It uses a different prompt and has no ability to emit new findings of its own.	Catches a meaningful fraction of the noise the hunter wouldn't catch when reviewing its own work.
Gapfill	Hunters flag areas they touched but didn't cover thoroughly. Those areas get re-queued for another pass.	Counteracts the model's tendency to drift toward attack classes it has already had success with.
Dedupe	Findings that share the same root cause collapse into a single record.	Variant analysis is a feature, not a way to inflate the queue with duplicates.
Trace	For each confirmed finding in a shared library, a tracer agent fans out (one instance per consumer repository), uses a cross-repo symbol index, and decides whether attacker-controlled input actually reaches the bug from outside the system.	Turns "there is a flaw" into "there is a reachable vulnerability." This is the stage that matters most.
Feedback	Reachable traces become new hunt tasks in the consumer repositories where the bug is actually exposed.	Closes the loop. The pipeline gets better as it runs.
Report	An agent writes a structured report against a predefined schema, fixes any validation errors against that schema itself, and submits the report to an ingest API.	Output is queryable data, not free-form prose.

The loudest reaction to Mythos Preview from other security leaders has been about speed - scan faster, patch faster, compress the response cycle. More than one team we have spoken with is now operating under a two-hour SLA from CVE release to patch in production. The instinct is understandable: when the attacker timeline shortens, the defender timeline has to shorten with it. Faster is not going to be enough, and we think a lot of teams are about to spend a lot of time, effort, and money learning that the hard way.

Patching faster does not change the shape of the pipeline that produces the patch. If regression testing takes a day, you cannot get to a two-hour SLA without skipping it, and the bugs you ship when you skip regression testing tend to be worse than the bugs you were trying to patch. We learned a version of this when we tried letting the model write its own patches and watched a few go out that fixed the original bug while quietly breaking something else the code depended on.

The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it. 

We also recognize this topic cuts both ways. The same capabilities that helped us find bugs in our own code will, in the wrong hands, accelerate the attack side against every application on the Internet. Cloudflare sits in front of millions of those applications, and the architectural principles described above are exactly the ones our products are built to apply on behalf of customers. We will share more on what that means for customers in the weeks ahead.

If your team is doing similar work and would like to compare notes, reach out to us at security-ai-research@cloudflare.com.

Our research with Mythos Preview was conducted in a controlled environment against our own code; every vulnerability surfaced through this work was triaged, validated, and remediated where action was needed under Cloudflare's formal vulnerability management process.

This work was a team effort. Thanks to Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, and Rohit Chenna Reddy for their contributions to the research, engineering, and analysis behind this blog post.

Note: I just enabled paid subscriptions for $8/month. Most of these essays will still be free, but I’m working on adding premium features to Artifact Land and launching a hosted version of Conjure among other upcoming products that will come with the subscription. I’m planning on increasing the price to $20/month once these features are launched. So upgrade your subscription now to lock in the intro price.

Ok… picture this… you’re standing at a self-checkout at a grocery store.

The screen is yelling at you about an unexpected item in the bagging area. You look down, is the unexpected item the banana? Is it your reusable totes? The machine doesn’t seem to want to give you any hints either way.

Behind you, a child is negotiating, in the loudest possible terms, for one of the pouches in their parent’s cart. A barcode is failing to scan for the eleventh time. And there’s one employee overseeing six of these machines like a shepherd whose sheep have all started doing their own taxes.

How did we get here?

Automated Salesforce Machine

In April 2026, Salesforce announced Headless 360.

The pitch, from Marc Benioff: “No browser required. The API is the UI.”

You can basically translate this to:

we’re no longer going to ship you software. we’re going to ship you the raw materials of software. you can figure out the rest.

If you heard this and shrugged, I don’t blame you. It’s an API. APIs are old. What’s the big deal?

The big deal is that Salesforce is the largest enterprise software vendor on earth, and they just told their entire customer base that the part of the product they use most is no longer Salesforce’s job.

It is the customer’s job.

I don’t think Salesforce is going to be the only time we see this. I see this as a direction of travel announcement. Every major enterprise vendor is going to do some version of this in the next eighteen months. They’re going to call it different things or dress it up in different words. But the shape will be the same: the vendor ships the substrate, and somebody at your company assembles the substrate into something that does work.

That somebody is probably going to be you.

Unbundling Implementation

Now I know that “the vendor used to do this for you” isn’t the whole story.

Implementation labor was always layered across an ecosystem with a thin slice of vendor-paid solutions engineers at the top, a much bigger slice of customer-paid integrators and agencies in the middle, and underneath all of it, a job category. The Salesforce admin. The Design Ops or Marketing Ops Manager. People whose entire role inside your company was to configure another company’s products for you.

The customer was always expected to pay for most of the cake.

Headless 360 just significantly changes the scope of what the people the customer was already paying are now expected to do.

The Salesforce admin role gets re-scoped. What used to be “click through the configuration screens that Salesforce designed for you.” Now has no screens and the admin is wiring together workflows that didn’t exist as a product feature an hour ago using agents, MCP, custom integrations, things that don’t have a Trailhead course yet. And that’s just the people who already had the role.

But to me what this hints at is that every other function in your company is about to need its own version of that role. Marketing needs one. Finance needs one. Legal, ops, support, recruiting, even engineering. Each function uses different software and lives in a different corner of the business, but each one now needs somebody whose job is to translate generic AI capability into something that does work here, specifically.

It was easy to name this person’s role when they only existed inside one product. But what do you name the version of them about to exist in every department of every company at once?

I don’t know, but I think it means there’s about to be a lot of those people.

Enter Colonel Saunders

In 1917, in Memphis, a man named Clarence Saunders opened a store called Piggly Wiggly. (We used to live in much more whimsical times…)

Clarence had the wild idea to let you, the customer, walk around and pick your own groceries off the shelves.

Before Piggly Wiggly, you had to give a list to a clerk who fetched the things for you. That was the clerk’s entire job. They had everything memorized. They knew where the flour was, intimately, like family.

Saunders looked at that beautiful, dignified, fairly-paid clerk and said: “what if the customer just did that part, for free?”

And we said: “ok!”

We’ve been saying ok for over a hundred years.

• 1917 — customer picks items off the shelf (clerk loses one job)

• 1970s — barcodes price and inventory the items (clerk loses another)

• 2000s — customer scans the items themselves (clerk mostly stops existing)

Each wave needed a capability unlock. Open-shelf store layouts. UPC codes. Cheap touchscreens that could yell about bagging areas without needing a human supervisor for every single machine.

And each wave was sold as convenience.

Yes, I understand that the clerk job mostly disappeared, but the point is that the labor didn't. The consumer now has to do it. For enterprise software it's a bit different, you're not choosing to enter the Salesforce store, that decision is made for you.

Here comes everybody (again)

Fast forward to 2008. A guy named Clay Shirky wrote a book called Here Comes Everybody.

The book’s argument was essentially that institutions exist because coordinating people is expensive. You need bosses, processes, headquarters, payroll, and a building with the company name on it because otherwise nothing gets done. The firm exists to absorb coordination costs.

Shirky’s bet was that the internet collapsed those costs to near zero which caused institutional functions to start leaking out into ad-hoc groups. Wikipedia over Britannica. Flash mobs happened. Coordination got cheap enough to organize without organizations.

Eighteen years later, almost exactly, I think we are watching the same trick get pulled with a different cost curve.

That was the coordination story. We are now living through the building story.

Building complex software used to require a software company. You needed engineers, and a build process, and a UI design phase, and someone whose entire job was figuring out what to do with the JIRA tickets. Building was institutionally expensive in the same way coordinating used to be.

Agentic coding tools, MCP, headless platforms, and so on are already starting to do to building what the internet did to coordinating. Building is cheap now and people everywhere are waking up to it. A finance lead can spin up a reconciliation agent on a Tuesday afternoon. A recruiter can wire up a candidate-research workflow over coffee and a chocolate croissant.

Coordination got cheap enough to organize without organizations.
Implementation got cheap enough to implement without implementers.

Shirky’s everybody came together. Ours comes apart.

His version produced Wikipedia where a million people work together to build one thing. The 2026 version produces a million people each building their own separate thing in their own separate corner of their own separate company. A million reconciliation agents. A million candidate-research workflows. None of them shareable. None of them composable. The disintermediation is the same; the sociology is the opposite.

The old everybody convened. The new everybody atomizes. Coordination was a tax we paid because software was scarce, and we don’t have to pay it anymore. This is what software finally being abundant looks like.

Pit Crew

So what do we call this person? The one in marketing or finance or legal who’s now expected to translate generic AI capability into something that does work in their corner of the business?

I’ve been using Pit Crew over in Near Zero, but I’m sure we’ll call it something else. Though I’m not convinced we’ll use Stripe’s Forward Deployed AI Accelerator, Marketing either.

Your marketer has the taste. They know your brand voice, what’s been tried, when a subject line is going to land and when it wont. The marketer is the driver. The car they’re now driving is AI. It is powerful, fast, finicky, capable of going off the track in genuinely surprising ways if it isn’t tuned correctly. The Pit Crew tunes the car.

You can’t expect every marketer to know how to configure an MCP server or stitch six APIs together with an agent. Similarly the Pit Crew doesn’t need to write a brand voice guide. Neither of them wins the race alone. The marketer brings what to build and why. The Pit Crew brings how to build it and how to keep it running at speed.

Every domain expert in your company is about to need their Pit Crew counterpart. Or be one. Or both.

There are two reasons every function is going to need this person, and they push in the same direction.

The first is what we’ve been talking about all post. Headless platforms externalize implementation labor onto your team. You’re forward-deployed for the vendor just billed to your own employer.

The second is bigger and more permanent than any one vendor. Models are generic. The model doesn’t know your customers, your data, your weird Q3 reporting requirement, the fact that one specific salesperson refuses to use the new CRM no matter how many times you ask. AI capability only becomes useful at the point of contact with a specific workflow, dataset, or person. It doesn’t make sense to have a central “AI team” any more than it would be to have a central “Excel team.” Every function gets its own.

I personally like “Pit Crew.” But I’m sure the industry is going to come up with something else (maybe better? I don’t know…). But the role is real before its vocabulary is, and I’d rather pick an imperfect name than wait around for a good one.

Empowerment and Extraction

I do truly believe this is empowerment. Pit Crew is a real career path with real leverage, and the people who get good at it early are going to eat extremely well. People can genuinely do things they couldn’t do a year ago, and I’m blown away by the things I’ve been seeing.

Which is different from what you see in most headlines these days. The current consensus is that all of this means the need for fewer jobs. One Pit Crew member, they say, can do the work that used to take twenty marketers. So you keep the Pit Crew, you lay off the twenty, and you write yourself a thank-you note in the form of an EBITDA improvement.

I think this is wrong about the direction of the change.

The marketing team doesn’t shrink. It grows. So does the Pit Crew supporting it. Both numbers go up. Once a marketer paired with a Pit Crew is dramatically more productive, that pair is dramatically more valuable to the business. Valuable functions don’t shrink. They get more budget. They hire. The output expands, and demand expands with it, because there turn out to be enormous amounts of marketing work that nobody could previously imagine doing because nobody could previously afford to do it.

So you don’t go from 20 marketers to 1 marketer plus 1 Pit Crew. You go from 20 marketers to 25 marketers plus 5 Pit Crew. Then 30 plus 10. The Pit Crew ratio rises. The marketing team rises with it. The whole org chart gets taller. The labor multiplies. Every other time in history that software engineering became cheaper, demand skyrocketed. Why would this time be any different?

Call one bet “Substitution” if a company sees Pit Crew as a way to do the same work cheaper. The other “Multiplication” if a company sees Pit Crew as a way to do much more work, period.

Both are happening in different companies right now. Only one of them is right about the future. The companies betting on substitution are going to wonder, in about eighteen months, where their competitive advantage went. The answer will be that it went to the company that hired more people and more pit crew for them, not fewer.

Share