Your Best Engineers Have a Playbook. Your Team Doesn't.

Every engineering leader I talk to is running an experiment right now. We know AI lets our teams write code much faster. What we don't know yet is what process and policies we need around it.

I want to focus on one gap that I think will become one of the biggest.

The same tool, very different results

Hand the same model to two engineers and you can get two very different products.

One knows how to frame the problem. They give the model the right context, ask the awkward follow-up questions, and know where the model tends to cut corners. They understand the product, so they notice when something technically works but makes no sense for the customer. In a few days they ship something that would have taken a team months.

The other uses the same model, gets something that runs, and ships it. Most of the time that's fine. Sometimes it breaks something nobody checked.

That gap was always there between people. But AI multiplies it. When the model does most of the typing, what's left is judgment: what to ask, what to check, what to distrust. And judgment is unevenly spread across every team I've ever worked in.

So the question I keep coming back to as a leader is: how do we get everyone working the way our best people already do?

Skills exist. Using them is the hard part.

The industry has already started on this. Skills, custom agents, shared prompts: these are exactly the attempt to capture what a senior person knows and hand it to everyone else. And there are already places to store them, from team repos to central skills registries.

But in practice, most of these live a step away from where the work actually happens. Someone has to know the right skill exists, remember to pull it in, and use it at the right moment. The engineers who most need the help are usually the ones least likely to go looking.

And a registry can't answer the questions a leader actually has. Which of these must always be followed? Which ones are just good advice? Are people using them at all? Are they making the work better?

From skills to playbooks

This is why we talk about playbooks instead of skills or registries.

A playbook is how your best people work, written down and built into the way the team ships. Take how a strong senior engineer reviews an AI-built feature. They don't read it line by line. They map out the feature first: which systems it touches, which tables and queries changed, which user journeys are new, what's tested and what isn't. Only then do they decide where to look closely. That way of thinking can be captured once and offered to everyone, every time.

The important part is that not everything in a playbook carries the same weight:

• Must follow. A few steps are non-negotiable. A change to payments runs through the critical journey tests. A new table gets a performance check.
• Recommended. Most steps are guidance. Good defaults that people can skip with a reason, when they know better.
• Shared and improved. When someone finds a better way to investigate, test or review, it goes back into the playbook, so the next person starts from there.

We're not trying to make everyone work the same way. We want the average work to look a lot more like your best work.

Seeing what's actually happening

If you lead an engineering organization, you need a simple overview. Which playbooks are teams using? Where do people skip the recommended steps, and is that a sign the playbook is wrong or that the team needs help? Which must-follow checks keep catching real problems, and which ones never catch anything and should probably go?

That last question matters. A playbook that only ever grows becomes a checklist people tick without thinking. The overview is how you keep it honest: keep what catches real issues, drop what doesn't, and let the practice get better over time instead of heavier.

None of this is about watching people. You just want to know whether the way you've asked the team to work is actually working.

Why we're building this into Adaptl

At Adaptl, we don't want playbooks to be a separate library you have to remember to visit. We're building them into the way a change gets made, from the first piece of feedback to the merge.

Some of this already works. A project can require a yes from a named group before a change merges, an owner who overrides that has to say why, and a change that touches sensitive code is flagged for a security review. The rest is still ahead of us, and this is where we're taking it.

You'll be able to bring in the skills and agents your team already has and turn them into playbooks. From then on, Adaptl will make sure they're used at the right moment: when a feature is defined, when the code is generated, when a change is reviewed, and before it merges. The must-follow steps will be enforced on every change that goes through Adaptl. The recommended ones will be offered. And it will all be visible, so leaders can see how the practice is used and how it improves.

We don't want to be one more place where knowledge gets stored. We want it to show up in the work.

The new standard

We used to build quality into teams by hiring good people and hoping their habits rubbed off on others. With AI doing more of the work, hoping isn't enough. The habits have to be written down, shared, and built into the way we ship.

My bet is that the teams who get this right will ship fast and still ship well, because their best people's judgment is behind every change.

If you're leading a team through this and wrestling with the same questions, I'd love to compare notes. You can find us at adaptl.ai.