What is the AI noise tax?

THE SHORT ANSWER

The AI noise tax is the credibility a product team loses when it performs the AI shift instead of shipping it. Three patterns pay it: LinkedIn superpower posts that wrap two-year-old model behavior in a new badge, SaaS companies publishing agent-strategy essays while shipping a 2019 forms-and-tables UI with a chat sidebar grafted on, and PMs arguing prototyping breaks customer empathy. Each lets a team feel like it is participating in the shift while shipping the same product as last quarter. The fix is the work, not another post.

I am tired of three patterns clogging my feed. None of them ship. All three tax the credibility of every PM and product team doing the actual work. I would rather call them out once than keep losing the same five minutes a week.

Pattern one: superpower posts

A screenshot of Claude or ChatGPT doing something, a "I just discovered" or "game-changer" caption, and a "comment PROMPTS for the guide" CTA. The label says leap; the reality is the model has been good at this for eighteen months. The damage is not any single post. It is the aggregate signal a PM gets from scrolling: that the field moves in disconnected micro-leaps, that someone is always one superpower ahead, that committing to a workflow is pointless. The hard work of building useful AI workflows is not screenshottable and does not make a Reel, so you do not see it on the feed.

Pattern two: essays without the receipts

A SaaS company with a 2019-era forms-and-tables UI publishes a thousand words on its agent-first strategy. Then you open the product. Same dashboard, same forms, a small "Ask AI" button in the corner that opens a sidebar and summarizes data already on the page. That is not an AI shift. That is a chat sidebar. Run two public checks: the changelog, for whether cadence and release size actually changed, and the primary surface, for whether the agent is the surface or is banished to a sidebar. Both are public, and the reason most companies skip them is that the answers are uncomfortable.

Pattern three: the anti-prototype PMs

The argument that PMs should not prototype because it pulls them away from customers, usually with Cagan or Torres grafted on out of context. It depends on a 2019 premise: that prototyping is expensive and eats weeks of engineering. It does not anymore. A working prototype takes hours. The prototype is the customer empathy tool, the cheapest way to put a real artifact in front of a customer and watch their actual behavior. The people writing the posts have mostly not used the tools.

What to do this week

One small thing per pattern, none more than an evening. If you were about to post a superpower screenshot, instead evaluate one workflow you actually use and write one paragraph on what improved, what broke, and the metric it moved. If your company is publishing AI-strategy posts, ask in the next product review whether the changelog cadence and the surface design actually shifted to match the post. If you are arguing your team should not prototype, build one prototype with Claude Code, run it past three customers, and re-read your last post on the subject. The fix is the work, not one more post.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read