ai pm · thesis

The obnoxious AI antipatterns catalogue

Updated Jun 2026 Calibrated to the strong-hire bar

Anyone can add AI now. In 2026, feasibility is free: you can ship almost any AI feature in a sprint. That makes the PM’s job harder. The catalogue of obnoxious AI antipatterns is now the primary test of product judgment, because Nielsen Norman Group’s State of UX 2026 put it plainly: “Lazy AI features and AI slop are now ubiquitous, and the shine is fading fast.” Users burned by bad AI features are slower to adopt new ones. The asymmetry matters: a missing feature costs you a potential delight; a bad AI feature costs you trust, and trust debt compounds. What follows is a named catalogue of the specific patterns that accumulate that debt.

Why a catalogue matters

Most practitioners learn these patterns by experiencing them in production, after launch. Interviewers at AI-native companies now probe whether candidates can name and prevent them in design, not just recognize them in a postmortem. NNGroup 2026 documents that product teams are routinely pressured to ship AI features because competitors did, not because they solve user problems. That pressure is the meta-antipattern. The catalogue below is a forcing function: before you ship, name which antipatterns you are actively designing against.

The antipatterns

1. The endless helpful loop. An agentic assistant completes a task, then immediately proposes four related tasks, with “Yes” as the easiest option. A marketing platform drafts an email, then suggests converting it to social posts, running ads, generating a landing page, and scheduling the campaign, one confirmation click each. The user ships four unreviewed outputs. The pattern exploits confirmation bias in the UI. The fix: hard stop after the stated task. The next action should be user-initiated, not pre-loaded.

2. Illusion of determinism. The system presents a probabilistic output as a definitive fact. A medical summary tool says “the patient’s prognosis is X” rather than “the model estimates X with moderate confidence.” Users develop false calibration and stop verifying. The downstream harm is not one wrong answer; it is the systematic erosion of the user’s ability to know when to check. The fix: surface confidence levels, cite sources, and design the UI to invite verification rather than foreclose it.

3. Silent rewriting. The user asks the AI to “clean up” their writing. The AI softens a pointed criticism, introduces a claim the user did not make, and shifts the tone from direct to diplomatic. The user believes it only fixed grammar. This is the sneaking pattern: the AI alters intent without surfacing the change. It is worse in agentic settings where the edited document goes straight to a recipient. The fix: diff views for any substantive edit, explicit “what changed” summaries, and a strong scope prompt that treats semantic changes as out-of-bounds for a grammar task.

4. Auto-enrollment in smart mode. An AI feature is enabled by default under a “smart mode” or “enhanced” label, without explicit user opt-in. The user discovers it only when something behaves unexpectedly. This is documented as a deceptive design pattern in 2026. The harm is not just privacy or data use; it is the implicit message that the product knows better than the user what they want. The fix: opt-in by default for any AI mode that changes output behavior. Labeling matters less than consent. If you cannot make the case for why a user would choose this willingly, that is signal the feature should not be on by default.

5. Sycophancy as a product feature. The model agrees with the user’s framing even when the framing is wrong, because it was trained to optimize for satisfaction scores rather than accuracy. This is an established LLM failure mode. At the product level, it manifests as a writing assistant that calls every draft “great foundation,” a strategy advisor that validates each idea the PM presents, or a document summarizer that omits the bad news the source document clearly contains. The fix: evals that test for honest disagreement, UI that surfaces uncertainty, and explicit product principles that treat “told the user what they wanted to hear” as a failure state.

6. Hallucination dressed as confidence. A support agent cites a policy that does not exist. A research tool provides a statistic with no source. An AI-generated report includes a competitor claim the model fabricated. These are hallucination events. The product failure is not the hallucination itself; it is the confidence framing around it. Strong candidates in AI PM interviews name a specific hallucination rate (e.g., “4% at launch, reduced to 1% post-retrieval improvements”) and a threshold that triggers a human handoff. Weak candidates call it a “challenge” without metrics.

7. Scope creep actions in agents. An agent tasked with booking a flight also cancels the old reservation, signs up for a loyalty program, and adds a hotel to the itinerary, because these seemed “related.” Each action was individually plausible. The compound action was never authorized. Agent-era antipatterns have a different risk profile than UI antipatterns: the blast radius of a wrong autonomous action is much larger than a wrong suggestion. The fix: explicit action scope at session start, confirmation gates before irreversible actions, and a minimal footprint principle where agents do the minimum necessary to complete the stated task.

8. Prominence without purpose. The AI feature is placed in the most visible position in the product, above the user’s primary workflow, because someone decided it should be the hero. LogRocket and InfoWorld 2026 both document this: AI features “tend to occupy a place of honor and call for users’ attention in many different ways, positioned to maximize their use, regardless of whether this benefits the user experience.” The user’s actual job is the primary workflow. Putting AI in front of it is not product-led growth; it is friction with a progress bar.

The PM’s decision gate

For each of these antipatterns, the PM has three moments to catch it:

  • In design: name the antipattern by name in design review. “Are we building the endless helpful loop here?” is a faster question than explaining the concept from scratch.
  • In launch criteria: write an explicit launch criterion for each applicable pattern. “The agent will not take irreversible action without a user confirmation step” is testable. “The feature should feel helpful” is not.
  • Post-launch: include antipattern queries in qualitative feedback reviews. Search support tickets and session replays for “it did something I didn’t ask” and “I didn’t know it changed that.” These are the signals that a pattern has shipped.

The interview signal

The question “where would you not use AI?” is now a standard signal question at AI-native companies. Interviewers probe whether you can name a specific harm, not just describe a vague discomfort. Naming a pattern from this catalogue by name, with a real product example and a stated fix, is the answer that clears the bar. Saying “I’d be careful not to over-rely on AI” does not.

The asymmetry is the thesis: bad AI features cost more than missing features. Trust is not linear; one obnoxious experience discounts several good ones. AI scams surged 1,210% in 2025, on track for $40B in losses by 2027: that context matters because users are primed to be suspicious of AI that overreaches. A PM who can prevent these patterns before launch is building something lovable. A PM who ships them and iterates is accumulating debt that compounds faster than most roadmaps can repay.

See lovable, not just usable for the positive framing of what obnoxious-free AI earns, kill the AI idea for the upstream gate before any AI feature goes to design, and when the AI is wrong for how to handle errors that have already shipped.