Talk: scaling AI-driven development across our teams

None of what follows is a proof of concept.

At our June Afterwork, Hannes took the stage for a talk called 'Skills at scale', a look under the hood of how we build software with AI. The workflows, skills and agents he walked through are not experiments. They run in production, in our teams, today. What he told was the story of the last three years: from ordering GitHub Copilot licences, to running an agentic software factory.

The big idea

The shift that matters is not better code generation. Three years ago these tools did autocomplete on steroids: suggest the next word, the next line. Today an engineer orchestrates the agents that do the work. The whole talk was about what it takes to industrialise that shift, so speed compounds into quality instead of chaos.

> "One skill is cool. A hundred skills on an atomic base, creating compounding effects, is purely magical.”

Rookie mistakes

We didn't get there overnight. Early on we made the mistake many companies still make: treating AI as just a new tool to do the same job.

When Generative AI entered our world, we did what every self-respecting company did: we ordered GitHub Copilot licences for the entire team. When that mostly raised our software bill, we replaced them with Cursor licences for the entire team, because Cursor was the tool of the day.

Both were the same mistake, or milder, naivety: buying tools is not the same as changing how you work.

Things we got right early

The first is true to our DNA. We have a builder culture, full of people who would rather try a new thing than talk about it. That energy landed in a Slack channel, #generative-ai, still one of our most active today, where failures and insights get shared so the whole team can build on them.

The second was a bet on optionality. We built Trellis, our AI governance and orchestration platform. It gives us an LLM gateway to safely reach for new models, do usage and cost monitoring, set up secure integrations, and create sandbox for agentic workflows. When Claude Code arrived, roughly a year ago, we had the playground ready. By the autumn of 2025, our whole engineering team and much of product and design were orchestrating agents rather than typing every line or pushing pixels.

The first walls

Speed on its own creates new problems. Our engineers were fast, but the bottleneck simply moved to product managers trying to keep up with discovery, or quality engineers trying to keep up with faster release cycles. Fast doesn’t automatically equal good.

We also expected the gap between the most and least fluent people to shrink as everyone adopted the same tool. It did the opposite. The people who already knew how to work with agents pulled further ahead, while others gained far less from the exact same tool. With AI-first rapidly becoming the default, we want everyone on board. So closing that gap became a priority.

And a decade of deliberate team autonomy started to strain: when almost every best practice needs rethinking at once, you suddenly need standardisation, without crushing teams used to finding their own way.

Skills: the unlock, and a new luxury problem

A month later, Anthropic introduced agent skills, bringing with it a huge unlock in efficiency and quality.

A skill is simple: a single file or folder of instructions you feed an agent to do one task, consistently. If the agent is a chef, skills are the recipes. They became an open standard, they are composable like atomic design or microservices, and they only load when invoked, so they don't flood the context window.

So we codified our expertise into skills, by the dozen and then the hundred. And that is where it broke. A commit skill built for one team made assumptions that did not hold in another codebase. We ended up with twelve slightly different commit skills, and over 600 skills in total. Quantity means nothing if you can't keep up with the quality.

Making skills scale

Fixing this took a few months, and it is the part worth stealing.

We group skills into Claude plugins by community of practice: general ITP skills for everyone, then skills per discipline, then niche domain skills like Flutter or .NET. Every plugin has an owner, a practice lead who maintains what sits under it. We manage them in GitLab and distribute through our own marketplace and the Anthropic plugin marketplace, with a visual interface on top of Trellis to make 400 skills discoverable and spot duplicates.

Four lessons stand out from building well over 800 skills:

• Name and description decide whether a skill even gets triggered.
• Prefer small atomic skills over large ones. They are easier to chain, test and improve.
• Match freedom to the job. Text-based skills for creative work, script-based when you need the exact same output every time.
• Separate context skills from workflow skills. A workflow skill (commit the code) invokes a context skill (our git guidelines) that carries the standards.

Quality then flipped from liability to asset. We now run automated skill evaluations in CI, collect ratings from the team, and use Trellis monitoring to see what to boost and what to deprecate.

Stop the slop

There is a human milestone underneath all this, and it became our internal rallying cry: stop the slop.

Any AI drifts toward generic output over time. That is precisely why you let it handle the predictable, repeatable work, so people are freed to add the things only people can: taste, judgement, differentiation and, above all, accountability. You cannot hide behind "the AI made this". What you own is "I made this with Claude. I checked it. You can trust me." That is the relationship we are building, and it is how we onboard every new person, team and client.

Rewatch the session

Some talks are worth more than a recap. This is one of them, so here is Hannes in full.

Where to start

Take the four things that made the difference for us.

• Be decisive and prefer open standards, because a wrong decision you can reverse beats waiting for a perfect one.
• Back your early heroes and give them the tools.
• Look for the compounding effect, because a hundred atomic skills building on each other is where it turns magical.
• And take continuous small steps over big leaps, because anything you bet big on today risks being irrelevant by the time you ship it.

Want to talk about upgrading your own AI-driven software factory?

‍Get in touch.

Wouldn’t mind being part of a rocket ship like this?

‍We’re always hiring.

‍