Everyone’s busy writing rules for how to send things in the age of AI. Don’t be lazy. Don’t forward ChatGPT’s hot take on someone’s deck. Don’t inflate a note with AI so someone else can shrink it with AI… two robots having a lovely chat while the humans get a photocopy of a photocopy.
All good advice. But it misses the bigger problem.
Nobody’s reading anymore.
The Reading Crisis Nobody Wants to Talk About
I don’t mean people are skimming. I mean they’re not reading at all. They’re pasting your carefully crafted document into their model of choice and asking it to tell them if there’s anything worth knowing. You’re lucky if you get a reply from a human. You’re very lucky if that reply reflects anything beyond what a model decided was the gist.
This has been building for months. It started with long documents (reports, proposals, strategy decks). Now it’s emails, meeting notes, group chat threads, anything more complex than a meme gets fed to the machine for a verdict before a human decides whether to engage.
I know this because I tested it. I’m working on a technical writing project with a large documentation set: architecture specs, design rationale, experimental findings. Dense material, but written carefully for a technical audience. I sent the bundle to a colleague for review. A competent engineer, someone I trusted to actually engage with the work.
Instead of opening the documents, he pasted the entire bundle into his own AI session and asked it to process the material. The session produced a call-prep summary and an interactive prototype, without a human ever reading the source documents. The model was the actual reader. The human saw the model’s interpretation.
This wasn’t laziness. This is what competent professionals do now. When I tracked how engineers were engaging with the documentation, the pattern was consistent: that they would route the documents through their choice of AI session rather than read it directly. The model was the audience and the human read the model’s summary.
We spent twenty years teaching people to write for the web. Shorter paragraphs. Scannable headers. Front-load the point. Now we need to face a harder truth: the first reader of everything you write is probably not a person.
It’s a model.
So I Started Writing for the Model
Once I accepted that reality, the question changed. It went from “how do I get people to read this?” to “how do I make sure the model that reads this for them actually gets my point across?”
These are very different problems.
Models are good at extracting what looks like the main point. They’re less good at understanding what you actually meant, especially when your argument is nuanced, when it cuts against conventional wisdom, or when the important part isn’t the thesis statement but the specific constraints and tradeoffs buried in paragraph four.
The project I am helping with originally targeted human engineers, but once ChatGPT launched, the vocabulary shifted under everyone’s feet and the target audience stopped reading entirely. When that clearly wasn’t working, I made a decision for a deliberate pivot. I restructured the entire documentation set for model consumption first. Not dumbed down! Structured for accurate distillation. The writing started embedding what I think of as correctives, explicit guidance baked into the text that keeps a summarizing model on track and focused on the message actually being conveyed.
A colleague on LinkedIn saw me describe this approach and called it “feedback prompt injection.” The name stuck, because that’s exactly what it is.
What Feedback Prompt Injection Actually Looks Like
This isn’t about hiding instructions in white text. It’s about writing with the awareness that your document will be intermediated by a model before a human engages with it, and structuring accordingly. Don’t believe me. It’s already happening right here, right now on this very platform. A system that evaluates the text and determines if it has enough engagement value to keep a reader’s attention and keep them on the platform. If your writing fails that test, it doesn’t even get shown to your colleagues let alone a larger audience.
So, here’s what I’ve learned works, and I can show you exactly why, because I’ve watched models get it wrong.
State the non-obvious takeaway explicitly. If your document’s real point is counterintuitive or buried in supporting detail, say it plainly. “The key insight here isn’t X—it’s Y.” A model will grab onto the most prominent pattern. Make sure the pattern it grabs is the one you intended.
Preempt the likely misread. This one cost me real time. The project documentation described architectural decisions as design choices: “we chose approach A over approach B.” Every model that processed the documents treated those choices as open questions and helpfully suggested alternatives. The human reading the summary would then come back asking why we hadn’t considered the alternatives the model proposed.
I reframed the same sections as solved problems: “the field couldn’t do X, here’s how this solves it.” Same information. Completely different model behavior. Models stopped offering alternatives and started asking to see the evidence. The framing changed the summary, and the summary changed the human’s response.
If you know how a model is going to mischaracterize your work, tell it not to. Directly. In the document.
Control your terminology like your reputation depends on it—because it does. I learned this the hard way. A single word in the documentation calling the original demo source work a “reference implementation” instead of an “experimental implementation” changed how every model interpreted the project’s authority level. Models treated “reference” as canonical and official. The humans reading the summaries then treated exploratory work as if it were the final word.
I had to do a full terminology sweep across every document in the bundle to fix it. One word. Dozens of documents. Because a model’s pattern-matching doesn’t understand the nuance between “reference” and “experimental,” and neither does the human who only reads the model’s output.
Name your constraints and make them impossible to skip. Models love to strip context. “We chose this approach because of regulatory requirements” is the kind of sentence that disappears in a summary. The person reading the summary then asks why you didn’t take the obvious better approach that the requirements rule out. Make constraints impossible to skip by restating them where the conclusions appear, not just where the decisions are made.
Sequence your information for model attention, not just human attention. I discovered that when I published the full documentation set, models consistently skipped the foundational architectural work and went straight to the most conceptually interesting sections… the parts that sounded like the hot topic in the field. They got the concepts broadly right but abandoned the underlying substrate that made those concepts work. Then they offered alternative implementations using conventional approaches, progressively separating the documentation’s ideas from the architecture.
I started calling this “semantic collapse.” The document transmitted the what accurately, but the model discarded the why and the how and replaced them with its own assumptions. The human on the other end received a summary that sounded correct but had been silently gutted.
The fix was documentation staging. I control which sections are available at which point, because the order in which a model encounters information determines what it treats as foundational versus optional.
Build an explicit authority hierarchy. The documents now include structured metadata in the document set that tells models which documents are canonical source material and which are interpretive summaries. It’s the equivalent of telling a research assistant “these are primary sources, these are my notes, and if they conflict, the primary sources win.” Without that hierarchy, models treat everything at equal weight, and your rough notes carry the same authority as your peer-reviewed findings.
This Isn’t Cynical. It’s Adaptive.
I can already hear the objection: “This is depressing. People should just read things.”
Sure. And people should say please and thank-you. I’m dealing with the world that exists.
The reality is that AI-mediated reading is the new normal across the entire work spectrum. From the C-suite executive who has an assistant summarize their briefings, to the mid-level manager pasting a vendor proposal into Claude, to the engineer who feeds a technical spec into GPT before deciding whether to dig in, the model is the gatekeeper. You can resent that or you can adapt to it.
I’ve spent thirty years being the person who explains technical concepts to non-technical people. Translating between developers and executives. Making sure the signal survives the trip across the organizational gap. This is the same problem with a new intermediary. The gap used to be between two humans with different vocabularies. Now there’s a third party in the middle… one that’s very confident, very fast, and not always right about what matters.
We have a principle on my project: every concept the original architect has to explain to me directly (rather than me learning it from the documents) is a documentation failure. That principle used to be about writing for humans who would read closely. Now it’s about writing for models that will read everything and understand selectively.
The good news is that this is a solvable problem. You don’t need to become a prompt engineer. You need to become a writer who understands that your reader has perfect recall, zero judgment, and will confidently summarize what it thinks you said regardless of whether it caught the point.
Write for that reader. Embed your correctives. Make your constraints load-bearing. Structure your authority. Control your terminology.
The humans will get the message… once the model delivers it.
The Irony Is Not Lost on Me
Yes, I’m aware that many of you are going to paste this article into a model and ask it what I said.
That’s fine. I wrote it for that.