← Back to Blog

The Shop Floor Is the Classroom

May 10, 2026

Tobi Lutke built an AI agent that only works in public. It accidentally recreated the apprenticeship model I've been arguing for. Capability over functionality, taste over technique, and why the best AI rollouts look like a German Lehrwerkstatt.

Tobi built the thing I've been talking about

Tobi Lutke posted a piece this week about River, Shopify's internal AI agent. 5,938 employees used it in the last 30 days. It opened 1,870 pull requests in a single week. One in eight merged PRs was authored by an AI, reviewed by a human.

That's impressive, but it's not the interesting part.

The interesting part is a constraint: River only works in public. No DMs. No private windows. Every conversation happens in Slack channels anyone at Shopify can see, search, and join. Tobi works with River in #tobi_river — over 100 people watch, react, add context, pick up threads, and learn.

He has a German word for it: Lehrwerkstatt. A teaching workshop. The whole shop floor is the classroom.

When I read this, I felt like someone had built the production version of something I've been arguing for in panels and on the Hong Kong AI Podcast.

Capability, not functionality

At the Snowball Asia panel, I said something that I keep coming back to:

We should think about rolling out AI in terms of capability rather than functionality.

It sounds a little wuwu. But the distinction matters. Functionality is a feature list — the agent can query a data warehouse, open PRs, run tests. Capability is what a team can now do that it couldn't before. The difference is organizational, not technical.

When you roll out AI as functionality, you get a tool adoption problem. Usage dashboards. Training sessions. ROI spreadsheets that nobody believes.

When you roll out AI as capability, you get something closer to what Tobi describes — a support engineer in #help_checkout watches a backend engineer get River to find the right log query, and the next day she does the same thing herself. No training plan. No curriculum. Osmosis.

That's capability transfer, not feature deployment.

What good sauce tastes like

I keep using a cooking metaphor because it lands with non-technical audiences:

You don't need to know how the sauce is made as much anymore, but you need to know what a good sauce tastes like. You need to have a mental model in your mind of how to get to a good sauce.

This is exactly what's happening in Tobi's #tobi_river channel. When 100 people watch a CEO work with an AI agent, they're not learning the agent's API. They're developing taste — the ability to look at a prompt, a code review, a debugging session, and know whether it's heading somewhere good or somewhere generic.

AI regresses to the mean because it's trained on everything. Taste is the departure from the mean. And taste spreads through observation, not documentation.

Tobi's numbers prove it. River's merge rate climbed from 36% to 77% in two months. They didn't retrain the model. They didn't switch providers. People watched River work, noticed where it got stuck, and wrote down what it should have known. Every team's accumulated taste flowed into the agent.

The apprenticeship argument

At the same panel, I said something that felt contrarian at the time:

I do think we might need to go back to an apprentice-master kind of apprenticeship. You need to learn things maybe more by observation and then sort of non-verbal, subtle cues.

Tobi's piece opens with exactly this — his own apprenticeship at a Siemens subsidiary in Germany, learning to program by making coffee for the people in the basement and hanging around long enough that their judgment seeped into his.

The standard worry about AI is that juniors will stop learning. Why debug if the agent debugs for you? Why read the codebase if you can just ask?

But Tobi's answer — and mine — is the same: the risk isn't that AI does the work. The risk is that AI does the work in private. If every interaction happens in a private window, the only person who learns anything is the person at the keyboard. Everyone else is locked out of the apprenticeship.

River makes the apprenticeship public. The best prompt patterns spread. The clever investigation becomes a template. Skills written for one team get reused by twelve others.

Software that adapts to users

A Forrester article I keep citing — "When code is free, what's left to sell?" A 70-person Hong Kong manufacturer replaced its SaaS stack with AI-generated applications. Custom HR systems built in two days.

The implication I draw from this:

You can have the software adapt to the users rather than the other way around, like SAP and other ERPs.

River is the internal version of this same idea. Each team pre-loads River with their own zones, skills, and instructions — written by the people closest to the work. The agent doesn't ship as a finished product. It ships as a capability that each team shapes to fit how they actually work.

This is what I mean by capability over functionality. You're not rolling out a tool with a fixed feature set. You're rolling out an apprentice that every team trains differently, in public, and the training compounds across the entire company.

The speed of the slowest secret

Tobi writes: "The company moves at the speed of its slowest secret."

Meetings are slow. Email is slow. Private DMs are slow — not for the individuals, but for the organization. The information never fully diffuses without huge additional effort.

I like my hammer. My hammer is Claude Code. I tailor it, I make sure the handle is smooth. But I also recognize that my style of development — focused on a single tool, maximizing efficiency — is a private-window approach. The productivity gains are real but they don't compound across a team.

What Tobi built forces the compounding. Every public conversation with River is searchable, teachable, and builds on the last one. The next person who has the same question doesn't have to ask it.

What this means for enterprise AI rollouts

If I had to distill all of this into advice for someone leading an AI rollout, it wouldn't be about which model to pick or how many PRs the agent can open. It would be four things, all about visibility:

Make AI work visible. The learning comes from watching, not from using. If your teams interact with AI agents in private, you get individual productivity gains. If they interact in public, you get organizational capability gains. The difference is multiplicative.

Invest in taste, not training. You don't need a curriculum for AI adoption. You need your best people using AI where others can see them. The judgment — the sense of what a good result looks like — transfers through observation. Non-verbal, subtle cues.

Enable capability, not functionality. Don't measure success by adoption rates or feature usage. Measure it by what teams can now do that they couldn't before. Can a support engineer debug like a backend engineer? Can a new hire scope a request like a senior? That's the signal.

Let teams shape their own agents. The agent should adapt to the work, not the other way around. Each team's accumulated knowledge should flow into how the agent behaves for them. Surgical software, not one-size-fits-all platforms.

But here's what I keep circling back to. We're surrounded by extraordinary complexity now — agentic harnesses, multi-model orchestration, tool-use chains, memory systems, RAG pipelines. And yet the thing that made River actually work wasn't any of that. It was making conversations visible. It was people watching other people work and picking up cues. It was, at bottom, great communication.

IRC was pretty good at that, wasn't it? Open channels. Searchable logs. Anyone could lurk and learn. We had the infrastructure for Lehrwerkstatt thirty years ago. We just forgot what it was for. Maybe the most important thing AI agents will teach us isn't how to write better code or ship faster. Maybe it's that the most powerful tool in any organization was always the simplest one: a shared space where people can see each other think.