The wall of text is becoming the product

For twenty years the job was to make people read less. Shorter copy, sensible defaults, progressive disclosure, show only what’s needed at the moment it’s needed. Then AI arrived and we rebuilt our own work around enormous blocks of text: PRDs, system prompts, rules files, implementation plans, research summaries, PR descriptions, transcripts, and generated summaries of all of the above.

The text keeps growing for a good reason. What a model produces tracks the quality of the context it was given, so we add context. The trouble is what that assumes about the people in the room: that they will read, verify and maintain all of it. We already ran that experiment. It’s called terms and conditions.

People care who can see their photos and their bank balance. Almost nobody reads the agreement that governs it. That isn’t carelessness. Twenty pages of legal text above an Accept button is an interface whose shape has already made the decision. The information is available; the conditions for understanding it aren’t. What you get is the appearance of informed consent.

I think we’re building the same thing inside product teams, except what’s being accepted isn’t a privacy policy. It’s the product.

Context is the material now

The old artifacts had edges. A PRD described a feature, a Figma file an interface, a repo an implementation, a ticket a unit of work. One long prompt can now hold requirements, interaction logic, constraints, edge cases, analytics and test criteria at once. Its output becomes the input for another agent, whose output gets summarized for a third, and eventually something writes code.

So the lifecycle looks less like a sequence of handoffs between disciplines and more like a chain of translations: problem to prompt, prompt to spec, spec to design, design to code, code to review summary, summary back into a prompt. Meaning gets compressed, expanded or quietly altered at each step, and what ships is whatever survived.

That makes the prompt an interface, and by the standards we apply everywhere else, a bad one. In conventional software we label the buttons, constrain the inputs, confirm destructive actions and make state visible. With a prompt you don’t know which sentence mattered, which instruction was ignored, which stale file outranked the new one, or what the model actually read. Every feedback mechanism we’d insist on in a checkout flow is missing.

I can see it in my own repo. The CLAUDE.md for this site has a rule about which two typefaces are allowed and, a few paragraphs away at exactly the same visual weight, a warning about a config setting that breaks login if someone “fixes” it. One is taste. The other is an outage. Nothing in the file says which is which, except that I happen to remember.

The enterprise “I agree”

Here’s the agentic coding loop as most of us run it on a busy day. The agent proposes a plan. It’s long, so you skim, and it looks sensible, so you approve. The agent edits twenty-three files. A model summarizes the changes. You read the summary rather than the diff. Tests pass. You merge.

Every step there is defensible. But at each one the information available exceeded the information consumed, and by the end you were reviewing a representation of a representation of the work.

Abstraction isn’t the problem. No engineer reads the instructions a CPU executes, and no designer inspects every pixel the browser paints. It becomes a problem when the abstraction hides the one thing the decision depended on. Approve plan, accept changes, merge, ship: those are decisions, and a wall of text doesn’t support a decision just because the relevant sentence is in there somewhere.

Better models make it worse

A weak system keeps you alert. If the code is obviously broken or the research is obviously invented, you check everything.

A strong one produces work that mostly looks right, and that’s when verification gets hard. Take a 2,000-word implementation plan in which one sentence assumes something false about how refunds work. I’ve spent five years designing payouts, and that’s the kind of sentence that is easy to write and expensive to be wrong about. The plan reads well, so the sentence becomes implementation context. The code is coherent, the UI looks correct, QA covers the happy path, and three weeks later the assumption is in production. The model was perfectly capable of building the feature. What failed was a reviewer who, reasonably, let the quality of the other 1,990 words stand in for the ten that mattered.

Polish reads as credibility. Nine correct claims buy the tenth a pass. A tool that’s been right for months gets a lighter look each time. None of this is a character flaw; it’s how attention gets rationed. But it means the rare mistake gets more expensive exactly as mistakes get rarer. A mediocre agent exposes a misunderstanding within minutes. A great one builds the wrong thing beautifully.

A summary isn’t a second opinion

The obvious fix is summarization, and it has a flaw people skip past. Every summary answers the question “what can safely be left out?”, and the thing answering is usually the same model whose work you’re meant to be checking. If it misunderstood the requirement while writing the code, it will carry that misunderstanding into the summary. You get a cleaner view of the same reasoning, which is a different thing from an independent check.

Most generated summaries are also built for comfort. “Implemented the requested feature. Added appropriate error handling. Updated relevant tests.” The least useful thing an agent can tell me is everything it did correctly. I want to know where I should disagree.

Design the approval, not the document

“Human in the loop” is doing a lot of unearned work in these conversations. A person who clicks approve after scanning 7,000 words is in the loop the way a person who accepts a privacy policy has consented. Oversight runs on attention, attention is finite, and so the goal can’t be to show people everything.

What I’d want in front of a PM reviewing an agent-built feature is closer to this:

• Decisions made. Five were needed to build this.
• Rules reused. Seven behaviors came straight from documented product rules.
• New assumptions. Two behaviors were inferred because no rule existed.
• Conflicts. One requirement contradicts the current checkout spec.
• Blast radius. Three existing flows change, plus one new analytics event and one schema change.
• Confidence. Well supported throughout, except refund handling.

Six lines, and you know where to spend the next twenty minutes. The full text still exists behind it. It just isn’t the interface anymore.

The same move works before anything is generated. I don’t need the model’s chain of thought. I need its working assumptions: what it thinks the problem is, which constraints it treats as hard, what it believes has already been decided, and what it’s going to infer unless someone stops it. A developer used to ask, “what happens if the organizer cancels while a payout is processing?” An agent will just pick an answer. Surfacing that pick is the cheapest correction available, because nothing has been built on it yet.

And it works on the context itself, which right now looks like the web before design systems. Every team has its own CLAUDE.md, prompt templates and definition of done, full of duplicated, contradictory and expired instructions that nobody dares delete. A business rule shouldn’t carry the same weight as a style preference. A confirmed customer fact shouldn’t look like a model’s hypothesis. Yesterday’s requirement shouldn’t sit quietly beside the one that replaced it. Context needs hierarchy, provenance, ownership and an expiry date, so the structure tells you what kind of statement you’re reading before you’ve read it.

Every one of these is an information architecture problem. We know people scan. We know hierarchy directs attention, that defaults steer behavior, that something can be on the screen and functionally invisible. That knowledge now applies to the machinery of product development, where the users happen to be our own teams. It’s why I don’t think the opening for designers is prompt writing. It’s designing comprehension: what the agent sees, what the reviewer sees, what changed, what’s uncertain, what may be collapsed and what must never be summarized away.

Shared text isn’t shared truth

“Prompt engineering” makes this sound like a writing skill. Ask an agent to redesign onboarding and phrasing is the least of it. Which onboarding, for which segment? Which experiments already failed? Which stakeholder preference is actually policy? Which technical limitation went away six months ago? Which document wins when two disagree?

No paragraph fixes that. AI is exposing something teams have been able to hide for years: most organizations don’t have a shared source of truth. They have shared sources of text, and until recently a human quietly reconciled them before anything got built. Now incorrect context can execute.

Early websites looked like documents, and early mobile apps looked like shrunken desktop software. AI work currently looks like giant markdown files, because language is the easiest protocol between people and models. It’s a fine input format for the machine and a poor decision surface for a person. The machine can read ten thousand lines. The person needs the five decisions inside them, and needs to know which one to doubt.

We know what people do with a wall of text. They click accept. The work now is making that click mean something.