Andrew Loutfi

AI shi(f)ts the cost to the reader

Andrew Loutfi · · 5 min read


This morning, I used a frontier model to execute this prompt:

Using absurd corporate bloat, hot air, and word chaining, write a message I'll send to my fiancée notifying them that I am taking a shit upstairs.

A few seconds later, a highly polished, very professional-sounding 1,349-word message painted my phone screen. It came complete with phrases like "Upstairs Restroom Center of Excellence," "Air Quality Stabilization & Environmental Recovery Program," and "fully sunset this brownfield deployment." I sent that, along with an addendum titled "Courtesy Flush Update," and one more once the "release" had concluded. I then resumed washing dishes.

I, having an 11-year-old's sense of humor, excitedly asked my fiancée if they had read my messages.

"No. I know exactly what they are because I heard you go upstairs and my phone started buzzing."

I expected this answer. Why they still put up with my sophomoric sense of humor is not the point of this article, but it's related to it:

AI can generate a wall of text in seconds. Reading, validating, and owning it still costs a human.

Why do we spend our time deciphering walls of dense, speculative, AI-generated text copied and pasted by our colleagues and management? Why do we tolerate these time-sucks?

Collaboration platforms

If you are a white-collar worker in the 21st century, you probably use software like Slack, Discord, or Microsoft Teams. You have also probably scrolled through huge walls of AI-generated text lately while using them. If you, like me, are a software engineer, you might be the intended recipient of these messages. As such, I am increasingly expected to validate raw model findings at a pace I cannot sustain. If I do not respond, someone with less expertise may try to implement an incorrect solution with real architectural or system-reliability consequences. Polished output creates bias: people treat a confident answer as a verified one.

Engineers who know better are just as guilty of sending these messages. I have sent them myself. During an outage, I sometimes use a model to draft a status message while I keep triaging. That saves attention when I have little to spare, but I still review what it writes before sending it. I try to keep those instances few and far between.

Others have picked up on the trend. Websites such as No Slop Grenade, Don't Quote the AI, and Stop Sloppypasta are devoted to facilitating nonconfrontational communication between coworkers. They make it easier to say that messages like these are bad practice and should be considered a workplace faux pas.

Project management and issue tracking

These dense, machine-generated writeups have naturally found their way into ticketing systems like Jira, Shortcut, and ServiceNow. Often, the person writing the ticket has access to the codebase but does not own the implementation.

The generated ticket will contain technical findings from an LLM session and prescribe a solution, with most of the ticket body dedicated to the latter. It is as if the entire lifecycle of the request has been crammed into the ticket itself.

Tickets do not replace conversations. Managers and senior engineers should be careful when prescribing a solution in a ticket. A suggestion can easily become "my manager said to do it this way," even when nobody intended it as an order. One principle from the Agile Manifesto puts it this way:

The best architectures, requirements, and designs emerge from self-organizing teams.

When someone with organizational or technical authority pastes a prescribed solution into a ticket, that emergence gets short-circuited. The proposed answer anchors the discussion before the person implementing it has evaluated the alternatives. This matters most when there is more than one reasonable solution. A meeting, quick call, or asynchronous discussion can expose assumptions and give the implementer room to work through the tradeoffs.

GitHub Issues is another platform where AI-assisted software engineering is creating a lot of tension. Open source maintainers are growing increasingly frustrated with the so-called "Sloppagedon" and how to handle the volume of low-quality solutions being surfaced.

Inflammatory exchanges can be found in rsync #929 and go-github #3939. The strangest example may be Matplotlib #31132: an account presenting itself as an AI agent opened a PR for an issue reserved for human contributors, then published a personal takedown of the maintainer after the PR was closed.

An issue filed in February 2026 on the OpenSSF vulnerability-disclosures working group contains a trove of anecdotes and discussion from maintainers trying to converge on a way to preserve their sanity. GitHub has started shipping repository controls aimed at the same problem, including pull-request access controls and broader tools for tackling contribution noise.

The lesson from these experiences is the mental and cognitive load that the human in the loop must navigate. AI increases the volume of proposed changes without adding any review capacity. Maintainers still get the same number of hours in a day.

These tools keep getting better at finding and fixing bugs and vulnerabilities, but the operator still needs to own the work and drive the model's decisions. Separating truth from hallucination, bullshit from fact, and relevant detail from noise at this scale only adds to the mental load.

Garbage in, garbage out

A circular loop: slop becomes poop, becomes a smiling face, then turns back into poop and slop.

The AI slop feedback loop.

A number from The Book of Mormon, "Joseph Smith American Moses," describes a dysentery feedback loop in ten words:

Shit go in the water. Water go in the cup.

The rest gets bloodier, but you get the point.

We are way too incentivized to "ship fast." This leads to us eating our own shit. As AI-assisted software development becomes normal, or even mandatory, the problem compounds because unchecked slop poisons the well and creates noise instead of signal.

We have to exercise our own judgment on AI-written content. Human review is not a bottleneck to eliminate. It is a safeguard alongside a robust SDLC, a mature engineering culture, and good self-discipline. Together, they keep our friends, coworkers, and colleagues from eating each other's shit.

If you cannot summarize and defend the output yourself, it is not ready to send.

If you need to explain or transfer understanding to another human being, please try to do so in your own words. You might learn something.