AI Workslop: Ask What Recipients Had to Check or Redo

Polished is not the same as useful

AI output can be grammatically clean and structurally convincing while still failing the job it was meant to do. A summary might accurately describe what was said, but miss the assumption that drove the decision. An email can sound professional while burying the actual request. A project update may list what's done while leaving the next step - and who owns it - up in the air.

None of that necessarily means the model "lied." The content can be factually correct and still create friction because it doesn't include the context, evidence, or decision cue the next person needs. Proofreading alone doesn't answer the real question. The question is whether someone can use the output without avoidable repair.

Researchers at BetterUp Labs and Stanford's Social Media Lab used the term workslop for AI-generated work that appears finished but doesn't have the substance to move a task forward. In a 2025 survey of 1,150 US desk workers, 40% said they had received workslop in the previous month. Respondents who had received it estimated that each incident cost them nearly two hours. Half said it made them view the sender as less capable, and 32% said they were less likely to want to work with that person again.

These are survey responses, not a universal meter for every AI workflow. Still, they point to a real risk teams can overlook: the productivity gain you see on one person's screen can show up as verification and repair work on someone else's. The recipient is usually the best person to spot where that transfer is happening.

Ask after the person has used the work

Timing matters. If you ask right after you send the document, the recipient may not know what's missing yet. Ask after they've made the decision, used the update, or passed the information along. Keep it short, and make it clear you want an honest answer - not reassurance.

For example: "Now that you've used the summary, what did you have to check or redo?" If the handoff is routine, you can ask in a brief message or during an existing check-in. The goal is learning from real use, without turning feedback into another ritual that costs more than it returns.

Start with one recurring handoff

Pick one type of work you send regularly. A weekly project update is usually easier to improve than an occasional, high-stakes report, because you get another chance to test changes quickly. Good places to start include research summaries, meeting recaps, customer-support drafts, and internal decision briefs.

Keep the scope narrow. If you ask about every AI use at once, the feedback won't compare cleanly - and it'll be harder to act on. A recurring handoff gives you a stable "unit of work": roughly the same sender, recipient, purpose, and format. That makes it easier to see whether a change actually reduced friction.

If the recipient names multiple issues, don't defend the draft or debate whether it "should have been obvious." Ask for an example if you need it, then write down the first concrete repair they describe. The first answer isn't a verdict on your skills or on AI in general. It's a signal about one part of a workflow you can make more usable.

Map the repair to a change

Translate what the recipient says into a practical adjustment. If they reopened sources to verify claims, put the relevant source beside each important claim. If they searched for the request, move the ask (and the required response) to the first line. If they couldn't tell who owned the next step, state the owner and deadline explicitly.

These are examples, not universal rules. Sometimes a source list doesn't matter for low-risk internal notes, but it matters a lot for customer-facing or financial claims. The right fix depends on the cost of being wrong, the recipient's task, and how often the handoff gets reused.

Change the workflow, not just the wording

Sometimes the problem isn't a sentence that needs editing. The input might be incomplete, the AI tool may not have access to the right sources, or the handoff may have no defined owner. In those cases, a fancier prompt can produce something that looks better without solving the underlying issue.

Work backward from the repair. If recipients keep correcting the same figure, check whether the source data is current and whether the model is allowed to use it. If summaries consistently miss a specific decision, make sure the decision actually gets captured in the notes before asking AI to summarize them. If action items are repeatedly vague, decide who is responsible for confirming ownership before the recap goes out.

The best intervention is the smallest one that eliminates the recurring repair. That might mean a line in a template, a required "source" field, a human review step for sensitive claims, or deciding to stop using AI for that particular handoff. Automation should reduce total effort - not just shuffle work to someone else.

Measure transferred effort, not just generation speed

A workflow can be faster for the sender and slower for the team overall. Where it's practical, compare the time saved on drafting with the time spent reviewing, verifying, clarifying, and correcting. You may not be able to track every minute precisely - and you don't need a perfect number to spot a recurring burden.

A useful quality check is whether the output supports the next action without an avoidable follow-up. In some cases, the recipient should be able to decide, approve, or forward the material directly. In others, they may need to review carefully because the stakes of an error are high. Your standard should match the task, not a blanket claim that AI output should always be ready to use.

Keep risk and accountability in view

Recipient feedback doesn't replace fact-checking, privacy controls, or human accountability. For legal, financial, medical, employment, or other high-impact work, someone with the right authority still needs to verify the output against reliable sources and applicable requirements. If a recipient says they didn't have to redo anything, that's evidence about usability - not proof that every claim is true or safe.

Also, don't turn the question into surveillance or a personal performance score. The purpose is to improve the handoff and the system around it. If people expect blame for naming a problem, they'll start giving reassuring answers. Make it clear that feedback is about reducing friction - and then act visibly on what you hear. A loop that asks for input but never changes anything will lose credibility fast.