AI spreads through
a few people who build for their own work.

In March 2025, Tobi Lütke, the CEO of Shopify, sent his staff a memo. In April he heard it was leaking and posted it on X himself. Most of the coverage went to its bold heading, “Reflexive AI usage is now a baseline expectation at Shopify,” and to the rule that teams must show why AI cannot do the work before they ask for more headcount.

The sentence I keep going back to sits in the middle. The summer before, Lütke had invited everyone to tinker with AI. Many did, and he describes the people who took it furthest with real admiration. Then he writes: “The call to tinker with it was the right one, but it was too much of a suggestion.”

I’ve seen many of these people approach implausible tasks, ones we wouldn’t even have chosen to tackle before, with reflexive and brilliant usage of AI to get 100X the work done.

Read that way, the memo describes how AI had already spread inside Shopify. A group of people played with it until they were doing work nobody had planned for, and the memo is the company trying to make that everyone’s job. It also builds a way to pass the lessons around. Point four reads “Learning is self directed, but share what you learned,” and names the Slack channels where people already swapped prompts, #revenue-ai-use-cases and #ai-centaurs, with a promise to share “Ws (and Ls!)” and to make time for AI in monthly business reviews.

Duolingo measured the usage and then let it go

Three weeks after Shopify’s memo went public, on April 28, 2025, Luis von Ahn, the CEO of Duolingo, posted his own “AI-first” memo on LinkedIn. According to Fortune, it said the company would gradually stop using contractors to “do work that AI can handle,” and that headcount would grow only if “a team cannot automate more of their work.” Employees would also be assessed on their AI use.

The reaction came mostly from outside the company. Commenters wrote things like “AI first means people last,” and von Ahn later told the Financial Times, “I did not expect the amount of blowback.” By August he was telling the New York Times, “This was on me. I did not give enough context.”

The part that interests me came a year later. In April 2026 von Ahn said on the Silicon Valley Girl podcast that Duolingo had stopped evaluating employees on their AI use. As Fortune reported it, people had started asking whether the company “just wanted them to use AI for AI’s sake.” His new rule: “the most important thing in your performance is that you are doing whatever your job is as well as possible. A lot of times AI can help you with that.” And then: “I’m not going to force you to do that.”

Both memos told every employee to use AI. A metric on usage produces usage, and people noticed that the usage was the thing being scored. That lesson cost Duolingo a year. What neither memo can do on its own is turn usage into changed work, and the people who do that turning are a much smaller group. Vas, the CEO of Varick Agents, put that group at 5‑10% of one large rollout, and I wrote about his barbell in Why AI licenses rarely make a company faster. This note is about that slice: who they are, and what a company can do so that their work spreads.

The people who spread it build for their own work first

The clearest advice I have read on this came in January from Nikunj Kothari, a partner at FPV Ventures, in a post addressed to CEOs.

Hire tinkerers. Make it high status. Find ones that will explore the edges and (ideally) naturally gifted at teaching people. Empower them to freely roam across the org and fix large problems that can be automated.

He also predicts the objection: “All your execs will complain that these tinkerers don’t understand scale or systems (rollout being a favorite word).” His answer is to listen and ignore them, “or even better give them budget to hire a tinkerer to achieve their targets.”

Cody Schneider, who is building Graphed, describes the habit from the inside: “whatever I’m working on, I’m trying to automate parts of it in the background while I work on it.” After a while, he writes, “you start seeing every repetitive action, every manual process, every annoying workflow as a bug.” His estimate is that fixing “3–5 of these bugs every week” leaves you with your own automations, research agents and monitoring a few months later. He calls the result “the equipped employee,” someone who shows up “with their own internal R&D department in their backpack.”

The third example shows what happens when a team gets the same access at once. The Boring Marketer, a marketer who posts under that name, describes an ad agency with one Claude team account connected to “the 3-5 software tools being used on a daily/weekly basis.” “Each person has access. No gatekeepers.” Ad managers write new ad scripts from the agency’s own data without waiting on the Creative Lead, with this result: “Learnings within the day vs a week to get an ad created.”

Aaron Levie, the CEO of Box, wrote a job description for the formal version of this person in April. He calls it the agent deployer: someone who maps a team’s workflows, finds where agents add the most, and runs them. Two details in it matter here. The person needs “full autonomy to connect up business systems,” and “the company believes it’s safe for them to do so.” And there will be “one or more of these people on every team, so it’s not a centralized role per se.”

Put the four next to each other and the pattern is plain. These people start from their own work and their own annoyances. They need permission to connect real systems, which a license alone does not give them. They live inside the teams. And the good ones teach, which is the part Kothari puts in brackets and I would put first.

Private gains stay private

The risk with tinkerers is that their gains stay with them. Alex Lieberman, a founder of Tenex and Morning Brew, shared his notes from a call with the Chief HR Officer of a $500m consumer business. Two lines in them describe most companies I know. “Key challenge is ‘haves vs have-nots’.” And: “Most advanced users building agents for personal workflows, not yet for scalable company processes.”

Seth Rosen, co-founder of TopCoat and now building Thruwire, gave the pattern a name in June. “If every employee has their own chat, their own memories, and their own files, a few of them get sharper in private. The organization gets nothing.” He calls it “AI hero ball,” and his fix is a contract: everyone keeps their own tools, but every session “leaves the shared structure in better shape than it started.”

Reward the people who build the system, and the ones who use it.Seth Rosen, June 2026

Give them time, status, access and a way to share

A company can design for this with four choices, and I would make them in this order.

1. Time that is protected. A tinkerer who builds only in the evenings builds for themselves. Give the people who already experiment a fixed share of their week for it, and put AI on the agenda of the monthly review, the way Shopify’s memo does.
2. Status that others can see. Kothari’s “make it high status” is the cheapest item on this list. Let the person who rebuilt the quote process show it at the all-hands, put their name on it, and let them report to someone senior enough to clear the path.
3. Budget and real access. Licenses are the easy part. The scarce thing is permission to connect the CRM, the shared drive and the ERP, with someone in IT who agrees it is safe, as in Levie’s description. Without that access the best people stop at copy and paste.
4. A way to share what works. A channel where wins and failures get posted, a shared folder of skills and prompts the next person can reuse, and a person who decides which personal tool is worth turning into a company process. That last step is where a tinkerer’s side project becomes a redesigned workflow with an owner.

Then score the outcome of the work and leave the usage alone. Duolingo spent a year learning that, and von Ahn’s new rule is the one I would start with.

This is also what the 100xworker Program I run is built around: people who want to become the AI person in their company, and who learn to build for their own work first.

If you want a first step this week, find the five people in your company who built something for themselves with AI this year. Ask each of them what they built, who else uses it, and what stopped it from spreading.