We pay for Gemini. Who still needs a Claude seat?

Start everyone on Gemini. Move people who keep asking engineers questions to Claude Tag in Slack. Give a Claude seat to the people who build things or do long, private work, inside engineering or outside it.

That approach keeps you out of two traps: seats nobody opens, and staff stuck on a tool that can’t do their job.

Look before you lead

It’s true, anyone can lead.

In twenty years I’ve watched people grow into leaders, helped a few get there, and grown into the role myself. How far each of us got depended on the trust, backing and incentives around us as much as on what we brought.

Before you say yes to a lead role, find out who will stand behind you when the decisions get hard.

Your coding agents need a gardener

Your coding agents repeat mistakes you corrected last week. A gardener reads what your team accepted on recent pull requests each week and proposes a lint rule or a sharper instruction when the evidence supports one.

The gardener opens each proposal as a PR with its evidence, and you decide whether it merges.

Shepherd fixes the PR, Stamp approves it

Shepherd and Stamp take a pull request from opened to approved.

Shepherd runs in your coding agent, reviews the change, fixes what it can and repairs the build.

Stamp runs in CI and decides whether the result earns an approval.

I give approval to a separate reviewer. You keep the decisions that need a person.

Local decision models with AI SDK Ollama

Ollama 0.35 runs decision models on your own computer. You give one a support ticket and a question like “which team should handle this?”, and it returns a percentage for each team instead of writing a reply.

ai-sdk-ollama 4.4.0 lets you call them from the AI SDK.

I ran 12 support tickets through the three new models and a small chat model on a MacBook Pro.

The decision models routed every clear ticket correctly.

On the tickets I wanted a person to check, two of the three models still sounded sure, and that changes how you set the rule that hands work to a human.

One Folder, One Topic: Convention-Based Design for Docs

Every company I have worked at has had the same documentation problem: teams need information they can find, share and trust.

At most of those companies, the answer has been Confluence, and the pages drift away from the code they describe.

At a payments client, we took a different approach. We created a convention: every repo keeps its docs in the same folder and carries the same GitHub topic. A small build discovers them, and Astro turns them into one site that engineers and AI agents can both read.

Give AI somewhere to prove its work

Earlier this year I led a team that used AI to replace a self-hosted FTP server with a managed file transfer platform on AWS.

It has run in production since cutover without an incident.

We used AI, mostly Claude with a mix of Codex, at every stage: research, build, and delivery.

In this post I’ll discuss what we did, and how we did it.

The Best Consultancies Make Themselves Less Necessary

I’m preparing for a talk with Equal Experts, and it’s got me thinking about consultancy.

I’ve worked for consultancies, alongside them, and inside companies while consultancies have come in to assess them.

Some experiences have been brilliant.

Others have made me uncomfortable.

And the more I’ve seen, the more I think the difference between a good consultancy and a bad one often has little to do with technical ability.

It comes down to culture, honesty, empathy and transparency.

But above all, it comes down to incentives.

Every consultancy has to make money. Of course it does.

But how it makes that money matters.

Test WebMCP tools like an API (with Playwright)

The Chrome team’s best practices and use cases guides end on evaluation tests.

Evals cover the agent’s judgement. Did it pick the right tool, did it fill the form the way the user meant, did it stop when it should have asked. You can’t hard-code those outcomes, which is why the guides send you to evaluation-driven development.

Underneath that sits a layer that is deterministic and dull. Once your page calls registerTool, it advertises callable functions with typed schemas to whatever agent is driving. That’s an API. Get an enum wrong and an agent walks a path your buttons never allow, and the eval that catches it will report that the model got confused. Your UI tests will never see it.

I measured what Chrome 152 does when an agent calls these methods.

Instrument Before You Know the Question

Dave Farley tells a story about an organisation that took months to ship a release. Staged, layered, careful. While someone walked him through the process, he asked what happens when production breaks and a fix has to go out now.

“Oh, we can do a type seven release in under an hour.”

So why not run every release as a type seven?

“We couldn’t possibly do that. The risk is too high.”

Type seven was their name for skipping every check the normal process existed to run, shipping the diff, and hoping. That organisation kept two paths to production: one so slow nobody could learn from it, and one so dangerous they saved it for emergencies.

Your observability has a type seven too.

You know the shape of it. Production is misbehaving, your dashboards answer none of the questions you have, so someone adds a log line and ships it. Waits for the deploy. Reads the output. Adds another log line. Or flips debug logging on across a service for twenty minutes and flips it off before the bill arrives. Or attaches a debugger to a live process and holds their breath.

Nobody files that under “the normal process failed”. It goes under incident response, where uncomfortable things go to be forgiven.

The talk this story comes from is worth watching in full:

Organisations that get this right never need a type seven. Releasing is already cheap and fast enough that even a real emergency uses the normal path, with the safety still in it. Fast and safe stop being a trade-off. Two paths exist when you plan your way through a system that only yields to learning.