Consulting for engineering teams that already code with AI.
AI-assisted development consulting. In a mature team, agents write the code, and the team's work moves to both sides of it: the spec before, the code review after.
If your team has the tools and not much has changed, the tools were never the missing part.
So What Was Missing?
I think it was how the team works around the code.
In my last role my mobile team was already using AI assistants, and code review had become the bottleneck. I was researching AI-assisted development, and I brought it to the team. My view was that the process itself had to change, starting from the spec.
The first decision was whether to build agents myself or adopt an existing framework. Installing a framework is the easy part. Fitting it to your team is the work.
Take refinement: the "how to" stays in your developers' heads, so the agents guess it at implementation time, and a wrong guess costs tokens, time and a frustrated developer.
Getting a Team to Keep Using It
Anything that hasn't earned the team's trust gets worked around, regardless of how good it is.
My mobile team was seven developers, and I led it. It needed to write code faster. Four of the seven were junior or graduate engineers, and there was one senior per platform, stretched between their own work, reviewing everyone else's code, and pairing with the people who needed it. Review quality was slipping.
We put an AI reviewer into the GitLab CI pipeline. A graduate engineer from the team built that reviewer with me. It checked every merge request for SOLID violations and left findings as inline comments. It was also set up so it didn't flag things the team had chosen on purpose.
An AI code reviewer the team doesn't trust gets worked around or quietly ignored, and a new one hasn't earned that trust yet. I deliberately didn't fail the pipeline on its findings, and worked on making the signal better instead. Before I left, I had also moved it from a single agent to a multi-agent reviewer. I left before I could see the outcome of those last changes, so I won't claim one.
Anyone can point a reviewer at a pipeline. Getting a team to trust it enough to keep using it is the hard part.
If you want a team that still trusts its checks after the engagement ends, that is what the Rollout Advisory below is for.
How to Work With Me
I work with engineering teams in three ways: a Diagnostic that finds where reviews stall and specs are too vague, a Pilot on one team's real backlog, and a Rollout Advisory for the follow-through.
Agents do the implementation; your team owns the spec, the checks and the risk.
I work inside your team, the way a forward deployed engineer would, not from the outside.
Diagnostic
A fixed-price, short engagement. I audit how your team actually uses AI-assisted development today: where reviews stall and where specs are too vague for AI output to be checked. Not a pitch for a bigger engagement.
You end up with: a written brief, ranked by what to fix first.
£3,000
Pilot
One team, on a real backlog. Before deciding whether to go further, you see your agents help write stories they can work from without guessing, on your own codebase. It is the fix for what the spec leaves out, the problem described in So What Was Missing? earlier on this page.
You end up with: stories an agent can finish, written for your team's codebase, tools and rules.
Fixed scope, on enquiry.
Rollout Advisory
A way of working or a reviewer the team doesn't trust gets worked around. This is the follow-through on the trust problem above, after the Pilot or on its own.
What it aims at: a way of working your team still follows after I have left.
Fixed scope, on enquiry.
The Review Step, in Production
Revue.sh is the AI code review that runs in CI once the code is written: a multi-agent tool for GitHub, GitLab and Bitbucket. It launched publicly on 10 June 2026 and is in production today.
Get in Touch
Tell me how many engineers you have, and which AI tools they use if you like, and I'll get back to you.