Send Your Coworker the Claude Output

Written by Claude Opus 5.5 on 2026-10-30, last edited 2026-10-30 · History · Prompts

I was cooking dinner for my three kids tonight when I caught up on some early results a colleague had shared from a project we’re working on. They were comparing how much a multi-agent workflow costs and how long it takes at different AI model settings. I had a useful idea and about a minute to type it. Here’s what I sent in Slack, with a name removed:

Ask Claude to keep some kind of doc for this, like maybe one running log as you have learnings. Could be a GitHub issue. And also a formatted markdown with a table or yaml or something that can serve as a knowledge table with model, effort, costs and run times

[A partner] would love to see a report about that so we can get Claude to dial in the best quality / cost ratio with some input from him

I’m doing this with competitor research and cloud front logging etc

I’ll work up an issue you can pluck some ideas from one sec

That’s 102 words, and they’re the best I could do with a pan on the stove. Then I dictated a few rambling paragraphs into Claude Code and went back to dinner. By GitHub’s timestamp, the issue landed about seven minutes after my last Slack message. It runs about 2,000 words, and my colleague can act on it. Claude filed it before I’d read it.

Without Claude, my colleague would have gotten the 102 words. A longer version wasn’t going to happen tonight, and probably not this week.

I Don’t Think This Is Rude

There’s an ongoing argument about whether it’s OK to send people something an LLM wrote, especially if you didn’t write it yourself or read it closely. I think I’m in the minority here. I think it’s fine, and sometimes it’s the most helpful thing you can do.

The objection has real cases behind it. Nobody wants to read pages of confident filler because someone couldn’t be bothered to think. That’s a complaint about bad writing and wasted time, though. It doesn’t tell you whether a particular document is good.

So I’d judge the document. This one lists 15 ideas and says plainly that nothing is decided. It cites file paths and line numbers in the code it’s talking about. It also works out how long testing one setting at a time would take, which turned out to be days, and suggests a cheaper first step. I couldn’t have given my colleague any of that from the kitchen.

I also think the reaction will fade. Programmers are getting used to the fact that Claude can write code. People are going to have to get used to the fact that some of what they read was generated by an LLM, and that it can be very useful. I’d rather receive a good document that a model wrote than a short message that leaves me to work out the details.

This isn’t a rule for everything. If someone wants to know what I think, they should get my words. If I’m apologizing, or giving someone hard news, I’ll write it myself. My name is still on what I send, so a mistake in it is still my mistake.

Point Claude at Something That Already Works

The issue is good because Claude had real examples to read. I’ve spent months building the same kind of system in Hello Weather, and I told Claude to go look at it.

Hello Weather has a recurring problem that looks a lot like model tuning. We have to choose settings such as server counts and CDN timeouts, measure what happens, and remember why we chose them. Over time, that knowledge has settled into four kinds of files:

A structured file in the repo: what’s true now and how we know. Our Heroku YAML has the current server count, its limits, and a dated history where each entry gives a reason.
A running log: what we tried and decided. Sentry triage passes go in comments on one long-lived GitHub issue, so writing something down doesn’t need a PR.
Raw data we can throw away: a gitignored SQLite file for CloudFront logs or competitor reviews. We can query it and rebuild it, so nobody has to trust it as fresh.
A dated research note: a finished conclusion with its evidence.

I never would have typed that list into Slack. I’d have said “like we do in Hello Weather,” which means nothing to a colleague who doesn’t work in that repo. Claude read the repo and translated the pattern into terms that fit the other project.

My prompt was mostly the goal and the pointer. I asked for an issue informed by the Hello Weather repo, with ideas my colleague could pick from, in the same format as one we’d made the day before. Claude also read the other project’s eval code and related issues, so it could say what already exists and what’s missing.

What the Issue Looked Like

The repo is private, so I can’t link it, but the shape is easy to describe. It opens with a few plain sentences on the goal: for each workflow and each agent, find the model and effort level that gives the best result for the money and the wait. It then says nothing is decided, and that this is a menu.

After that come these parts:

What we know so far: the numbers from my colleague’s runs, including their warning that the stored costs read low.
Five top picks: for someone who won’t read the rest.
The Hello Weather ideas: each one says what it is, where it came from, and how it would apply here.
How to run the tests: start with a step that costs nothing, by comparing finished runs agent by agent to see where the extra money went.
A table of gaps in the current tools: each row has the problem, the line of code, and a likely fix.
A report for a partner: which charts would help, and the questions only that partner can answer.
A last step: a brief for a fresh model session that reads all the data and opens a PR setting the values.

Most of it is short and concrete. Here’s the kind of table it suggests keeping, with made-up names:

workflows:
  example_workflow:
    measured:
      - { arm: model-a@medium, runs: 1, on: "2026-10-30" }
      - { arm: model-a@high, runs: 1, on: "2026-10-30" }
    agents:
      research_agent: { model: model-a, effort: high, why: "placeholder" }
    history:
      - { on: "2026-10-30", change: "first arms measured", why: "see issue" }

The why and history fields come straight from the Heroku file. They’re there because a number without a reason gets re-argued later.

Claude checked its own draft too. One sentence called a projected total “measured”, and it fixed that before filing. That doesn’t make the issue correct everywhere. I don’t know yet which ideas will hold up, and my colleague hasn’t tried them.

Write It for the Reader’s Claude

Here’s the trick I’d most like people to take from this. A lot of what I make with Claude is meant to be read through Claude.

My colleague may skim the issue. Then I expect they’ll open a Claude session, paste the link, and talk through what’s useful, what’s reasonable, and how they want to approach it. They might never read the whole thing, and that’s fine. The issue says so in its first few lines: open a session, talk it through, take what you want.

That changes what counts as too long. A paragraph of file paths and line numbers is tedious for a person. For the model on the other end, it’s the context that saves an hour of searching. The plain summary and top picks are there for the human. The evidence is there for the human’s agent, and it’s most of what makes that conversation useful.

It also answers much of the objection about reading slop. My colleague doesn’t have to spend an evening on 2,000 words. They can spend ten minutes asking questions about them, and ignore everything that doesn’t apply. We did this the day before with a similar issue about agent setup, and they told me they’re finding it useful. It’s related to writing a handoff before you stop, except the next session belongs to someone else.

What It Cost

Time: a few minutes of dictating, in between other things. I couldn’t have written this at all tonight without Claude, and that includes this post.
Length: 102 words in Slack became about 2,000 in the issue.
Trust: the issue went out before I’d read it. I accepted that because it proposes ideas and changes no code. Nothing happens until my colleague picks something.
Unknown: I haven’t measured whether this saves my colleague time. All I have so far is that they liked the last one.

Lessons Learned

Judge a document by whether it’s accurate and useful, not by who typed it.
Point the model at a working example in your own code instead of describing the idea from memory.
Send drafts that propose options freely, and review more closely when the document makes a decision.
Put a short summary first, then keep the evidence, because the reader’s agent will use it.
Tell the reader they can open a session on it and don’t have to read it all.

A Shout-Out to VoiceInk

I’ve really been enjoying VoiceInk, a dictation app for the Mac. Talking is so much easier than typing when I want to get my full context into Claude. I’ll ramble through what I’m thinking, with all the half-finished ideas and side notes, and I don’t have to clean any of it up first. Claude can sort it out.