You open the report. It's long. It has an executive summary, a set of recommendations, a conclusion that circles back to the introduction. You read it, and slowly realise it has told you nothing.
Carl Hendrick, in his post "AI Brain Fry, Workslop and the Ironies," describes this as the thinking being transferred from the producer to the recipient. Over the last year, most knowledge workers have been swamped in reports, emails, and other work content powered by AI.
Last summer, researchers at BetterUp Labs and Stanford gave it a name: work slop. In their study in the Harvard Business Review, they found that 40% of desk workers reported receiving work slop in the last month, taking roughly two hours on average to fix each instance. Work slop is AI-generated work content that masquerades as good work but lacks the substance to meaningfully advance a task.
The problem goes deeper than volume. Cal Newport, in a recent post, quoted statistics showing that the legibility of academic study submissions has decreased just as their volume has increased, precisely overlapping the period of the rollout of AI.
In all of our complaints about poor work, there's a far bigger problem brewing than just being swamped with bad writing. We actually have a growing slop-debt problem.
Engineers named and tamed something similar 30 years ago when they figured out the concept of technical debt, along with related terms like refactoring, interest payments and bankruptcy. And there's a direct parallel here with knowledge work.
Both a code base and a corpus of business knowledge are systems with maintenance costs. Both have readers, even if they're agents down the line, who will pay the price of the shortcuts taken to create those code bases or documents. There is a direct connection between code quality and prose quality.
When we cut corners in our thinking and in our production of written materials, we are building up a debt that has to be paid back in the future. Often it's paid back by the recipient. By the manager who is swamped by so many decisions that they become gridlocked. By the company drives and intranets that become clogged up with poor quality data. Every time those artifacts are looked at again and picked up, there are debt payments that we have to make.
So what does the debt actually cost us? The ‘interest payments’ are paid on every read, by everyone downstream, until someone fixes the source (rewriting the report the way an engineer ‘refactors’ code). Ten people end up losing 15 minutes checking whether a figure is current because they don't trust the source. Or a new hire builds a wrong model from a plausible but wrong page that they found on the internet, and acts on that model for a month.
The concept of bankruptcy also holds up. A knowledge base could reach a point where nobody trusts any of it. People stop reading it and start asking a colleague or regenerating it from scratch each time. You could hit the point where you have to consider the nuclear option. And that is a point where your organization has gone bankrupt on its own memory.
There's also something I'd like to call comprehension debt. AI doesn't write obviously broken code. It writes plausible-looking code. It passes the linter, it passes the unit tests. It looks beautiful at a glance. But because the engineer didn't build the mental model to write it, they don't truly understand its underlying assumptions. The debt isn't tangled code, it's a total vacuum of human understanding. Rewriting slop costs more than a clean draft, because the understanding was never created. You build comprehension from zero while fighting a doc that looks finished.
The analogy with technical debt might reach its limits. Engineers have automated tools, compilers and linters, that flag tech debt and prevent bad code from being deployed. Knowledge work still lacks a compiler for truth and clarity. There is no automated system to flag an error down the line until the damage is already done. Arguably slop debt is more dangerous than tech debt, because we don't have a compiler. Human attention is the key filter.
There's also a difference in motivation. Tech debt can be an organizational strategy. You are racing to meet a tight deadline, you are willing to take a hit on code quality to beat a competitor. But slop debt is more like an organizational virus born from chasing the wrong proxies of hard work.
So what are the stakes for leaders today? Allowing your systems to be gummed up with sloppy work materials is going to cap the automation and the efficiency gains that you can achieve tomorrow. We all have high hopes for the productivity boosts that we expect AI to bring us. But in this world, just as before, garbage in, garbage out still holds. Pairing agents with individual contributors only works if the agents read from an accurate corpus of information. Point an agent at slop and it produces slop faster and more confidently.
What we have seen is that AI changes the role of an engineer from a writer of code to an editor and a system architect. The teams keeping technical debt down aren't the ones typing the fastest. They are the ones enforcing rigorous governance over what gets allowed into the code base. Modern engineering teams are successfully deploying specialized AI agents as night janitors to refactor old code. In this view, AI clears the debt rather than adding to it, freeing humans from the grind of maintenance. There's quite possibly something similar that we can create for knowledge work in the future. But that still needs to be built.
So what might help?
We know that more AI won't fix the problem. But we can use AI to locate the problem. AI might be able to find and triage sloppy information, but it can't decide what good looks like, what is strategically relevant for your business. That's still very much human work.
Style guides offer a way of potentially linting knowledge, and they're far underused and misunderstood today. Style guides embedded into your AI workflow as a skill, for example, must do more than just remove em dashes and other AI stylistic and wording tells. We must take them a step further, to be ruthless editors: challenging our thinking, removing duplication, and checking and double-checking the logic of our statements.
We need to make frank feedback a core value for all knowledge work. The fix for work being accepted uncritically is a culture where pushback is normal and cheap.
Knowledge has to be treated as infrastructure itself. We have to treat company documentation as the code base that future automation will run on. Is it well governed? Is it clear who wrote it, who's responsible for it, when it was written, what was updated? We're not going to get around being smart about this.
As we figure out how to tackle this wave of work slop, remember: the standards didn't change. Our ability to detect failures of those standards has. The tools changed. Taste and judgement remain the essential human job.