After my talk at Agile on the Beach 2026, a Software Engineer Leader from John Lewis & Partners came over with a question I wasn’t expecting. He didn’t ask which model we use, whether we prefer Cursor or Claude Code, or which MCP servers I’d recommend. He asked about the AI framework I’d mentioned almost in passing. Could I share it? He thought it might help his team.
That conversation stayed with me all the way home. The more I reflected on it, the more I realised he wasn’t really asking about a framework. He was asking about adoption.
There are countless articles explaining how to use AI tools more effectively. Every week brings a new model, a new workflow, another opinion on the “right” way to build software with AI. Those conversations are useful, but they’re almost entirely about the technology. I think the harder challenge, and the more important one, is helping people adopt it well.
AI doesn’t fix ambiguity. It scales it.
One slide from the internal deck I used to launch our framework simply says:
AI doesn’t fix ambiguity. It scales it.
The more we’ve adopted AI at Collecting Cars the more I’ve found that to be true. If your documentation is poor, AI consumes poor documentation faster. If your Jira tickets are vague, AI confidently implements vague requirements. If your architecture lacks direction, AI accelerates inconsistency rather than reducing it.
Equally, if your team shares knowledge, writes good specifications, documents decisions and continually improves the engineering system, AI compounds those behaviours too.
AI is an amplifier. The question isn’t whether you use it. It’s what you’re asking it to amplify.
We’d built half the guardrails
As engineering leaders we’ve spent years building technical guardrails: testing, observability, security, documentation, coding standards, target architecture, release processes. None of these exist to slow engineers down. They exist to reduce ambiguity, so teams can make good decisions without asking permission at every step.
When AI arrived, we naturally invested even more in those systems. What surprised me was how little we’d thought about the human side. Because the conversations I was having with engineers weren’t about tooling. They sounded like this:
Am I using AI enough? Am I relying on it too much? What should I still be writing myself? What skills matter now? What does good look like?
Those aren’t technology questions. They’re leadership questions. And without clear answers, everyone quietly invents their own
What we actually built
So we created a framework. Not a policy, a checklist or a scorecard. A shared language and a direction of travel. Enough structure to reduce uncertainty, enough freedom to experiment.
A few pieces of it, so this stays concrete rather than theoretical…
Ten levels of AI-first engineering: From autocomplete at Level 1 up to AI-native at Level 10. With a clear team target, everyone at Level 6 by June. Levels 7 to 10 we deliberately left open, to be shaped together as a team. The destination matters less than everyone knowing roughly where they are and what the next step looks like.
A compounding loop: Level 6 is where AI stops being a tool you use and becomes a system you improve. On pull requests, encouraging the team to ask five questions:
- What would have made this task easier?
- Did AI hit any gaps in understanding our codebase?
- Did it make repeated mistakes we should guard against?
- Which rules or skills are now stale?
- Is there anything here that should become a reusable pattern?
The answers update our rules, skills and context files, and they ship in the PR so the whole team benefits. Every merge makes the next task slightly easier.
Honest answers to honest doubts. One slide in the launch deck tackles the objections head on. “I don’t trust AI output.” Good, verification is non-negotiable. “I don’t see the point.” The mechanics got automated, the thinking didn’t. “What about my job?” We’re investing in upskilling you, not replacing you. The closing slide reads: a supported journey, not a deadline to fear.
That last part matters more than any of the levels. If people are privately worried about their jobs, no amount of tooling guidance will land. Psychological safety isn’t a nice-to-have in AI adoption. It’s a prerequisite.
Learning a circuit
Adopting AI has reminded me of learning a new circuit (think Spa, not PCB). The first few laps are about confidence. Then you find another couple of miles an hour through one corner and suddenly you’re arriving at the next braking zone much faster than you’re used to. The quicker you get, the more the next challenge changes.
And here’s the thing about circuits: they have barriers, gravel traps and runoff. Nobody thinks the barriers at Eau Rouge exist to slow drivers down. They exist to provide safety in a worst case and reassurance to commit. That’s what guardrails are for. Not restriction. Commitment.
That’s exactly what happened with us. By June, everyone on the team had reached Level 6. Every engineer and repo is now compounding with each PR and release, and we’re exploring orchestration, autonomous pipelines and looping together, the levels we deliberately left open.
And, true to the circuit, the speed exposed new corners. Our engineering strategy needs more attention. Our target architecture the same. Documentation became increasingly valuable because AI consumed whatever context we gave it. Even our pull request process had to change, because faster iteration created more PRs than our old ways of working could absorb.
The framework hadn’t failed. It had helped us discover the next corner.
Managers build systems
From Lenny Rachitsky‘s excellent collab research, article and podcast with Noam Segal I recently read that only around a quarter of tech workers believe they have a good manager, and that good managers are one of the biggest factors in whether engineers feel positive about AI.
I want to earn my place in that quarter. Not because I have all the answers, but because I believe our job is to build systems where people can succeed. Career frameworks, engineering strategy, target architecture, psychological safety, knowledge sharing, coaching. They’re not separate initiatives. They’re all parts of the same engineering system. AI simply increases the leverage of that system. The bowling alley!
Human guardrails
When people talk about AI guardrails, they almost always mean the technical ones. Testing, verification, security, observability. Those are essential. But AI needs human guardrails too. Clear expectations. A shared vision. A framework for growth. Space to experiment. Permission to fail. A culture that rewards learning and sharing.
Because AI doesn’t create great engineering organisations. It amplifies them.
That’s why I don’t think AI adoption is primarily a tooling problem. It’s a leadership problem. Our job is to build systems where both people and AI know what good looks like.
I promised that Senior Engineering Leader from John Lewis I’d share the framework, so I’ve included the slides from our internal launch deck below. Take whatever is useful. It’s built for our context (assisted by Claude) and yours will differ, but I suspect the human guardrails translate better than the technical ones ever will.
I’m curious what others have found. What human guardrails have you built around AI adoption? And what have I missed?
Olly Brand 