Reviewing slop and asking for better feedback

My AI slop annoys me. Your AI slop annoys me, but probably not as much as my own slop annoys me. We shouldn’t review it more than we have to, yet here we are. 🙄

We need to work together anyways.

Let’s talk about how to ask for feedback on your AI slop without ruining your relationships. No judgement … well, not much judgement anyways.

Economics 101

A teammate I’ll call Bob asked me to review a lengthy document in my field of expertise. At 30 pages, it seemed a bit long but not unusual for an internal analysis of alternatives¹ document. Yet after a moment, it was clearly full of the tech equivalent of lorem ipsum such that “please review” would become more like “please rewrite this for me”.

Let’s go back to Economics 101 for a moment to break down the interaction that happens all too often and why a well-meaning request became incredibly irritating instead of a normal daily teammate interaction.

how this piece started, minus a ton of annoyance no one saw thanks to remote work

AI made it cheaper to generate 30 pages of convincing text, but the cost to review didn’t go down.

Finding a profitable trade in this discrepancy in value is called “arbitrage.”² A basic example is “buy low, sell high” to purchase a good in one market and sell it in another. You have some costs of business like transportation, but it’s a simple profit. It’s not that dissimilar to our review faux pas.

value arbitrage between “making” and “reviewing” flipped

A well-researched and thorough analysis of alternatives is a complex document to write. Something that looks roughly right, and maybe even is correct, is now incredibly fast to produce. Human attention, to write or to edit, hasn’t gotten more abundant. If anything, it’s more scarce and stokes a bit of resentment.

Bob’s 30 page document bought content low and sold attention to it high. In organizations that value the number of documents and volume of content generated as a measurable result, Bob found the easiest path to “free money” with a new tool.

Asking for better feedback

Be clear when it’s slop.

The old model of code/document/case review was fewer, larger rounds of feedback that worked more like this.

1. author(s) draft and edit
2. one or two reviewers, then incorporate their feedback
3. final reviews
4. ship it 🚀

Instead, use the fact that “getting close” is now really fast and cheap to ask for simpler feedback more often. In this case, I’m asking for a quick check of “is this document on the right path before I spend more time on it?”

No rush on my part - just figured if I’m on the right path-ish to useful salesy/capture stuff, I can edit it into something I’d feel good about. If it’s not at all useful, I’ll delete the slop and we’re out a combined 10 minutes of human time. 🙂

Fence your ask

It’s always best to be explicit about what you’re asking for (and what you’re not!!) from another person. Here’s an example:

to be clear, not asking for an in-depth review, just “useful” or “would be better as a 1-pager” or “should be in sharepoint instead” … other short/high-level feedback. no need to spend lots of time on slop.

This info helps the other person scope how much time to spend on what you’ve asked for.

Could you review this?

Yes, and please tell me what you’re asking for? I’ll put as much effort in as I think appropriate. Try not to read that unkindly, as it’s never my intention. We all have things to do. 🤷🏻‍♀️

Not to throw stones in this glass house, since I ship a bunch of code now that I don’t review in any detail. In a system and problem space that I understand deeply, with a continually-improving series of tests and boundaries to constrain the wild randomness of the code gushing in, it feels … safe? Safer? Acceptably risky?? When my footing isn’t so sure, my review gets a lot slower to pay attention when it matters.

Goofus says “Mother will clean this up.” Gallant says “Let’s not leave this for Mother.”

This feels like the new professional Goofus and Gallant rules. After a while, our norms will settle back down again. The diligent teammate will still be valued. The annoying teammate that takes the easiest way out will still take the easiest way out.

Goofus sends over a big document with a vague ask for feedback.

Gallant asks for specific, scoped feedback that acknowledges how much effort he’s spent too.

Arbitrage settles over time

The flipside of arbitrage is that eventually, the cost difference between the two markets trends to nothing. If it costs $100 more to buy a widget in City A versus City B, a few early people will make a profit by transporting widgets between cities but as more people do so, the profit on that widget diminishes.

Attention isn’t that much different than a physical widget. It’s a fixed quantity, since AI did not give anyone more hours in the day. I can’t make more time than I have, but neither can anyone else. I’m not spending it writing as many first drafts, but am instead now spending it editing and polishing and building systems to make lots of other random inputs/outputs safe.

The 10-minute 30 page document being “valuable” depends on the assumption that length is equivalent to expertise. Page count or impressive (but questionable) graphics won’t be a proxy for effort when it’s not reliably good. Big documents poorly reviewed is the new “buy low, sell high” for attention in the office and just like any other new tool in the workplace, we’ll all find a new balance with it.

Anthropic published a thorough AI-native SDLC playbook , and this picture from it made lots of rounds through the Slack/Discord/text groups I’m in … without the surrounding context, naturally.

The entire playbook is worth the read, since the context around that picture changes the meaning versus the “hot takes” in private chats. It’s true that the time spent writing code (and presentations and client deliverables and anything else) collapses, but the test/review/maintain time only stays constant if they were fantastic to begin with. In practice, though, systems to support quality and reliability and continuous improvement are where “pre-AI” teams invest the least.

When you could safely assume a thoughtful and thorough professional assembled your non-code deliverable, it was possible to spend less time reviewing it. Now that’s not the case, a similar shift to focus on “post writing” quality tasks is (begrudgingly) taking place outside of code too.

Kindness

Don’t be a meat proxy , simply forwarding what anyone can put into another system. This is the new “let me google that for you” where someone would just ask what could be easily searched on your own.

let me google that for you

The kindest thing Alice can do is privately ask “did you read this before sending it?”, not simply ignore Bob entirely going forward after the first suspicion.

It’s awkward to ask it and awkward to admit to it. If it’s a problem, this isn’t anything beyond a new “performance conversation” and do what you need to do based on your role. The job hasn’t changed even if the tools have. Building together in the same sandbox has always been the more challenging part than building something smaller solo.

Generating the thing got cheap. Asking well didn’t, and that’s the part still worth doing on purpose. 😅

---

Footnotes

1. An “analysis of alternatives” document is exactly what it sounds like. A client asks a question such as “how would I think about launching widgets in Q4 in market?” or “compare tools to solve problem in my tech stack” and an AoA doc talks through a few alternatives and their pros/cons/costs/etc., then usually ends on a recommendation. ↩

2. What is Arbitrage? 3 Strategies to Know from Harvard Business School is a good primer. The Wikipedia page on “Arbitrage” is a great page to continue learning a ton more about the concept. There’s also an NPR podcast Planet Money with an approachable case study on college textbooks that’s well worth a listen. ↩