Let the work speak: work that explains itself
By Soumen Sarkar · October 2026
Our work explains itself, so nobody ever has to come and ask us.
What does "let the work speak" mean?
Let the work speak means every piece of work carries its own explanation: what it's for, what was decided, what was assumed, and what's left. When the next person or agent picks it up, they don't have to find you and ask. The work has already told them.
Put another way, work isn't done when the code runs. It's done when someone else can carry it on without you.
Why does it matter at agent pace?
Because nobody can keep up by asking. When a team ships dozens of changes a day, a reviewer might face twenty agent-made pull requests in an afternoon. Messaging the author of each one isn't possible, and often the author is a session that has already ended. The person who directed it is three sessions deep in something else.
If the reasoning lived only in that session, it's gone. The reviewer reconstructs intent from the diff. The next agent repeats an approach that was already tried and dropped. Someone in another time zone waits a night for an answer that was clear to its author at the time.
The same is true inside one person's day. You might direct four sessions at once, and come back to one of them after lunch with no memory of why it chose what it chose. Work that explains itself helps its own author as much as anyone.
So explaining is part of finishing, not something added later. And at this volume, it has to cost almost nothing, or it won't happen.
What does it look like in a working day?
Here's a scenario. Marco is moving his team's search to a new index format, in the area they call "Search · lib/search". It's six in the evening for him and the work is half done. Aiko, a few time zones east, starts her day in two hours.
When Marco's session stops, it leaves a handoff behind:
Done: new index format written; products backfilled and checked.
Left: articles and help pages still on the old index.
Next step: run the backfill for articles (the script takes a content type).
Open question: keep the old index for a week as a fallback? Assumed yes.
Trap: the backfill fails without an error above 500 items a batch. Use 200.
Aiko never messages Marco. She sees the handoff waiting, picks it up, and her agent starts from the next step instead of from the beginning. It reads the trap before running anything, so the silent failure never happens. The open question is still visible, so whoever knows the answer can correct it without a meeting.
Meanwhile the products half went out as a pull request before Marco stopped. Sam reviews it the next morning. Alongside the diff are the change's reasons: what it's for, the calls made (keep the old index for a week as a fallback), what was assumed, and what was tried and dropped (migrating in place, dropped because it locked writes for minutes). Sam reviews against the intent instead of guessing it, and asks nothing.
At the end of Marco's day, the team also gets a few lines in plain words: search is moving to a new format, products are done, articles are next. Nobody wrote it. It came from the work.
What do people do?
You finish your work by making it explain itself. That rarely means writing a document. It means saying, at the moment you make a call, why you made it, in one sentence. It means noticing the trap you nearly fell into and leaving a line about it. It means stopping in a state someone else can start from.
And you read before you ask. When you pick up someone else's work, the handoff and the reasons come first. Often everything you needed is already there.
What do agents do?
An agent leaves its reasons and its handoff with the work, every time it stops. That includes stopping unfinished, which is when it matters most. A good handoff says what's done, what's left, the next step, what's still open, and what to watch out for. The handoff template has that shape.
When an agent commits, it says what the change is for and the calls it made, so a reviewer can read the intent before the diff. The change reasons template has a version teams can copy into their instructions. And as it finishes each chunk of work, it logs it in plain words, outcome first, so the people around it can follow without reading code.
Doesn't this mean more writing?
If it meant writing reports, it wouldn't last a week. That's the honest objection, and the answer is that the explanation should come from the work itself, captured as it happens, not composed afterwards. A sentence of reason when the call is made. A handoff produced when the session stops. Nothing that asks people to remember.
There are limits, too:
- An explanation doesn't excuse unclear work. Clear names, small changes and good tests still matter. Reasons tell you why; the code still has to say what.
- A handoff is only as good as what the session noticed. A trap nobody hit won't be in it. Read it with judgement, and add what you learn.
- This isn't a rule against talking. If two people need to work through a design together, they should. The point is that nobody should have to come and ask what you did.
How does Campfyrr make it hold?
In Claude Code, Campfyrr's hooks do the explaining nobody has time for. When a session stops, compacts or ends, a handoff is written from the session: what's done, what's unfinished, the next step, open questions and traps. The transcript itself isn't kept. On a commit or pull request, the change's reasons are written for the reviewer, with a link to put in the pull request description.
Handoffs show up in the project's Activity feed as work paused partway, with the next step, and each person's next session opens with "Pick up where it was left" at the top: their own unfinished work and handoffs to them. To take over a teammate's, you paste it into your first prompt. Each week, Activity shows how many handoffs were picked up, and how fast.
Agents log their work in plain words as they go, and at each person's end of day those logs become a short daily update. Codex, Cursor and other connected agents call the same tools, hand_off, change_story and log_work, following the instructions the server gives them; they don't get the automatic hooks.
What changes when a team works this way?
Nobody becomes the only person who understands their own work. Pick-up time shrinks, because the next person starts from the next step instead of from a question. Reviews move faster, because the reviewer reads intent before code. And trust grows, because the work keeps its promises out loud.
Let the work speak is how a team takes care of each other at agent pace. You never have to stop to explain your work. It already explains itself.
Questions this answers
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).