A polished AI-generated document can save its author time while leaving colleagues to check the facts, reconstruct missing context and finish the thinking. In this TechBullion interview, Dimitriy Wolf examines AI workslop: convincing output that appears complete but creates avoidable work for the people who receive it.
Drawing on his experience in communication teaching and pitch mentoring, Wolf explains how businesses can assess AI’s impact on workplace productivity, set clearer standards for sharing work and protect team trust. He discusses how to question unreliable output constructively, why founders must understand the reasoning behind an AI-assisted investor pitch, and what managers should measure beyond the speed of a first draft. He also outlines a practical 30-day approach to reducing unnecessary corrections and helping teams produce work that colleagues can confidently use.
1) What is an AI workslop, and how can someone recognise it in an otherwise polished document?
Researchers from BetterUp Labs and the Stanford Social Media Lab described workslop in 2025. It’s AI-generated work that looks ready to use and leaves the recipient to finish the thinking. Harvard Business Review
A common starting point is a task given to AI in a hurry. The person has a lot of the variables in their head and supplies only a few. The model fills in the gaps, the document looks finished, and somebody else has to find out what the author meant. Even a well-briefed model can misread a source, so the person sharing the document still has to check it.
You can usually see the problem when you try to use the work. You can’t trace a number to its source, the recommendation ignores a constraint everyone on the project knows, or you finish reading and still have to ask what decision you’re supposed to make.
2) Could you walk us through an anonymised example from your practice, or a clearly labelled hypothetical scenario, showing where useful AI assistance ends and extra work for a colleague begins?
I look at what each pass leaves the next person to do. When one pass after another adds work that could have been avoided, AI has stopped saving the team time.
Take a hypothetical example from course design. You ask AI to write the steps a student should follow to develop a proposal. Now you have a list of steps. How will you know the student did the work? How will you tell whether they understood the method and can use it in a different situation?
If the model helps you catch those questions while you’re designing the assignment, it has helped. If you send the assignment off as finished and another instructional designer has to reconstruct the learning goal and build the assessment from scratch, they’ve inherited work you could have done before the handoff.
I’d give the model my own proposal for assessing the skill. For example, the student could explain their choice and defend it after one of the conditions changes. Then I’d ask the model to help improve that exercise. A person who knows the work can anticipate a lot of the questions that otherwise come up one at a time.
3) How can a business tell whether AI is saving time across a team or simply transferring work between people?
In our work, we use AI systems that follow rules we set. We track each project on a card. As work moves from one person to the next, the card shows what’s been resolved and what each person still has to do.
A growing list tells me to look more closely. Did we discover work the project genuinely needed, or did the next person have to do work the previous person could reasonably have finished? If I saved twenty minutes writing something and a colleague spent an extra forty minutes fixing it, we added twenty minutes of work as a team.
To see whether we saved time, I’d compare similar jobs through to acceptance, with the same standard for what counts as finished.
4) What should managers measure beyond the speed of producing a first draft, particularly when checking, clarification and revisions happen elsewhere?
I’d track the number of iterations, the number of handoffs, and what each new pass leaves open. Then I’d look at the time spent by the person who made the draft, the people who checked it, and anyone who had to clarify or fix it before it could be used.
Look at why the work came back, too. A new fact or a question that exposes a real problem can improve the result. If the team keeps going back because the original brief is missing or the same calculation never gets checked, that’s the rework I want to measure. Counting the items alone misses how much effort they take and how much the errors matter.
5) Why do capable professionals sometimes pass on AI-generated work they cannot fully explain or defend?
Working with AI lets you take on a huge volume of work. That can also mean more projects running at once and more material to check. Deep thinking still takes time. When a capable person is short on time and attention, a fluent answer that seems close enough can be very easy to accept.
I’ve sat at conferences and put a question into ChatGPT just as it was asked onstage. I’ve heard answers that matched what was on my screen almost word for word. I had no way of knowing how the speaker had prepared. What I wanted to hear next was what that person knew from their own work that a general answer couldn’t give me.
That’s the part a busy specialist can end up skipping. They know enough to go deeper, and they may have given themselves very little time to do it.
6) From your experience teaching communication, how much comes down to time pressure, unclear expectations or confidence in language that sounds authoritative?
I see all three interacting. Under time pressure, you give the model fewer specifics. If you’re unsure what the result needs to do, a confident answer can look more complete than it is.
Imagine you have a robot that does chores. You send it to the supermarket and say, “Bring me some milk.” It brings back milk. You were picturing a particular fat content, a certain size, a glass bottle, and the latest expiration date on the shelf. You gave it one instruction. The rest of the brief stayed in your head.
The two habits I’d teach are to give the model the details that affect the result and to verify what matters before using the answer. You can ask AI to surface its assumptions or take a second look. An important figure still needs to be checked against the original report or recalculated.
7) What should a useful handover of AI-assisted work contain?
I’d want a short note describing the intended result, the decisions already made, the reasons behind them, and what the next person is being asked to do. Include what’s been checked and what still needs an answer. Even if the robot brought back exactly the milk you asked for, someone taking over the cooking needs to know what you were going to make.
In one setup we use Claude Code and other agents on a server we manage. The workflow asks the person for specific inputs before it accepts the task. Their answers, intentions, and decisions become part of the project documentation. The person taking over adds their own context and records any changes. That way, when two people work on the same project, the original design and the reasons for it are still available to both.
8) Could you demonstrate a concise example that identifies the decision needed, the essential context, what has been verified, any remaining uncertainty and who owns the result?
Here’s a hypothetical note I’d send with a lesson we were preparing to pilot.
“By Friday, we need to decide whether to pilot this lesson with the next group. The point of the assignment is to see whether a student can use the method to develop a proposal in a new situation. The instructional designer and I checked that the assignment and scoring criteria test that skill. We still need to find out whether students can finish it in the time we’ve allowed. I’m responsible for the pilot and will bring back the first group’s results.”
9) What quality standards should leaders establish before AI-assisted work is shared with colleagues or clients?
I’d make three checks before sharing the work. Can the recipient use it without avoidable cleanup? Have we verified the facts and calculations that matter? Does the result fit the job the recipient needs it to do?
With a client, I’d ask early how they plan to use the work and what they’ll consider a satisfactory result. Before delivery, I’d check the work against that conversation. If what we found calls one of the client’s assumptions into question, I’d talk through it with them. That conversation can save both sides a round of work that a perfectly formatted document won’t resolve.
10) How should those expectations change between an early brainstorming draft, an internal recommendation and a document that could influence a significant business decision?
A brainstorming draft can explore dozens of possibilities. In our work, we sometimes give several people the same task and let each build their own version with AI. Then we see which ideas can work together. It’s like a construction set where everyone makes a few pieces, and then you find out which ones fit. At that stage, you can leave ideas untested as long as everyone knows they’re hypotheses.
An internal recommendation needs a direction. What are we proposing, what supports the choice, and what results should we expect along the way? I’d define what the finished project should do and when we’ll check its quality.
For a consequential business decision, have a second person with the right expertise verify the claims and calculations that could change it. The person approving it needs to see which assumptions still have to hold for the recommendation to work.
11) How can an employee challenge poor-quality AI output without damaging the working relationship?
The ability to point out a problem is a communication skill. It helps if the team agrees in advance on what counts as an error in that particular project. You might give AI room to generate creative options, then have someone who understands the brief decide which ones fit. If the model produces an analysis people will act on, someone who knows the subject needs to interpret it and check the conclusion.
In the conversation, I’d point to the specific issue, explain why it matters, and ask for the next step. “This comparison assumes the two groups had the same starting conditions. That affects the conclusion. Can we check the data before we use it?” The project standard gives you something both of you can refer to.
12) What language would you recommend when the sender is a colleague, a senior executive or someone whose work repeatedly needs substantial correction?
With a colleague, I’d say, “Can you show me where this number came from? I need to be able to explain it when I take the work forward.”
With a senior executive, I’d tie it to the decision. “Our recommendation to the client depends on this figure. For this kind of decision, we check it against the original report. Can we confirm the source before it goes out?”
When the problem keeps recurring, I’d address the pattern. “The last three handoffs came back for the same kind of correction. Let’s look at where the problem starts and agree on what you’ll check before the next one.” I’d also suggest asking the model after each pass to list what still needs a decision or verification. If the same long list keeps coming back, it’s time to look at how the task is being set up.
13) What happens to team trust when someone repeatedly submits convincing work that does not withstand scrutiny?
People react differently. Some colleagues give the person the benefit of the doubt and quietly help. Others have more faith in what the technology could do and get frustrated when they keep inheriting work they expected it to handle. That can split a team even when everyone agrees that the work needs fixing.
Over time, people start checking who sent a document before they decide how much of it they can rely on. Even good work from that person takes longer to accept. I’d give the whole team a common standard for what they verify before passing work on. People can still experiment freely, and everyone knows what to expect when a colleague says something is ready to use.
14) How can leaders distinguish an individual development need from a wider problem with incentives, workloads or management expectations?
You can assess skill with AI just as you can assess whether someone knows how to work in Word. Give people a comparable task, clear inputs, enough time, and the same standard for a finished result. See whether they can decide when to break the work into stages, give the model the right context, and check what comes back.
I’d also ask what the company has taught them. Has anyone tested which models and ways of briefing them work for the tasks this team actually does? Are the rules clear to the people expected to follow them? If several capable people get stuck at the same point, check the brief, the workload, and what management rewards. If one person consistently struggles under the same conditions, you can identify what they need to practice.
15) When AI prepares the presentation or investor pitch, how can founders demonstrate that they understand the business case behind it?
AI can help with slide design, organize the numbers, suggest a sequence, and give the founder a chance to rehearse. The argument still has to make sense in the founder’s own head, from the wording on the slides to what they say in the room.
Put the deck away and explain who pays, what customers have actually paid for, and which assumptions the forecast depends on. If you’re asking for money, explain what you plan to do with it and what that spending is supposed to prove. A founder who understands the case can explain why the numbers belong in the deck and how the plan changes if an assumption turns out to be wrong.
16) Drawing on your executive communication and pitch mentoring work, what questions or rehearsal techniques reveal whether someone can explain their reasoning, acknowledge uncertainty and respond under pressure?
After we’ve built a deck, I often recommend turning on voice mode and pitching to AI. Ask it to play a skeptical, detail-oriented investor and to keep asking follow-up questions. Founders tend to get stuck on the business model, how they’ll reach the market, and why this should work here and now. “Who pays first?” and “What makes you think you can reach those buyers?” can tell you a lot.
For practice under pressure, work with a person. Have a coach interrupt with a real question, change an assumption about the sales cycle, or ask for the answer in thirty seconds. Practice saying, “I don’t know yet. Here’s how we’ll find out.” You learn a lot by hearing how your own answer changes when the conversation goes somewhere you hadn’t prepared for.
17) What should corporate learning programmes teach beyond how to prompt an AI tool?
A financial analyst is still a financial analyst. A marketer is still a marketer. Ethics, cross-cultural communication, business communication, and the skills people need to do their jobs still matter. AI training should help them apply that expertise.
If you don’t know a market, you can ask a model for a marketing plan and get a convincing one. You’re also going to have a hard time spotting the bad assumptions. Give people practice formulating the problem, checking evidence, interpreting it in their field, and explaining why they chose a particular course of action.
18) Could you share a practical exercise that helps employees evaluate an output, explain a decision in their own words and answer questions without relying on the generated text?
Give the employee a real decision to make, the source material, and two options AI has proposed. Ask them to identify and verify the two claims most likely to affect their choice. They should check them against the sources, using the standards they’d apply on the job. Then they make their own decision.
Have them close the document. Give them a minute to explain what they chose, what they checked, what remains uncertain, and what new evidence would make them change their mind. Have a colleague ask a follow-up question. You’re looking for how they reached their decision and whether they can defend it in their own words.
19) What would a realistic 30-day plan look like for a manager who wants to reduce AI workslop?
I’d pick one recurring process where the team already spends time on corrections.
In week one, explain what workslop looks like in that process. Follow several tasks from the brief through acceptance. Record how long they take and why they come back for changes.
In week two, agree on the inputs every request should contain and what a useful handoff looks like. Ask the model to list what still needs to be done or decided after each pass. Review that list before assigning any work, then record the necessary items on the same project card and give each one an owner.
In week three, use real examples to coach people on setting up tasks and checking the results. See where missing inputs or unclear responsibilities keep causing the same problems.
In week four, compare similar tasks with the first week. Once the rules work in practice, you can automate routine routing or have a system ask for missing information before a task starts.
20) Which changes would you introduce first, and what evidence would show that the team is spending less time correcting work while making better decisions?
I’d start by giving everyone the same standard for what counts as finished and a place to document what still needs checking. That gives the author and the recipient a way to agree that the work is ready.
I’d look at total team time per accepted task, how often work is returned for preventable corrections, and how often significant errors surface after someone has used it. Compare tasks with similar scope and quality requirements. The number of iterations and the work that arises from each one help explain changes in those results. Token counts can help you track usage and estimate what it costs.
After thirty days, you can see whether the team spends less time fixing work and whether important claims are better supported when decisions are made. Some business decisions take longer to play out. Follow their outcomes when the results come in.