- Doc
- SG-20261020
- Rev
- 1
Irreducible Context
Recently I saw some shade being thrown on Twitter about Amazon no longer embodying the culture it built during its heyday. Culture usually shifts when leadership does, and most of these takes are tech-bro laments posted as engagement bait. This one was about writing...which, if you're reading this, you can guess is something I care about.
Colloquially known as Jeff Bezos's Amazon Memo, the 6-page pre-read before every important meeting rode in as the knight in armor to slay the dragon of corporate PowerPoint slides and save the princess of productivity and alignment in the early 2000s. It worked surprisingly well, for the following reason:
Full sentences are harder to write. They have verbs. The paragraphs have topic sentences. There is no way to write a six-page, narratively structured memo and not have clear thinking.
Fast forward to 2026, and here be AI dragons that have evolved into frontier leviathans, juiced up by subsidized inference and armed with machine-gun decoders firing so many tokens per second, all with a beer gut hanging out. From any angle, it's a sloppy dragon, and the long-dead knight never stood a chance.
Steve Huynh's On the Death of Amazon's Writing Culture calls out an L7 PM (a senior Amazon product manager, paid big bucks) who skipped the thinking and went straight to prompting a six-pager. The awkward part is that within a few minutes, it was painfully obvious to his senior engineering peers that the PM had not written any of it and was reading the doc for the first time too.
There's a word for this behavior, or rather for the PM, and it's a bit unsavory, perhaps intentionally. He is a meat proxy, and his entire contribution was to relay the output of an AI model to the intended recipient.
As AI becomes more mainstream and encouraged at work, does it put you at a disadvantage not to be a proxy? Perhaps the PM did this mental calculus and decided to YOLO it. Or, even worse, he'd been on the receiving end of AI-written docs and was doing unto others as had been done unto him. This is where things go from sloppy to slippery.
Just the other week, a very senior product leader chatted with me about where I thought the product development lifecycle (PDLC) was headed. I wrote about my views on product last year, and my view hasn't changed too much. But the conversation did make me challenge some of my priors.
Could there be a world where life goes on just fine if we were all happy being proxies? Will models get good enough that product requirements and specs become relics of the past, and we just describe the experience we want and everything gets made? How do senior PMs mentor junior PMs if AI does a lot of the entry-level work?
I don't think we can all be happy proxies, because a person is worth the context only they can add. Anything a model could have guessed on its own, it will happily write for you, so the part that's actually yours is what it couldn't guess, like the user's quirks, the judgment call on taste, or the tradeoff that was already decided. I've started calling this irreducible context. Models, people, and teams all depend on it.
How a Model Measures Surprise
Annie Sexton's Compression is prediction on the ngrok blog is one of the best explainers I have come across in recent months. She successfully nerd-sniped me, and I'd recommend reading the whole thing if you have time.
Compressing a file and predicting what comes next are the same job-to-be-done, which means the large language models (LLMs) we use every day are, under the hood, very good compressors. An LLM reads text as tokens, numbers that stand for whole words or pieces of words, and its entire job is to predict which token comes next, or in her words, fancy autocomplete.
What I found most interesting is what her article says about the part that can't be compressed by a model, or the irreducible context.
Compression is the work of storing a message in as few bits as possible, like zipping a file, and bits are how compression keeps score. The trick every compressor relies on is spending fewer bits on what it expects and more bits on what surprises it, the same way Morse code gives the common letter "E" a single dot and saves the longer codes for rarer letters like "Q."
So the better a compressor can predict what comes next, the smaller the file gets, and predicting what comes next is exactly what an LLM is built to do.
Cool. Everything mentioned thus far should intuitively feel true even if we aren't model trainers. But what about the things models can't do well? That's what Annie measures and calls surprise.
A word the model saw coming costs almost nothing to store, and a word that surprised it is expensive. Every message also has a floor, a point where there's nothing predictable left to squeeze out, and the only way to go smaller is to start throwing information away, which is what lossy formats like JPEG do on purpose.
When fully optimized to sit at the floor, it's actually quite easy to surprise the model, to the point where getting something working generally means raising the floor again. That added cost is the irreducible part, and it's the same thing a person adds to a doc when they bring context the model couldn't have guessed.
Here is a very cool interactive example, using a sentence drawn from my day job. We are going to look at probabilities and cost while keeping the model the same. What changes is how much context it gets before it has to predict "The inquiry uplift is delayed and the API won't be ready." Step through one word at a time and switch between the three prompts. You don't need to follow the math, just watch which words stay underlined.
The model only has the word "The" to go on.
The?
underlined words cost 3+ bits, the irreducible context this prompt didn't supply
- first0.06
- new0.05
- best0.04
- inquiry0.0005
Why Models Can't Skip the Spec
The same 10 words cost roughly 46 bits with no prompt, 35 with a thin prompt, and under 5 with rich context. Nothing about the sentence or the model changed between runs. The only thing that changed was how much the model knew going in.
Generation is more or less the same mechanism running in the other direction. When a model writes, it picks likely tokens one after another, and what counts as likely depends entirely on the context it was given. With a rich prompt, the likely next token is the specific one. With a thin prompt, the model sits at the floor and fills the gap with whatever is most probable across everything it has read, which is another way of saying the most generic thing.
From the model's side, then, the output can never carry more than the context put in.
So to the question of whether models will get good enough that we skip the specs and just describe the experience we want, I don't think the spec goes away. The description of the experience is the spec, and the model can't fill in what it doesn't say. Sean Grove of OpenAI put it best in his talk The New Code: "If you don't have a specification, you just have a vague idea."
His broader argument is that the bottleneck has shifted away from code. He estimates that code is only about 10–20% of the value an engineer brings, and the rest is the communication around it, like understanding users, distilling what they need, planning, and checking whether the result actually worked. As models take over more of the implementation, that communication becomes the constraint, or in his words, "structured communication is the bottleneck."
He also points out that vibe coding usually keeps the generated code and throws away the prompt, which he compares to shredding your source code and carefully versioning the binary (only engineering nerds who work with compilers will get this, sorry!). To pull it back to what I am writing about, that's the same as throwing away the irreducible context and keeping the slop.
Can We All Be Proxies?
Look at the thin prompt in the demo again. The model handles "is," "and," and "be" just fine on its own, but "inquiry," "uplift," "delayed," and "API" stay expensive. "Inquiry uplift" is a project name the model had no way to know, and nothing in "write a status update" could tell it what slipped or why.
Those underlined words are what I mean by irreducible context, and they are the only part of a document a person actually adds. It's whatever the model couldn't have predicted from the prompt, like a fact from the real world, a judgment call, a tradeoff that was already decided, or a constraint only the customer knows about. Everything else, however polished, is decompression of a short prompt into longer prose.
Steve half-jokes that it would be more honest for everybody to just share their prompts, and Sophie Alpert's AI writing policy at Clay, which Steve cites, says it directly—if a long document came from a short prompt, share the prompt. At this point I hope it's clear stepping through the bits example to understand why we want to see what went into the pot.
When something becomes cheap, something else becomes expensive. A generic document is cheap in bits and tokens but expensive for every person who has to read it and figure out that nothing is there. The PM passed the cost of thinking on to his coworkers. Steve goes as far as describing sloppy AI-generated documents as "AI;DR," on the theory that if a model wrote it, a model can summarize it.
So, back to the question of whether it puts you at a disadvantage not to be a proxy. In the short term, the proxy looks faster, and everyone doing it seems to be running circles around you. Over any longer stretch, I believe the context only you can add is what keeps you in your job. In the future, the PM paid big bucks will be paid for exactly the part the model couldn't guess.
Before you send anything a model helped write, ask what in it the model couldn't have predicted from your prompt. If the honest answer is nothing, maybe the team would be better off if you just took some vacation.
What Untrained Teams Cost
If new product and tech teams are not well-trained in using AI properly, the business pays the price. The models themselves are already well-trained and capable, so bad output usually comes down to the context they get, or the lack of it. An untrained team hands over something like the thin prompt in the demo, missing exactly the parts only they could supply, like which project it is, what slipped, and why. The model then does what it's built to do and fills each gap with its most probable guess.
Follow the thin prompt's top guesses and you get "The payments roadmap is on track," a sentence that reads perfectly well and is exactly wrong. In a real plan or status update, that kind of confident miss takes real effort to spot, and the fix isn't more training for the model but more training for the team.
Mentoring When AI Writes the First Draft
If senior PMs are going to mentor junior talent on this, it changes where I think review belongs in the product development lifecycle. Today, most of the feedback a junior PM gets happens on the decompressed output, like PRDs, design docs, and scoping tickets, but if that context enters at the spec, that is where the review and the coaching should happen too.
That lines up with Sean's point that the spec, not the generated code, is the artifact worth keeping. I wrote about a version of this last year in The Future of Product Development, where a short written brief holds the rules and the plan that the AI then works from, which I described as "what a PRD is meant to be."
At the time, I thought of those files as a productivity hack, but looking back, they were an early version of what a good deliverable looks like now, a file that holds what the model can't guess so everything else can be generated from it.
So what does mentoring look like when AI does a lot of the entry-level work? Since a model now writes most of the first drafts a junior PM used to learn on, I believe the reps have to move to the context instead. In practice, that means asking a junior PM to share the prompt alongside the doc, the same way Sophie's policy suggests, and reviewing the prompt first.
The most useful question a senior PM can ask is what the junior PM knew that the model didn't. If they can name it, like the dependency that slipped or the tradeoff the subject-matter expert rejected, they are learning the part of the job that will last. If they can't, the review becomes a lesson in where to go find it, whether that's the customer, the engineers, or the data.
It's also the best way I know to teach someone to catch a confident miss like "The payments roadmap is on track," and I believe it's the part of the job a model won't take from either of them.