You record a four-minute Loom to flag three issues on a staging site. The developer who receives it has to watch the whole thing, scrub back to the moment you pointed at the broken filter, screenshot their own screen because you did not attach one, and retype your spoken sentence into a ticket. The feedback took you four minutes to make and costs them fifteen to process. Multiply by a team and a week and you have a real problem.
Video is the right format for some things: a product demo, a personal message to a client, a walkthrough where the motion itself is the point. Most feedback is not that. Most feedback is a handful of specific observations tied to specific screens, and video is a clumsy container for it.
Why a recording costs the receiver more than it costs you
When you record, you are producing linear time. When the receiver consumes it, they have to play it back in linear time too, or skim and risk missing context. The asymmetry is the whole problem. You spent four minutes; they cannot spend less than four minutes unless they gamble.
A recording also buries the artifacts a fix needs. The exact URL is somewhere in the address bar at 0:42. The console error flashed at 2:15. The element you meant is the second card, not the third, but on playback at 1.5x it is hard to tell. None of this is searchable. None of it can be pasted into a ticket. The receiver becomes a transcriptionist before they can become a fixer.
Then there is the receiver who is not a person at all. If any part of the work flows through an AI coding agent, a video is opaque to it. Agents read text. A two-minute MP4 is a wall, and tools like the reasons Loom breaks down with agents are worth understanding even if you never plan to use one, because the same reasoning applies to junior teammates skimming on a phone.
The three cases where video genuinely is the right call
Keep recording when the motion is the message. A janky scroll behavior, a transition that feels wrong, an animation that stutters: you cannot describe those in a still. Record when you are doing a personal sales or client message and the human voice and face are the value. Record when you are training someone on a long, branching workflow and they will pause and replay sections deliberately.
For everything else, ask one question: does the receiver need to see this in motion, or do they need to know what is on a specific screen and what is wrong with it? If it is the second, a still with a comment beats a video every time.
What to send instead of a four-minute video
Send a review made of stills and comments. Each issue is one screenshot, one numbered pin on the spot you mean, and one sentence (typed or dictated) about what is wrong. The receiver opens a link, sees a list, fixes things, and marks each comment resolved. No scrubbing.
This is exactly what Cobalt Capture does as a browser-based alternative to Loom for feedback. You open a tab at the start-a-review page, share a window, crop the frame, and talk or type through what you see. There is no install, no extension, no signup. When you publish, the review gets a public URL anyone can read. It also exists as a PDF, a Word doc, and clean markdown at the same URL with /markdown on the end, which is what makes it work for both human receivers and handing work to a coding agent.
The result is that the four-minute recording becomes a six-item list. Each item is independently addressable. The developer can fix item three without watching items one and two. A QA lead can mark items resolved as they verify. A client can comment on item four without leaving voicemail. The asymmetry inverts: you spend a little more time per issue separating them, the receiver spends much less time per issue acting on them.
A short rule for when to record and when to capture
If you are about to hit record, stop and answer two questions. First, how many distinct issues am I reporting? If it is more than one, stills with comments will serve the receiver better, because each issue becomes its own item. Second, does any single issue require seeing motion to understand? If no, record nothing.
The cases that fail both tests are the obvious ones for capture: QA bug reports, staging site reviews, client feedback rounds, design reviews, accessibility passes. All of these are lists of discrete observations tied to specific screens. None of them benefit from being trapped inside a timeline.
One more thing worth saying plainly: stills are not a downgrade. A screenshot with a pin and a sentence is more precise than a finger pointing at a moving screen while you narrate. The video felt richer because it felt like a conversation. The receiver did not want a conversation. They wanted a list.
Next time you reach for the record button on three bugs, open a tab instead and send the link. The person on the other end will get more done and so will you.