The Tool Went In. Team Speed Didn't Move.

Here's what that chasm looks like inside a real company.

An operations lead at a non-tech company manages a few thousand people. Before AI, team speed was fine—nothing to complain about. Then the company rolled out Claude Cowork.

Team speed stayed the same. The lead had one question: why?

Because usage inside the organization splits the same way every time, whether the team is 50 people or 5,000. It's always a barbell:

The 5-10% heavy users are the ones who pushed the company to buy Cowork in the first place. They were already tinkering with AI on their own time and had seen what it could do.

On the ledger, this distribution reads as one sentence: Nothing got faster, but you definitely burned a few million dollars.

Distribution of an operations org. The bottom-right line reads "Observed speedup: none." Source: Vasuman / Varick Agents

Using AI and Using It Well Are Two Different Skills

But why does this happen? Even among the people who do use AI, the skill gap is terrifying:

AI users who don't know what they're doing are worse off with AI than without it. Vasuman

Installing Claude, pointing it at a repo, typing a four-word prompt, and watching it do something—that's easy. The result can be right or wrong. Using it well is another matter. Four things, total:

1. Knowing when to clear the context
2. Knowing that something you've done twice should become a skill file
   the model reads every time, instead of retyping the prompt
3. Knowing which 15% of an automation project needs the model to make
   judgments, and which 85% just needs deterministic code
4. Most important: actually reading the diff before you merge

The Same Ticket, Given to Two Engineers: It Splits in Five Minutes

Here's what the gap looks like in practice. Give the same ticket to two engineers.

Engineer one: Pastes the Jira text into Claude and hits submit. The change touches six files. He glances at it, sees the tests pass, and merges the PR. Three weeks later, production starts acting up, and someone discovers that this PR changed a configuration value for no reason.

Engineer two: Starts the same way—pastes the Jira text—but then specifies where the code lives in the repo, which folders and files should be touched, and which shouldn't. He already has a skill file that ensures every PR Claude submits is lean rather than bloated, with proper testing before submission. Then he reads the diff, catches one unnecessary change, removes it with a single prompt, and merges a PR half the size of the first engineer's.

FIGURE 3 - Same tool, same seat, different outcome. Source: Vasuman / Varick Agents

And in any organization, at least half the people will never reach that second state. Using AI well is a craft that requires enormous iteration. For someone who hasn't boarded the AI train at all, that inertia is a wall many can't climb. Turning a random prompter into a precise operator is just as hard.

Even a Perfect Rollout Still Ends Up a Barbell

So what about a company that does it well? The obvious rebuttal is: those companies rolled it out badly—if I did it, it would work. That rebuttal doesn't hold. Even a perfect rollout gives you the same barbell.

Another executive's math is even blunter: they just deployed enterprise licenses across the whole org—an eight-figure annual commitment. The result: roughly 10% of people burned 90% of the tokens.

Let's do that math:

FIGURE 4 - 10% of your seats burn 90% of the tokens. Source: Vasuman / Varick Agents

88% of Companies Use AI. Only 6% See Profit.

That's all first-hand observation. What does public research say? Two frequently-cited reports point the same way.

And that's the problem with "adoption rate" as a metric: adoption is a yes/no question. Skill is a spectrum. When you track adoption rate, you're asking the most abstract form of a yes/no question: "Did this person log in this month?" "Did they log in this year?" "Did they send more than 5 prompts a day?"

But that number is technically true—nobody is lying about adoption. It's just much easier to measure than what you actually care about. What you really want to know: how skilled each person is with AI, and what return you get per token spent.

FIGURE 5 - What the adoption number hides. Source: Vasuman / Varick Agents

Vendors, Companies, and Internal Power Users All Have Reasons Not to Fix It

The problem is obvious. So why doesn't anyone fix it? Vendors, companies, and internal power users each have their reasons.

Vendors

Every AI vendor's roadmap is about how much more powerful the agent got. Not a single line about how capable the team is at using it. So the only people who use it effectively are frontier users—and frontier users are the loudest, so they set the agenda. They're also the most enjoyable customers to serve. Win-win. The result: every feature release raises the skill floor for "using this product well." People stay still, the floor keeps rising, and the chasm only widens.

Companies

Enterprises are most seduced by the idea of "training employees to write prompts!" But that's a 10% game. The other 90% is "training employees to judge which workflows should never touch the model, and which should be fully automated."

That's a hard sell, because the answer is different for every company. You have to spend weeks on-site to figure it out.

Internal AI power users

They have no incentive to fix it either. The chasm is their leverage. They finish work 70% faster and then coast. Or they do the work of three people. If everyone else gets on board, their advantage disappears. Without extra incentive, why would they fix it?

Training Is for Finding People, Not Transforming Them

Put these observations together and you get an uncomfortable conclusion. Here's how he puts it:

If you actually track this metric, you'll find: the vast majority of people in an enterprise will never become AI-native.
Does that mean they have no value? Of course not. It just means your implementation and rollout plan has to adjust accordingly. Vasuman

There are two layers here, and missing either leads you astray. First, acknowledge reality: in any organization, at least half the people will never reach the "using it well" tier, and every model release raises the bar. Second, withhold judgment: this has nothing to do with their value as people. It only has to do with how you design your approach.

Training's real job is diagnosis

You have to train anyway. Without training, you won't know who's at the front. Some people in the company are genuinely interested in AI but lack the time and the handle to go deep. Training exposes each person's capability and comfort zone.

Once you find those people, give them a place to publish. A shared database where every skill they build gets published, ranked, and installed by others. This is the only mechanism he's seen that turns one person's breakthrough into something shareable.

The incentive here is the ranking. Power users are willing to trade their advantage for status within the org. But even then, the gap remains: you push these skills to everyone, and still 50% of people will never install a single one.

So this path only covers that small slice. For the large majority, you need a completely different approach.

Put AI in the Background. Ask No One to Change How They Work.

For the remaining majority, the work still has to get done, but you can't ask them to change how they work. That sounds like a compromise, but it's actually the fulcrum of the whole approach. It means AI has to step out of the foreground and into the background.

"Using AI" is, by default, understood as "a human opens a dialog box, types, and waits for an answer." That default puts all the burden on the user: they need to know what to ask, how to ask it, and which parts of the answer not to trust. Every skill gap from the earlier sections grows out of this assumption.

Remove that assumption, and the path changes. Three steps, concretely:

A concrete example: accounts payable

You have a few dozen AP analysts moving invoices around all day. Roughly 90% of that work is automatable.

But you can't expect them to spin up their own agents, and you can't expect them to reliably pull this off with prompts without breaking something in production. That's not the job they signed up for, and nobody trained them for it.

So flip the direction: build agents that run every day on their own, handling the invoice flow end to end. The analysts' role shifts to approving, rejecting, or adjusting what the agent produced.

Their way of working doesn't change—still clicking around the same system—but the org's output does.

People aren't shopping for a tool that will help them get the job done. They just want the job done. Vasuman

The thin path on top is training (three people walk it). The wide path below is background agents (a crowd walks it). Both converge on the same destination: the work is done. Note that the widths are drawn proportional to actual headcount. Source: Vasuman / Varick Agents

Stop Reporting Adoption Rate to the Board

So we land on one action you can change tomorrow: switch what you report.

Stop reporting "adoption rate."

Report this instead: of today's work,
  · how much was done manually
  · how much was done human-machine
  · how much was fully automated

That's the only metric worth reporting,
and the only one worth discussing.

After a several-thousand-person operations company rolled out Claude Cowork, team speed stayed exactly the same. Vasuman says he sees the same "barbell" at every client: heavy on both ends, empty in the middle.

That 5-10% were the ones who pushed the company to buy in the first place. The dashboard records the rollout as "adoption success." The ops lead sees exactly zero speedup. Both are simultaneously true.

Same ticket, two engineers, diverges in five minutes. The first pastes the ticket into Claude and hits submit. The change touches six files, a glance, tests pass, merge. Three weeks later, production breaks—turns out there was an unnecessary config change in there. The second specifies which files should be touched, uses an existing skill file to keep the change lean, reads the diff before merging, catches the one unnecessary change, and merges a PR half the size.

Another company had just signed an 8-figure annual AI license. Result: 10% of the seats burned 90% of the usage (tokens, the billing unit for AI processing).

Your best case becomes your worst case.

Public research shows the same shape.

Adoption rate can only answer "did this person log in this month?" It can't tell "pasted an email for reformatting" from "three agents touching the general ledger." That's what makes it a fake metric.

Turning the whole company into AI power users is a dead end—and each model release raises the bar. Training's real job is diagnosis: find who was already at the front, give them a place to publish where skills get ranked and installed by others. The rest of the majority shouldn't be asked to change how they work. Embed agents directly into the systems they already use (like Salesforce), and pull people in only when review is needed.