AI-assisted software development

Buying licences is the easy part. What usually follows is uneven: a few people get a lot out of the tools, others have tried them and given up, and code review quietly turns into the bottleneck. Somebody reasonably asks what the assistants are allowed to see, and nobody is quite sure.

None of this means the tools don’t work. It means the working practices haven’t caught up.

What I help with

• Working practices. When to use an agent and when not to. Breaking work down so that an agent can do it well: a clear specification, a plan you review before any code is written, and tests that tell you when it has gone wrong.
• Reviewing AI-written code. It tends to look plausible, and that is exactly the problem. I help reviewers know what to look for, and set things up so that less of it needs a human in the first place.
• The toolchain. Instruction files that give agents your conventions and context, sensible permissions and sandboxing, MCP servers that connect agents to your own systems, and automated AI review in CI.
• Safety and policy. What code and data the tools may see, which actions need a person’s approval, and how to keep secrets and customer data out of places they shouldn’t be.
• Knowing whether it’s working. Simple, honest measures of whether delivery is actually faster and better, rather than just busier.

How I work with a team

I’m most useful embedded in your team for a few weeks, doing real work on your codebase alongside your engineers. Practices stick when people see them used on their own code, against their own deadlines, rather than in a demo.

That usually means pairing with engineers, setting up the tooling as we go, and leaving behind written conventions that belong to the team, not to me.

I also run workshops, for engineering teams or for technical leadership, as a way to start or alongside an embedded engagement. And if you want a view before committing to anything, a short review of how your team uses AI today comes with a written list of what to change first.

Why me

I don’t just advise on this; it’s how I work every day.

• My own development environment. Over a long period, I’ve built an AI orchestration system that I now use for all of my software development. Agents work in sandboxes, each piece of work on its own branch, and every pull request gets an automated AI review. The reviewer can approve routine changes itself, and flags anything that needs a person to look at it. Given a series of tickets, it works through them one at a time, taking each through its own pull request (with fixes being applied if the reviewer finds any problems) before picking up the next ticket. It’s for my own use and isn’t for sale, but it means my advice comes from daily practice rather than from a vendor’s slides.
• caffeine.ai: designed and built Caffeine’s CLI and MCP server, and took the MCP server through to a listing in Anthropic’s Claude directory.
• Rilbo: our own issue tracker has a built-in MCP server, so coding agents can pick up and update work with access the team controls.
• Writing software since 1979, and professionally for twenty-five years. AI changes how code gets written. It doesn’t change what good software looks like, and that’s the judgement I bring.

I’ll also tell you where AI won’t help, or isn’t worth the risk.