We gave our engineers AI tools: Half the team barely scratched the surface

Access alone doesn’t create adoption. Here’s how we used data, communities, training, and skills marketplace distribution to get the productivity gains everyone dreams of.

---

We rolled out Claude Code, Cowork, and GitHub Copilot months ago in our engineering teams, hoping to get the productivity boosts everyone talks about. Some engineers embraced it immediately and started shipping noticeably faster. I always say we should be data-driven, so we collected data. The spread across individuals was wide enough that averages were almost meaningless: while some became heavy users right away, others barely touched the tools. Fostering AI adoption in your engineering teams turns out to require a lot more than buying seats: here is our journey and the strategy we put together to turn this around.

Buying seats is the easy part

Giving your team access to an AI coding tool is the minimum viable investment, but it did not give us the productivity boosts you read about on LinkedIn. A share of engineers will pick it up immediately, motivated and curious enough to figure it out on their own. A larger share won’t know where to start. Another group will try it once, not get an obviously impressive result, and quietly stop.

There’s also a subtler problem: since 2025, new AI tools appear every week. Without clear direction, engineers start exploring, a new agent here, a different IDE integration there. Breadth feels productive. It rarely is. I could see informal discussions between engineers trying new stuff every day. This curiosity is great, and it’s what keeps us learning and improving, but I felt we were missing widespread benefits. When attention spreads across too many tools, nobody has time to build the depth needed to work well with any of them. You can’t build shared skills, share workflows, or create a community of practice around six different tools simultaneously. We settled on two tools, Claude Code and GitHub Copilot, and built everything around them.

Measuring what actually matters

The first concrete thing we did was build visibility. To improve something, you must measure it.

We first ran monthly surveys asking engineers to self-report the percentage of code written with AI, productivity gains, friction points, and the workflows they’d found most useful. The qualitative signal was valuable to get first impressions and already showed promising results. But we also needed a more quantitative layer. We built a custom pipeline that ingests data from the Claude Code and Copilot analytics APIs and computes metrics: daily active users, sessions, lines of code accepted, agentic versus inline usage split, cost per user, and acceptance rates, tracked daily across both tools, etc.

The numbers confirmed the adoption was real. Claude Code was generating hundreds of thousands of lines of accepted code per month, growing roughly 30% month over month. On the Copilot side, agentic prompts went from near-zero in early February to hundreds per day by May, with the majority of monthly active users now working in agentic mode rather than inline completion.

But the spread was also very interesting: Per-user output varied significantly, and that variance told us exactly where to focus the enablement effort. We needed to bring everyone to a strong adoption to really benefit from AI at a larger scale.

Making wins visible

We set up dedicated Slack channels where engineers could share workflows, prompts, and results. One channel in particular was dedicated to AI for engineering, focusing only on the tools we selected. Other channels were also available for discussions about other tools, so people also have a space to explore outside of our ecosystem. This way, we fostered focus on our selected tools without preventing exploration and curiosity about AI in general.

The format was informal: someone posts what they did, how they did it, and what the AI produced. No required structure, no presentations to prepare. Just engineers showing each other what was working. It took some days to get started, and we leveraged leaders and strong adopters, encouraging them to post there, but we finally got momentum: there are multiple posts there every day now.

The Show & Tell sessions took the same principle and gave it a stage. In one session, a teammate walked through how we used an AI agent to validate and patch a bug bounty report end-to-end, from reproducing the issue to writing and reviewing the fix. Another engineer showed the room how they went from a Figma design directly to working front-end code without writing a line manually, entirely through an agent. One teammate rebuilt a full webmail application in two days over a weekend, alone.

Peer demonstration converts skeptics faster than any internal communication about AI productivity. It also gives practical examples and a place to start for people who are a bit lost approaching this new technology.

Training makes the difference

Visibility and community create motivation. Training turns that motivation into capability.

The survey data pointed to a consistent pattern: engineers who weren’t seeing strong results were often using AI in the most surface-level way, single-turn prompts, no context, no iteration. The difference is usually context. A prompt like “write a function to handle this error” tells the agent almost nothing useful. A prompt that includes the surrounding code, the architectural conventions, and a concrete description of the expected behavior gets a first draft you can actually build on. But even if you do it once, it can be boring, discouraging, and painful to rewrite a well-crafted prompt every time.

I took the online courses from Anthropic, and I now consider them a strong reference in the ecosystem. We pointed teams toward those courses as a foundation: Introduction to Agent Skills, Introduction to Sub-agents, and Build with Claude API (even if you don’t use the Claude API, it covers core concepts valuable when using AI tools). These courses cover how skills work mechanically, how to build them, and how distribution through plugins and marketplaces operates. This foundation helps understand why certain workflows are structured the way they are, and they can adapt and extend them. While I started learning about how to use AI by reading LinkedIn and Reddit, those courses put together many concepts in a structured and well-explained way.

People learn the mechanics in the courses, see a peer apply them in a context they recognize during Show & Tell, then go back and build something new. The two reinforce each other.

Building the skills marketplace

Informal sharing scales to a point. Beyond that, you need infrastructure and a lean distribution.

We built GAS, the group.one AI Skills marketplace, as a library of reusable workflows distributed through Claude plugins. It is an internal tool, but the model is straightforward to replicate: versioned repositories of skills, plugin manifests, and a distribution mechanism your team can install in seconds. An engineer installs the plugin and immediately has access to a curated set of skills that encode months of collective learning about how to work effectively with AI agents in your specific context. No prompt engineering required to get started.

The model serves three kinds of users at once:

• Beginners install and use skills as-is, which gets them past the initial blank-page problem immediately.
• Intermediate users customize skills for their context, adjusting prompts, adding constraints, tuning the workflow.
• Power users build new skills and contribute them back. The whole organization benefits from what any one team figures out.

Distribution helps to spread adoption: A skill shared in a Slack channel reaches a few people. A skill in the marketplace reaches every team that has the plugin installed, including teams outside of engineering.

Skills unlock real autonomy

The more significant change skills enabled was in how AI fit into the actual delivery workflow.

Before, engineers were managing AI step by step. Write the ticket, then ask the agent to groom it. Ask the agent to implement. Ask it to open the PR. Ask it to review. Every step was a separate prompt, and AI was actually waiting most of the time. The engineer was not doing the heavy lifting, but was a bottlneck spending time on low-value tasks to make the AI go to the next step.

The delivery-orchestration skill, part of our GAS library, changed that. It chains the full pipeline: ticket creation through grooming, implementation, documentation, definition-of-done checks, PR creation, peer review, and QA, with human review only at the points where judgment is actually required. The agent handles the transitions. The engineer steps in when a decision needs to be made, not when the next task needs to be initiated.

This matches what the usage data shows at scale. Agentic usage growing from near-zero to hundreds of prompts per day in three months shows a different mode of working entirely. And just like any way of working, it can be optimized with the help of technology and automations.

Fostering AI adoption beyond engineering

The marketplace model extends naturally beyond engineering. When our CPO noticed non-technical teams struggling to adopt AI, he came to me with a simple question: how do we help them? We sat down with people we wanted to help, picked one task they wanted to automate, and worked through it in an AI chat session, iterating until the output was good enough to use. At the end of the session, we asked the AI to turn the conversation into a reusable skill. A few days of refinement later, that skill was in the marketplace. Within a week, every PM in the group had access to a shared skill for writing PRDs. Most of those teams had never written a formal PRD before.

The new bottleneck

The constraint in tech has shifted. Arthur Mensch, CEO and co-founder of Mistral AI, described it well in an audition from 2026: solo, AI gives you 10 to 20 times the productivity. In a team of five, the gains start to drop. Communication overhead comes back. In a large company, he said, “you suddenly find yourself facing many organizational bottlenecks. That’s what needs to be overcome to achieve the productivity gains we dream of.”

The constraint has shifted from tooling to coordination. Developers are becoming managers of agents and, increasingly, the coordination layer between what agents can build and what the business actually needs. Implementation velocity is not the bottleneck anymore. Human and cross-team alignment is.

The teams that pull ahead will be the ones that re-invent themselves around AI, as AI-driven or AI-native: the measurement, the community, the skills infrastructure, the training, and ultimately, the organization that works around it.