How Replicated Onboarded the Whole Company to AI Engineering
A couple weeks ago, Replicated (my day job), handed every engineer in the company two things: a rubric and access to Claude Max. Not just the enterprise subscription. They paid for personal Claude Max accounts on top of it. And then they told us to go build something.
That undersells what actually happened. What our team ran was one of the smartest org-wide AI enablement exercises I've seen, and I want to talk about why.
The Setup
The structure was simple on paper. Leadership blocked out a couple weeks. They wrote a rubric for what they called a "bootcamp project," and the rubric had a specific shape: whatever you built, it had to be your own product idea, and it had to walk through every meaningful surface of the Replicated product suite. Onboard with our SDK. Release it the way our customers would. Build your own thing, but build it the way a Replicated customer would.
Then they said: go.
That last part is the part I want to dwell on, because it's the part most companies would never actually do. They didn't hand out assignments. They didn't pick the projects. Every engineer in the company got free rein to pick something they were genuinely interested in and build it however they wanted. A cat adoption web app? Sure. A platform for reviewing and improving Helm charts? Go. A support dashboard for the CRE team? That's mine. I'll get to it.
Why This Format Is So Sneaky-Good
You can read the structure and miss the genius. The bootcamp was doing at least three things at once.
First, it was a real AI engineering bootcamp. Everyone got to lean heavy into Claude, learn what's actually good and bad about agentic workflows, and develop their own opinions through real reps. You can't accelerate an org's AI maturity by sending people a Loom. You have to give them something to build and the budget to try.
Second, it was a tour of your own product. When you onboard your own project to Replicated, you find every rough edge, every confusing doc, every spot where the abstractions don't quite line up with how a real customer thinks about their app. You can't read your way to that empathy. You have to feel it.
And then there's the third thing. This is the part I keep coming back to.
It was an outer feedback loop.
The Outer Loop
If you've read any of my earlier writing on cybernetics, you know I think most of the leverage in agentic engineering comes from getting your feedback loops right: the inner loop where the agent does the work, and the outer loop where the system itself gets better over time.
Our team built an outer loop directly into the bootcamp.
Every engineer was asked to keep a friction log: bugs, gaps, papercuts, noise, anything that got in the way as you took your own product through the Replicated experience. At the end, all of those friction logs were aggregated alongside the existing backlog. Then engineers were paired up to spend the next couple weeks burning through the list.
So the bootcamp wasn't just a learning exercise. It was a synchronized, company-wide pass over the product, instrumented with structured friction reporting, followed by a coordinated repair sprint. The exercise was the loop. The output of everyone's individual project became the input to a real, prioritized product improvement cycle. That's cybernetics, applied at the organization scale.
What People Built
The project ideas were all over the map, which was the point. Some were personal: someone built a web app for cat adoption. Others were tightly focused on our problem space, like a platform for reviewing and improving Helm charts.
Mine was a support dashboard for the CRE team.
I built a GitHub App that subscribes to webhook events for issues, PRs, and comment updates, and used those as the substrate for a dashboard purpose-built for how CREs actually work. I added an internal commenting layer so we could have side conversations on customer issues without polluting the public thread. I built a customer health dashboard that scored accounts based on the frequency and severity of the issues they'd opened. And because I have no self-control, I added gamification: a support leaderboard, a trophy case, achievements.
Then something happened that accidentally validated the whole thing. GitHub's API has been flaky for the last few weeks. Searching the issues API was returning inconsistent results for my teammates: one CRE would see a handful of open issues in the queue, another would see an empty list. But I'd built an internal Redis cache into the dashboard from day one. So whenever the GitHub API got weird, the dashboard stayed correct. A tool I built to learn AI engineering quietly became the most reliable view of our support queue.
I had a ton of fun building it, and I'm hoping we can open source it. I think open source maintainers would get a lot of mileage out of a better way to wrangle their support queues.
The Output
By the end of the exercise, everyone in the company had a deeper, hands-on understanding of the Replicated product. Everyone had real, applied experience doing AI engineering at depth. An enormous amount of shared notes, patterns, and gotchas flowed between teammates. And the product itself measurably improved, on a timeline driven directly by the signals the exercise produced.
I have to hand it to our founders. This wasn't a hackathon. It was a deliberately designed cybernetic system: a structured inner loop (build your own product, run it through the suite), with a structured outer loop (friction log, aggregate, pair, fix) layered on top.
If you run an engineering org and you're trying to figure out how to actually get your team into AI engineering, not the slide deck version, the real version: steal this format. Give people the tooling, the rubric, and the freedom. Make them use your own product to ship their thing. Have them keep a friction log. And then close the loop.
It was brilliant. I'd run it again tomorrow.
If you want to see what we're building, check us out at replicated.com.