Last week I wrote that cheap waste at scale is one of the most expensive habits a company can develop. A few of you wrote back with the same question, “Agree, but how do I actually find where its happening?”

Fair. It is easy to say "watch the over-producers." It is harder to walk into a team, look at what they are cranking out, and say this part is worth it and that part is not. So this week I want to share how I think about it. But before that, there is a bigger shift underneath all of this that changes where the real work actually happens.

For years the waste in most organizations was wasted effort. Someone spent a week building a report nobody read. That was expensive because the week was expensive. The report itself was almost beside the point. (Visibility Theater sound familiar?)

AI has flipped that. The effort is cheap now. What is expensive is the volume, and it is starting to show up in real practical numbers. Researchers at Stanford's Social Media Lab and BetterUp Labs put a name on it: workslop. AI-generated work that looks polished but does not actually move the task forward. In their survey of 1,150 full-time workers, 41% said they had received workslop in the past month. Each instance took nearly two hours to sort out. Scale that across a 10,000-person company and it runs to more than $9 million a year in lost time, per their estimate.

That is the new type of waste and its not effort spent. It’s volume produced, then ultimately pushed downstream for someone else to untangle. And it is not confined to businesses. A top academic journal recently measured AI slop flooding its submissions. Same pattern everywhere: production got cheap, so people are producing more, and we stopped asking whether each thing needed to exist.

I called this Visibility Theater's louder cousin last week, and I stand by it. The old Visibility Theater was insight nobody acted on. The new version lets you generate ten times the work (report, graph, etc.) at a fraction of the cost and call the volume a win. It is not a win. It is faster waste with a usage meter running.

For most of the history of knowledge work, producing was the bottleneck. Building the financial model, writing the report, cutting the analysis, shipping the feature. It cost time and people, and that cost did useful work you never saw. It killed bad ideas. When building something was expensive, a weak idea died in the backlog because you could not afford to build it. The cost of production was also a filter.

AI removed the filter. You can now afford to build almost anything, so almost nothing dies on cost alone. The bottleneck moved. It is no longer "can we produce this." It is "should we, and is this the thing worth producing over everything else we could make instead." The scarce resource stopped being execution and became judgment. Plenty of people are landing on the same read: the real constraint in enterprise AI is judgment, not capacity. When execution is abundant, knowing what to execute is the job.

This is why planning matters more now, not less. The instinct is backwards. Teams see cheap production and think planning is overhead they can skip, because they can just make the thing and see. But when you could only build three things a quarter, a loose plan was survivable. The scarcity did the prioritizing for you. Now that you can build thirty, a loose plan means you build all thirty, and twenty-five of them are workslop with your company logo on it. The cheaper production gets, the more the plan is the only thing standing between you and a pile of expensive nothing.

So the FinOps move that matters most here is not catching waste after the fact. It is deciding what deserves to be produced before anyone spins it up. Take the time earlier. That is where the money is now.

Same four questions I ended on last week. What makes them useful is that they work at both moments: before you build, as a plan, and after, as an audit.

What decision does this change? Not what does it inform. What decision moves because this exists. If someone reads it and then does exactly what they were going to do anyway, it changed no decision. A good answer is specific. For example, "the pricing team uses this to decide which accounts to call." An empty answer is "it gives us visibility" or "it's good to have."

What outcome does it move? Decisions are upstream of outcomes, so this is the harder check. Does anything measurable move because of this output. Revenue, cost, churn, cycle time, an SLA. A good answer names the number. An empty answer waves at "alignment" or "awareness."

Who actually uses it? Not who is on the distribution list. Who opens it, reads it, and acts. If you cannot name a person, you have your answer. The most common finding in any review like this is the report with forty recipients and two readers, and the two readers only skim it.

What would stop happening if it did not exist? Before you build, this is the honest test of whether you need it. After you build, it is the tiebreaker on whether to keep it. If the answer is "nothing," you have found waste, or you are about to make some.

Ask these before you produce and they are a plan. This will help kill the weak idea while it is still free to kill. Ask these questions about what already exists and it becomes an audit. Same four questions, two moments, and the earlier moment is cheaper every time.

You cannot plan your way out of what you have already built. So you also need the backward-looking pass. Here is how I would run it since I have used variations of this process when managing large scale projects

Here is where a blunt version of this goes wrong, and I want to call it out before someone runs the audit like a chainsaw.

Not every low-scoring output is waste. Some of it is early exploration. A team trying a new analysis for the first time will not have a clean answer to "what decision does this change," because they are still finding out. That is fine. That is what experimentation looks like, and cheap production is genuinely good for it. The upside of more work, not less, is that you can try things that were never worth trying before.

So the "watch" bucket needs a rule: experiments get a runway and a deadline. You are allowed to produce something speculative for a defined window. What you are not allowed to do is let it quietly become a permanent standing report, tool, analyses nobody ever re-evaluated. An experiment is output you are actively deciding about. Waste is output that runs because it always has, and no one remembers turning it on.

AI did not create waste. It removed the cost that used to filter it out. Producing was the hard part, and now it is the easy part, which means the hard part moved upstream to deciding what is worth producing at all.

That is the real FinOps shift here. The old job was making the work cheaper. The new job starts one step earlier: making sure the work should exist before a dollar or a token goes into it. Plan first, with the four questions as the filter. Audit second, with the same four questions as the net. Give the experiments a runway.

Cheap to make was never a reason to make it. Decide what is worth producing. Producing was never the hard part.

Written with the help of AI. All the ideas expressed are mine and mine alone.

If you would like your company included in the Spotlight, contact the CloudXray AI Team

Company: CloudXray AI

Category: Managed Services & Consulting

What They Do: FinOps Consulting & Advisory Services; Owners & maintainers of the single largest FinOps company directory (finops.cloudxray.ai)

Why It Matters: Companies still need guidance on implementing FinOps and understanding the landscape of companies that exist