Everything about our dev workflow at Trade Nation was manual when I joined, and AI meant autocomplete. We opened changes by hand, copied ticket details across by hand and chased reviews by hand. There was no agent tooling and no shared standard for how to use it.
Nobody wrote an AI policy first. Our rule from day one was find a problem, solve it, repeat, and a platform grew out of the fixes. Our answers won't suit every team, but I think anyone driving this kind of change will hit the same problems in roughly the same order.
Starting with the boring stuff
The first problem was that the agents knew nothing about our code. An agent without that context is a very confident junior on their first day. So we started with CLAUDE.md files, READMEs and written conventions that explain how our projects work. Nothing visible came out of that stage, and everything after it is built on top of it.
Then we took the manual chores one at a time. We started packaging all the repetitive stuff into skills — branch names, task templates, workflows, and the little things developers do over and over again. Once it’s standardized, we don’t have to keep doing it manually.
For docs, we took the same approach. Instead of searching through API documentation every time, we connected MCPs like Context7 and let the tools pull in what we need. These are just a few simple examples. But it gets much more interesting when we move on to more complex workflows and use cases.
There was no roadmap, just a queue of things people hated doing. That's also why the team picked it up without being pushed. Every addition took away a job someone already disliked.
Context, skills and rules
The next wall was context, which is the working memory an agent has for a task. When one agent does everything, that memory fills up, every step gets more expensive and the agent starts forgetting things. So our main agent stopped doing the work itself. It became an orchestrator that hands exploration and coding to short-lived helper agents, each starting fresh, and gets a brief summary back. It's like a CEO who sends a specialist to investigate and judges the direction from the report, without holding every detail in their head. The helpers are cheap to throw away, and the orchestrator's context stays lean.
Independent tasks run in parallel, each in its own separate copy of the codebase, so one working folder isn't the bottleneck. More agents isn't automatically better, though. Anthropic found that multi-agent systems use about 15 times more tokens than chats, and our usage runs on real subscription budgets. So small tasks stay with a single agent, and the full multi-agent process is saved for work risky enough to justify the spend.
We also kept explaining the same things over and over, like how we open changes, name branches and write commit messages. We bundled those into skills, which are reusable playbooks the agent picks up when a task calls for one. Ask it to create a change and the branching rules, commit format and change template come along with it.
That's fine for playbooks and too loose for coding standards. Claude only loads a skill's full instructions when it thinks the skill is relevant, so a skill can get skipped. Standards that have to hold every time went into rules instead. Some load in every session, and others load whenever the agent touches a matching kind of file, with no judgment call involved. Deciding which bucket each standard belongs in turned out to be one of the most important design calls in the whole setup.
Review and the rest of the team
Then came review. The agent that writes a change never reviews it, for the same reason people don't approve their own pull requests. Tests are agreed before any code exists. Once an agent has written the code, browser tests, a run that tries to break the change and a reviewer that never saw the original conversation all go at the same time. That reviewer checks the code is correct and that it does what the ticket asked. Automated checks come next, then a check that the docs and comments still match the code, then a senior-level review of the big picture. A developer still has to explicitly approve the change before it's pushed or announced to the team, and a person does the actual merge.
The last wall was everyone else. What worked for us didn't carry over, because other developers work in different frameworks, languages and projects. So we packaged the setup as Claude Code plugins, a core bundle for how we work plus a bundle for each area of work, each with its own skills and setup. Adopting an area means installing its bundle, and contributing means opening a pull request to it. Getting a new developer into the AI workflow used to depend on tribal knowledge, and now it's an install step. Developers and QA use it every day now, and it's the part I'm most excited about, because it turns one power user's setup into something the whole team can build on.