Most companies rolling out AI coding tools follow the same playbook: stand up a platform team, build an internal publishing layer, package everything into a single installation, then roll it out to the company. It makes sense if you have a thousand people. It makes sense if you want controlled adoption.

We took a different path. Lorikeet has 70 people. Everyone uses Claude Code day-to-day. We didn’t build a platform to make it happen. We didn’t assign a team. It happened because of the kind of people we hire and what we gave them access to.

No platform, no problem

At an event a few weeks ago, there was an impromptu sharing session on “AI chief of staff” and personal AI productivity tooling. Company after company described their setup. What surprised us was that we appeared to be the only company with a shared repository of personal productivity skills that gives everyone access to the same tools the CEO uses, configured to their own role.

That sounds small. It isn’t. At most companies, the founder builds their own Claude Code workflows – maybe a daily planning routine, maybe a sales digest – and those stay private. The tooling compounds for one person. Everyone else starts from scratch.

We took the opposite approach. Every skill that works for leadership gets generalized and pushed to the repo. A skill to plan your day has a personal config section so anyone can use it. A skill to scan Slack update channels takes personally configured instructions for what to scan for. The BDR team has prospecting skills. The FDE team has subscriber diagnosis skills. The marketing team generates release content. The repo is open and anyone can contribute.

What makes it stick

Getting AI tools into the hands of non-engineers requires deliberate effort. The conventional answer is to build a platform. But there’s another way: build a culture where people just start using the tools because the environment makes it easy and the norms make it expected.

A few things made this work at Lorikeet without a dedicated team.

First, we connected Claude Code to everything early. The Lorikeet MCP for internal and external use was spun up quickly because we saw the potential. HubSpot, Linear, Grain, Notion, Slack, BigQuery, Google Calendar – they’re all wired in. When someone sits down with Claude Code for the first time, they can immediately do useful work because the connections are already there.

Second, early advocates made it their business to get people set up. Loom walkthroughs, start-up guides, open availability to help. This wasn’t someone’s job title. It was people choosing to spend time onboarding their colleagues because they were genuinely excited about what the tools could do.

Third, we removed the spend constraint. We openly allowed people to blow through Claude Code limits. Our team did hard work to battle Anthropic to make the pricing work for company-wide usage. Not many companies treat that as a priority. Most ration access, which sends an implicit signal: this tool isn’t really for you.

Agency plus tools equals dynamite

One of our senior engineers put it in a way that stuck: “Lorikeet over-indexes on hiring people who have agency and who do things without being told. We always saw this, but when coupled with being given the keys to Claude Code and access to logs, repo, database, and all the MCPs, we saw magic occur. Endlessly curious, high-horsepower people with agency plus Claude Code equals dynamite.”

That’s the part that’s hard to replicate with a platform. You can build the best possible infrastructure for AI adoption, but if your culture doesn’t reward people for using it in unexpected ways, adoption plateaus at “the things the platform team thought of.” Agency is the multiplier.

Here’s what 70 people with agency and Claude Code have built at Lorikeet, without anyone telling them to: an internal podcast that synthesizes information from key data sources and distributes it company-wide. Highly contextual microsites for subscribers and internal teams. A tools site at lorikeet.tools that started as an experiment. Countless Notion documents that in another company would have taken a week of analyst time. A non-engineer on our sales team is building a daily planning tool that pulls from her calendar, Slack, HubSpot, and Notion goals to suggest how to block her day. Nobody assigned that project to her.

The real question

The question isn’t whether you need a platform team to make AI tools work for non-engineers. It’s whether you’ve hired people who will figure it out on their own if you give them the right access and get out of the way. The platform is a solution to a problem that agency solves first.

At 70 people, we don’t have the luxury of building internal publishing platforms or design system overhauls for a tools catalog. What we have is a shared repo, a culture of contribution, and a bias toward just building something when you see a gap. As we grow, some of this will need more structure. But the foundation – hire people with agency, give them the real tools, remove the constraints, let them surprise you – is something that doesn’t scale out of relevance. It’s how you get a company where everyone builds, not because you gave them a platform, but because that’s the kind of person they are.