Developer tools for normal teams

Every team that uses AI seriously runs into the same wall. It isn’t the price of tokens. It’s that once several agents are doing real work, nobody can say for certain what they did or whether it was right.

Software teams have had that problem for decades, with people instead of agents, and they solved it with a handful of tools. I think those tools are about to leave engineering. This is the argument I made at the Canggu AI Meetup tonight; the slides are at the end.

The wall is trust, not tokens

Starting an agent is easy. Anyone can point one at an inbox or a spreadsheet in an afternoon.

The hard part comes afterwards. An agent rarely fails loudly. It summarises a little less carefully, skips a field in the CRM, drafts a proposal that is nearly right. If nothing checks the work and nothing records it, you find out weeks later, from a customer.

So the question worth asking isn’t “which agent?” It’s “how would I know?”

How a small team runs millions of lines

The codebase I work in every day is a little over five million lines, spread across 84 apps and services. A small team maintains it. Nobody reads it all, and nobody needs to.

It works because the agents that do much of the work operate inside a few rules we wrote down, and because nothing they produce lands without being checked. There are 253 written playbooks (we call them skills) and 48 specialised agents for planning, coding, reviewing and shipping. None of that is exotic. It’s mostly the standard toolkit of any well-run engineering team, applied to agents instead of people.

Four tools, in plainer clothes

Each of these exists in software because many hands working in one system break things in ways nobody notices until later. Agents are many hands.

• Checks the agent can run itself. Developers have tests: code that fails when something breaks. For everyone else it’s a checklist, a sample to compare against, or a number that has to move. An agent that can check its own work improves without you. One that can’t makes you the test.
• A record of everything. Developers have version history: every change, who made it, and a way back. For everyone else it’s Linear, Drive or Notion, as long as the agent writes where people already read.
• Know-how written down once. Developers have runbooks. For agents, the same idea is a skill: a short instruction loaded when the task needs it. The useful ones come from watching an agent fail at the same thing twice.
• Gates sized to the mistake. Developers have code review. For everyone else it’s approval: light for a draft email, heavier for a payment or a contract.

None of these need a developer. They need the habits developers have.

Keeping track is the one to start with

If I had to pick one, it’s the record. Every agent, whatever it does, writes to the same place: what it did, and whether its check passed.

That’s also how you catch the quiet failure. A shared log turns “the agent seems fine” into something you can see. If it isn’t tracked, it didn’t happen, and if it didn’t happen you can’t tell whether it went wrong.

The steps are about guardrails, not tokens

Boris Cherny, who built Claude Code, describes five steps of AI adoption: gated, then assisted (about one agent per person), parallel (about ten), supervised autonomy (about a hundred), and AI-native (a thousand or more). His point, which matches what I’ve seen, is that tokens alone don’t move a team up a step. Removing the next bottleneck and building the next guardrail does.

The four tools above are those guardrails. Most teams outside engineering are on the first or second step, and the jump to the third is where they start to matter: at ten agents per person, nobody can supervise every output by eye.

One install for the whole team

Habits spread badly by memo. What worked for us was packaging them. The team gets one plugin for Claude Cowork, installed once, with no terminal involved. It holds the skills, the connections to our own systems and the checks:

• Skills. For example, an inbox assistant that learns your tone from your sent mail and drafts replies on a schedule, or one that produces year-end investor statements.
• Connectors. Links to the company’s docs, CRM and data, so a question in plain words gets an answer from the real source.
• Checks. For example, a fact-checker that re-derives every claim in a draft before it goes out.

The plugin is built from what we actually run, so when someone adds a skill or a connection, everyone has it on the next update. Nobody maintains a list, which is the only reason the list stays true.

Can normal teams run this?

The meetup asked. Yes, with the tools, and none of them require writing code. Package the habits once and everyone installs them. Agents break things quietly only when there’s no check and no record; with both, a problem shows up in the log the same day.

The slides

Open questions

• How small can the record be before it stops being useful? A spreadsheet works for one team; I don’t know where it stops working.
• Who writes the skills in a team with no engineers, and who decides when one is wrong?
• Checks are easy for numbers and hard for judgement. What’s the checklist for “is this a good proposal”?