Usage isn’t adoption. Here’s what we measured instead.

Usage is easy to measure. Real AI adoption—and the impact that comes out of it—is a different thing entirely. In their 2026 State of AI report, McKinsey found that 88% of organizations use AI in at least one business function, but only 39% report any enterprise-level EBIT impact.

While many organizations have gravitated towards measuring tokens as a barometer of AI adoption, Rupert Rutland, Engineering Manager at Typeform, took a different approach.

“Tokens tell you that people are using the tool, but it doesn't tell you whether the tool is creating value,” says Rupert. He likens it to gas in a car. “If you're burning a lot of petrol, how do you know you're just not going around in circles?” Instead, says Rupert, you need to know if the tool is creating value, and “getting you to the top of the mountain.” 

Real confidence using AI coding tools and making a code change themselves. An improved relationship between engineers and R&D. People across the company who are empowered to have an idea and implement it. That’s what Rupert was after. 

To achieve it, he created the Vibeformers. 

Over four weeks, eight non-engineers across Typeform coded tools and agents that their teams now use daily. Their reported confidence with AI tools nearly doubled, from 2.6 to 4.3 out of 5. The program scored an NPS of 67. No one counted any tokens to get there.

Meet the Vibeformers

The idea for the Vibeformers project came from an interview Rupert heard with Boris Cherney of Anthropic (creator of Claude Code). Cherney said that everyone at Anthropic contributes code, even the finance team. Rupert wondered whether they could do something similar at Typeform and after a few Slack DMs with the VP of Engineering and Director of Engineering, quick approval meant the project was underway. 

“I used Claude Code itself to iterate and talk to as my partner for ideating on the project,” says Rupert. The four-week sprint ran May through June of 2026. Every participant was paired with an engineering buddy who reviewed pull-requests, and all code was written with Claude Code or Gemini. There was no manual coding by the eight non-engineer participants who worked in Content, Tracking, Product Designer, and as Project Managers across Research and Development.  

Coding projects created by the Vibeformers during the sprint had to meet certain parameters to stay in scope: 

• An engineer had to be able to review and merge code improvements in under 30 minutes
• The code couldn’t be related to authentication, billing, database migrations, or anything cross-service 

That meant most of the work was small by design: wording, settings, and minor front-end tweaks. But as Rupert and the Vibeformers would find out: even small code changes could lead to major day-to-day improvements for participants.   

Gap analysis, data tracking skills, and other Vibeformer innovations

Catherine McIlroy, one of the Vibeformers, runs Help Center content at Typeform. She writes help articles in Zendesk and then publishes them on the Help Center. As a Vibeformer, she built a Google Doc-to-Zendesk publishing tool, plus two AI agents that run a weekly Help Center gap analysis. The agents make sure that when people ask questions about Typeform, there's an article there to help them. 

“It had nothing to do with code contribution,” says Rupert. “She just automated a monotonous part of her job.” What she built speeds her up and gives her back hours every week. Rupert hopes that means she’ll reach for Claude Code for future problems, too.

Stephani, a member on Rupert's team, works on data tracking and built a Claude Code skill her whole team now uses daily. Previously, when there was a new product element to track (an event, button, or user action), someone had to go into the front-end tracking library and add it manually. One ticket at a time. Stephani’s skill automates that step. 

"It's already our new way of working,” reports Stephani. “We immediately reduced dependency on engineering, saving countless hours."

"This wasn't the plan at the beginning," Rupert noted. There was no mandate for Vibeformers to “create efficiencies” or increase token usage without a concrete outcome to show for it. The original idea was just to get people contributing code. But because everyone in the project had the support and tools they needed, they were able to surface, try, and realize an idea within the four-week sprint.

Stephani saw an opportunity to fix a problem that impacts the day-to-day experience of her team, and took it. Efficiency is a byproduct when you have engineering oversight and a powerful AI-coding tool at your disposal. 

Noa Peeters, a Senior Product Designer was able to make small UI changes directly in the product. “It’s been great for vibecoding prototypes,” she says, “and it's helped me get much more familiar with our codebase—which is incredibly useful for understanding technical constraints as a designer." She’s also been able to build her own Figma plugins to improve her design workflow. 

"When people understand the possibilities of something like Claude Code, it wakes up the creative side of their brain. It was great to see that kind of innovation during Vibeformers." – Rupert Rutland, Engineering Manager, Typeform

Mission accomplished: 2x confidence

Rupert surveyed the group at the start, middle, and end of Vibeformers. Throughout the project, confidence with AI coding tools in general climbed from 2.6 to 4.3 out of 5. Confidence in making a code change increased from 2.6 at the beginning of the project to 4.0 out of 5 by the end of four weeks, and the program scored an NPS of 67. Every participant surveyed said they would recommend a similar program to a colleague.

"It's not just a productivity tool, it can genuinely change how non-technical people contribute to a product." – Stephani, Vibeformer, Typeform

Over four weeks, the eight non-engineers in the Vibeformers project merged 28 pull requests across 14 repositories. Which is 28 more than the previous baseline of none—from people whose job isn’t engineering, in roughly one week of actual building. 

This work didn’t change the product roadmap for Typeform, but it changed how people move through it. Stephani's skill and Catherine's agents are ops improvements rather than product features, but Rupert is looking forward to revisiting the outputs in six months to measure their cumulative impact.

But it wasn’t all smooth sailing for Rupert, who assumed fluency with Claude Code would be the biggest hurdle for most participants.

“Coding wasn’t the barrier—it was everything around it.”

For three weeks, at the start of the project, nobody wrote any code at all. 

First, there was a hardware hurdle no one had accounted for. Engineers' laptops are configured a specific way when they join Typeform—there's a long technical checklist they work through and it’s highly specialized. A non-engineer's laptop has none of that.

Rupert and his team had to add missing engineering pieces to “normal” laptops. But because every Vibeformer’s setup was different, they couldn’t run one standard process to solve it. Engineers had to figure out, for each, what was already there and what was missing. 

Rupert had Claude Code help him build a checklist of everything a Vibeformer and their buddy needed to get through, and the Vibeformer pairs worked down that list until each person was set up. 

The laptop misconfig was a grind, but it was still solvable person-to-person. The bigger stumbling block for the team came in the form of token provisioning. Typeform’s original way of paying for Claude Code tokens was, in Rupert’s words, “too complicated for non-engineers.” They had to move the Vibeformers to enterprise accounts to get around it, which meant hitting pause on onboarding for several weeks. 

*Typeform’s internal hackathon

“Coding wasn’t the barrier,” says Rupert, “the friction was everything around it—git, terminal, local dev setup, and the pull-request workflow.” In the future, he says, he’d run the entire program with one person to start. “Fix the first hour of onboarding and you’ll keep most people.”

A token dashboard would have shown a flat line throughout this prolonged runway to get Vibeformers up and running. But that would discount every gain that came after.

Skill isn’t the metric—judgment is

For Rupert, the barrier to building something truly useful isn’t about technical skill. AI handles code-writing now, so getting “in” isn’t the hard part. Knowing what to build, how it fits into the larger system, and what could go wrong are. 

"Identifying the change I wanted to make and then making it with Claude was by far the easiest part of the process,” said one Vibeformer, “It was the dev dependencies and commands that were the hardest thing to get my head around."

Typeform engineers saw an unexpected benefit from the project. More people better trained to request changes and implement them frees engineers to focus on bigger questions around architecture and performance. 

All of these things—the time spent to make Claude Code a usable tool for non-engineers, the burgeoning relationships between engineers and product people, and a growing confidence across new teams about wielding AI tools—didn’t happen because some CEO pushed for “more consumption.” 

They’re the pieces that need to be in place for AI adoption to take hold in an organization in the first place. 

If you’re pushing for adoption, don’t get fixated on the consumption and counts. Measure what’s hard to fake—creative engagement with the tools.

The tokens will take care of themselves.