AI shi(f)ts the cost to the reader · Andrew Loutfi<br>Skip to contentThis morning, I used a frontier model to execute this prompt:
Using absurd corporate bloat, hot air, and word chaining, write a message<br>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<br>message painted my phone screen. It came complete with phrases like "Upstairs<br>Restroom Center of Excellence," "Air Quality Stabilization & Environmental<br>Recovery Program," and "fully sunset this brownfield deployment." I sent<br>that, along with an addendum titled "Courtesy Flush Update," and one more once<br>the "release" had concluded. I then resumed washing dishes.
I, having an 11-year-old's sense of humor, excitedly asked my fiancée<br>if they had read my messages.
"No. I know exactly what they are because I heard you go upstairs and my phone<br>started buzzing."
I expected this answer. Why they still put up with my sophomoric sense of<br>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,<br>AI-generated text copied and pasted by our colleagues and management? Why do<br>we tolerate these time-sucks?
Collaboration platforms
If you are a white-collar worker in the 21st century, you probably use<br>software like Slack, Discord, or Microsoft Teams. You have also probably<br>scrolled through huge walls of AI-generated text lately while using them. If<br>you, like me, are a software engineer, you might be the intended recipient of<br>these messages. As such, I am increasingly expected to validate raw model<br>findings at a pace I cannot sustain. If I do not respond, someone with less<br>expertise may try to implement an incorrect solution with real architectural<br>or system-reliability consequences. Polished output creates bias:<br>people treat a confident answer as a verified one.
Engineers who know better are just as guilty of sending these messages. I<br>have sent them myself. During an outage, I sometimes use a model to draft a<br>status message while I keep triaging. That saves attention when I have little<br>to spare, but I still review what it writes before sending it. I try to keep<br>those instances few and far between.
Others have picked up on the trend. Websites such as<br>No Slop Grenade,<br>Don't Quote the AI, and<br>Stop Sloppypasta are devoted to facilitating<br>nonconfrontational communication between coworkers. They make it easier to say<br>that messages like these are bad practice and should be considered a workplace<br>faux pas.
Project management and issue tracking
These dense, machine-generated writeups have naturally found their way into<br>ticketing systems like Jira, Shortcut, and ServiceNow. Often, the person<br>writing the ticket has access to the codebase but does not own the<br>implementation.
The generated ticket will contain technical findings from an LLM session and<br>prescribe a solution, with most of the ticket body dedicated to the latter. It<br>is as if the entire lifecycle of the request has been crammed into the ticket<br>itself.
Tickets do not replace conversations. Managers and senior engineers should be<br>careful when prescribing a solution in a ticket. A suggestion can easily<br>become "my manager said to do it this way," even when nobody intended it as an<br>order. One principle from the<br>Agile Manifesto puts it this way:
The best architectures, requirements, and designs emerge from self-organizing<br>teams.
When someone with organizational or technical authority pastes a prescribed<br>solution into a ticket, that emergence gets short-circuited. The proposed<br>answer anchors the discussion before the person implementing it has evaluated<br>the alternatives. This matters most when there is more than one reasonable<br>solution. A meeting, quick call, or asynchronous discussion can expose<br>assumptions and give the implementer room to work through the tradeoffs.
GitHub Issues is another platform where AI-assisted software engineering is<br>creating a lot of tension. Open source maintainers are growing increasingly<br>frustrated with the so-called "Sloppagedon" and how to handle the volume of<br>low-quality solutions being surfaced.
Inflammatory exchanges can be found in<br>rsync #929 and<br>go-github #3939. The<br>strangest example may be<br>Matplotlib #31132: an<br>account presenting itself as an AI agent opened a PR for an issue reserved for<br>human contributors, then published a personal takedown of the maintainer after<br>the PR was closed.
An issue filed in February 2026 on the<br>OpenSSF vulnerability-disclosures working group<br>contains a trove of anecdotes and discussion from maintainers trying to<br>converge on a way to preserve their sanity. GitHub has started shipping<br>repository controls aimed at the same problem, including<br>pull-request access controls<br>and broader tools for<br>tackling contribution noise.
The lesson from these experiences is the mental and cognitive load...