The licences are bought. The results are uneven.
You did the sensible thing. You gave your developers Claude Code, Cursor or Copilot, and you told them to try it. Some of them took to it. One person ships twice as much as before. Another tried it for a week, got a confident wrong answer, and went back to typing everything by hand. A third uses it for autocomplete and nothing else.
None of that is a failure of your people. They’re good engineers with real work to deliver, and nobody gave them time to work out a method. Coding agents reward a specific set of habits: how you describe a task, how much you hand over at once, how you check the result, when you stop and do it yourself. Those habits aren’t obvious, and they aren’t in the vendor’s onboarding video.
Your team already has the hard part. They know the codebase, the business rules and the reasons behind the odd corners. That knowledge is exactly what makes an agent useful, once they have a way to feed it in.
What I do inside the team
I join for roughly three to six months, part time, and work on your actual backlog alongside your developers. The habits get built on the work you were going to do anyway.
What we build together:
- Shared agent instructions. A file in the repo (CLAUDE.md, AGENTS.md, Cursor rules, or all three) that tells any agent how your project works: the conventions, the commands, the traps, the parts not to touch. Written once, improved every week, used by everyone.
- Scoping tasks for agents. The single biggest difference between good and bad results. A task an agent can finish well is small, has a clear definition of done and a way to check it. We practise breaking real tickets down that way.
- Running parallel sessions without collisions. Several agents at once saves time, and invites collisions. Separate worktrees or branches, clear ownership of files, and a habit of committing often.
- Reviewing AI output. Reading a diff you didn’t write takes a different kind of attention. What to look for first, which kinds of mistakes agents make most, and when to throw a result away and rephrase rather than patch it.
- Tests as the safety net. Agents are far more reliable when a test suite tells them, and you, whether a change worked. Where coverage is thin, we add it around the code people change most.
- Knowing when to say no. Some work is faster by hand. Some code is too sensitive to hand over. A team that knows where those lines are trusts the tool more, not less.
I share everything, and I plan to leave
This only works if nothing stays in my head. Every prompt pattern, every instruction file, every review checklist goes into your repo where the team can read and change it. I’m not building a dependency. The goal from the first week is that the team doesn’t need me by the end.
Concretely, the team keeps:
- An overview of how the team works with agents, written for the next person you hire.
- Runbooks for the common jobs: starting a parallel session, onboarding a new developer to the tools, cleaning up after a session that went wrong.
- Decision notes on what you chose and why: which tools, which kinds of work stay human, what you tried and dropped.
- Numbers: what we measured at the start and at the end, such as cycle time or review turnaround, so you can see whether it helped.
- The agent instructions themselves, versioned in the repo, so any future developer or freelancer gets good help from day one.
You own all of it.
Why me
I spent seven years as a senior engineer on a multi-tenant B2B SaaS that grew from about $4M to $13M in annual revenue, including running its roughly 1TB Postgres database. I now build and run a live product on my own, working with coding agents on code that real customers depend on. I write about the engineering underneath on my writing page.
Take a business like this one
The business in this section is a composite of the kind of company I talk to, not a named client. The numbers are the shape of the problem, not a case study.
Picture a logistics software company with nine developers on a ten-year-old codebase. Everyone has a Cursor licence and a Claude Code seat. Two developers use them heavily and swear by them. The rest are sceptical, partly because one agent-written change took down invoicing for an hour last quarter. Pull requests now arrive in two styles, and reviewers can tell which ones an agent wrote because they’re three times longer.
What I’d do for a team shaped like this:
- First two weeks: watch and measure. Pair with each developer on a ticket they already have. Note where the agent helps, where it wastes time, and where it does damage. Record a few baseline numbers.
- Write the first agent instructions file with the two enthusiasts and one sceptic, so it reflects how the whole team actually works.
- Add tests around invoicing and the other code that breaks most often, so agents and people both have a safety net there.
- Agree a review standard for agent-written changes: smaller pull requests, a short note on what was asked and what was checked.
- Introduce parallel sessions to the developers who are ready, with a simple branch and ownership convention.
- Hand over and step back. In the last month the team runs everything and I only answer questions. Then the written playbook, the numbers and the instructions stay with them.
The developers keep doing what they’re best at: understanding the logistics business and deciding what the software should do.
What it costs
It starts with a small fixed-price first piece: two weeks of pairing and a written assessment of where the team stands, what’s working, and what I’d change. The engagement after that is scoped from what we learn, with a clear end date. No open-ended retainer, and no per-seat fees on top of the tools you already pay for.
What I need from you
Access to the repo and your normal tools, a seat in the team’s chat, and a few hours a week of each developer’s time on work they’d be doing anyway. One person on your side who decides when we disagree about how the team should work. And honest feedback from the sceptics, because they usually spot the real problems first.