Why I treat Claude like a colleague, not a tool

A tool produces output you have to inspect. A colleague produces work you have to review. The difference is who owns the standards.

Treat Claude as a tool and you'll write longer prompts, demand more context per request, and re-read every line of output because you don't trust it yet. Treat Claude as a colleague and you'll spend that time on the brief, the review, the post-mortems on the failures, and the system you build around the work. The work itself stops being the bottleneck.

This is the mental model that changed what I ship.

The colleague model

Three things change when you make the switch.

One, the brief becomes the work. A vague prompt to a tool gets you garbage. A vague brief to a colleague gets you a clarifying question, an attempt that's mostly right, and a polite request for more detail. Claude already behaves this way if you let it. Most people don't let it because they're prompting like they're typing into a search engine.

Two, the review becomes the work. Code from a colleague gets reviewed line by line by you, because you're going to own the bugs. Code from a tool gets glanced at and shipped. The colleague model forces you to actually read what Claude wrote, catch the wrong bits, push back, iterate.

Three, the failure modes become written down. Colleagues have known weak spots. The senior dev who's strong on architecture but hates testing. The PM who's great with clients but loose with deadlines. You learn them and you build process around them. Claude has weak spots too. The colleague model means you write them down, build process around them, and stop being surprised when they show up.

What this looks like in practice

A typical task with Claude as a colleague:

Brief. Two paragraphs minimum. What the goal is, what the constraints are, what good looks like.
First pass. Claude takes a swing. I read it.
Review. Where it's wrong, I push back specifically. Where it's right, I move on.
Iteration. Maybe one or two more passes. I'm not retyping the brief, I'm correcting trajectory.
Ship. When the work meets the bar, it ships. I'm not re-doing it from scratch.

If you compare this to most people's actual workflow ("paste task into Claude, copy output, paste into IDE, fix the bits that broke, ship"), the difference is where the effort goes. The colleague model puts effort into the brief and the review. The tool model puts effort into the fix after the fact.

Why this matters for AI consulting

When I work with clients as a Claude consultant, the biggest leverage is rarely in the prompts. It's in the operating model.

Teams that get value out of Claude have three things:

Briefs that read like briefs to a junior colleague. Not one-line questions.
Reviews that take Claude seriously. Not box-ticking glances.
A library of patterns. When Claude does something well, that pattern gets captured. When it fails, the failure gets logged.

Teams that don't get value out of Claude tend to be teams who hired Claude like a tool, expected it to behave like one, and got tool-quality output.

Three small examples

A. When I write copy with Claude, I give it the voice rules upfront, ask for three variants, then critique each one in detail before asking for a rewrite. The final copy is faster than I'd produce alone and at a higher bar than my first draft.

B. When I'm debugging, I describe the symptom, paste the relevant code, and ask "what would you check first". I don't ask "fix this". The colleague answer is a list of hypotheses to test. The tool answer is a wrong patch.

C. When I'm planning a build, I write the architecture brief, paste it into Claude, ask for "the three things you'd push back on". The colleague answer is genuinely useful. The tool answer is "looks great, ready to build".

What you give up

Speed on trivial tasks. If you treat every Claude exchange like a colleague conversation, you'll over-invest in briefs for things that didn't need them. The pattern works for substantive work. For "summarise this paragraph" or "what's the capital of Belgium", you can just type and copy.

Why the cmd+K agent on this site is a colleague, not a chatbot

That's the same idea applied outwards. The agent in the corner of this site is not "a chatbot that answers questions about Callum". It's an agent that can do four things: show a project, search the writing, get current status, send Callum an email. It has a system prompt that briefs it like a colleague (open with the answer, never use em dashes, never hedge). It has tools instead of canned responses. It refuses gracefully when it doesn't know.

The mental model is the same model I run internally with Claude. The output, if I've built it well, should feel less like a chatbot and more like a brief conversation with someone who actually knows the work.

If you want to see how it behaves, press ⌘K and ask it something. If you want to read the system prompt, it's in .claude/agents/cmdk-router.md, version-controlled with the codebase.

Source: /content/articles/why-i-treat-claude-like-a-colleague.mdx

More writing → /writing. Got a brief? Get in touch.