AI is Making It Free to Gamify Everything. Why That’s a Problem.

The next dark pattern crisis is being vibe coded by your revenue team. Design leadership needs a framework now.

Not every workflow needs to feel like a slot machine.

A while back I wrote about the 10 core drives of gamification and how to use them responsibly. Streaks, leaderboards, daily rewards, loot boxes, the mechanics every product reaches for when retention dips. The premise was simple: every drive is a tool, not a verdict. Same mechanic can serve a user-set goal or extract behavior the user never asked for. The system has to catch the second case.

I assumed teams would have time to figure that out.

Then 2024 happened. Then 2025. Then 2026 happened harder. Things are accelerating and we need to know how and when to push back.

The thing that quietly used to keep manipulative gamification in check wasn’t ethics. It wasn’t review boards. It wasn’t a senior engineer pushing back. It was cost of implementation. A streak system took an engineering quarter. A loot box meant designing the visual loop, building the backend, integrating monetization, edge-casing the failure paths. An achievement system needed design, content, telemetry, six months.

That cost was an unintended ethics filter. If you were going to burn a quarter of engineering on a mechanic, you had to actually believe in it. Someone, usually the engineering lead, sometimes the PM, occasionally a designer, would say “is this worth doing?” and there was at least a conversation.

AI made that conversation go away.

What changed

In 2026, “add a streak system to my app” is an afternoon of vibe-coding. Cursor or Claude Code will scaffold the component, the state management, the notification logic, the streak-broken recovery flow. shadcnblocks-shaped catalogs ship “gamification kits” with daily-login chests, mystery-box reveals, level-up confetti pre-wired. v0 will mock up the entire UI in 10 minutes. Component libraries include leaderboards as primitives. The Storybook story renders before the PM even finishes describing the spec.

This is great when you’re shipping a learning product that actually wants a streak.

It’s catastrophic when you’re shipping a marketing dashboard that “needs more engagement.”

The implementation tax used to slow bad ideas down. AI removed the tax.

The cost-of-implementation tax that used to gate manipulative mechanics is gone. The implicit conversation that used to surface concerns is gone. The natural question, “do we actually need this?”, never gets asked, because the mechanic is already in the PR by the time anyone could object.

This is the part nobody at the leadership level has caught up to yet.

What’s shipping now that wouldn’t have shipped before

I can envision a future where logging into every b2b saas product starts to look like this:

• Streak language on tools that have nothing to do with daily practice. “You’re on a 12-day streak of logging in!” on an admin panel. The mechanic burns user attention for no underlying goal.
• Daily reward chests on enterprise software. Wait, what?
• XP / level systems for completing routine onboarding tasks. “You’re now a Level 3 user!” — meaning you finished the welcome flow.
• Confetti animations on every successful task. Not on goal completions. On basic stuff.
• Public leaderboards that default to everyone in the company, surfacing rank without consent.
• “Don’t lose your progress!” modals on tools where there’s no progress to lose.
• Energy / lives gates in productivity apps — “you’ve used your 3 free actions today, upgrade or wait 24 hours.”

None of these would have passed a senior engineer’s smell test in 2022. The implementation cost was too high to ship something that obviously wasn’t worth it. In 2026 they take an afternoon, so they ship, and nobody notices because the metric of the week goes up.

I’m seeing the writing on the wall everywhere. The reason it’s not yet a Substack-level moral panic is that engagement metrics are still up and the user backlash hasn’t reached the cycle threshold. It will.

What’s at stake

Short-term engagement can become long-term damage.

The dark-pattern reckoning isn’t new. We watched it happen with cookie banners, with hidden subscription cancellations, with sneaky negative-option billing. Each cycle goes the same way: companies extract, users tolerate, then a critical mass notices, then regulators move, then the Wall Street Journal writes the piece, then companies scramble to retrofit.

The cost gets paid in four ways:

User trust. When a user realizes they were manipulated, you don’t get them back. They don’t write you an angry email — they uninstall and they tell their friends. The “I deleted the app” moment is unrecoverable, and it scales virally on every social platform. Engagement metrics catch this LATE, after the damage is done.

Brand reputation. Once your product reads as “the one that does the thing” — the streak guilt-trip, the public leaderboard shaming, the impossible-to-cancel subscription — it becomes shorthand in the industry. Recruiting talent gets harder. Press coverage tilts. Comparison reviews mention it. The cost compounds for years.

Regulatory backlash. This one’s already moving. The EU Accessibility Act enforcement landed in 2025. EU loot-box regulation is in committee for 2026. The UK ASA has flagged FOMO advertising. Several US states are watching variable-ratio mechanics under existing gambling statutes. Companies that retrofitted compliance after the fact paid 5–10× what designing it in from day one would have cost.

Talent. This is the slow one but it’s the most expensive. Senior designers and engineers have started turning down offers from companies whose products feel manipulative. The 2024–2026 generation of design leads watched the dark-pattern cycle and don’t want to be on the wrong side of the next one. If your product reads as Black Hat to the people you’d hire to fix it, you’re stuck.

Why design leadership owns this

It’s not legal’s problem yet, they’re downstream. Legal acts on regulatory pressure, and the pressure builds before the regulation does.

It’s not engineering’s problem yet, they ship what they’re asked to ship. The senior engineer push-back that used to act as a filter doesn’t fire when the implementation cost is one afternoon.

It’s not the PM’s problem yet, they’re measured on engagement metrics, and the manipulative mechanic almost always lifts the metric short-term.

Get Matthew Stephens’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

It’s design leadership’s problem because:

1. Design is almost always the only one representing the humans on the other end of the interface. Therefore, they are in the best position to say “we can’t ship this.” Engineering can refuse to build something but rarely does. PMs can de-prioritize but won’t kill a feature that lifts the number.
2. Design leaders are often the only ones whose job description includes “should we build it?” Everyone else’s job is “how do we build it?” The question of should lives at the design-leadership layer.
3. Design leaders inherit the consequences. If your team ships the manipulative mechanic and the Wall Street Journal piece runs, the design lead is the one giving the all-hands explanation.

So design leadership needs a framework. And the framework needs to be something a PM can refer to before they ask their AI to scaffold the feature.

The framework

Here’s what I’ve been working with. It’s adapted from Yu-kai Chou’s Octalysis Framework (8 core drives), extended with two of my own (Exploration & Discovery, Challenge & Competition), and codified into a 3-gate test that runs in seconds.

The 10 Core Drives

Every gamification mechanic maps to one or more of these. Some are White Hat (empowering — build user loyalty over time). Some are Black Hat (urgent — drive action now but burn out fast). Many sit in between.

White Hat — drives that empower:

1. Epic Meaning & Purpose — users feel they’re contributing to something larger
2. Development & Achievement — measurable growth, real skill
3. Creativity & Feedback — creative expression with response
4. Ownership & Possession — investment in something that’s truly theirs

Mixed Hat — drives that can empower or manipulate

1. Social Influence & Connection — peer recognition, collaboration, sometimes pressure
2. Challenge & Competition — head-to-head skill axis

Black Hat — drives that drive urgency and can burn users out:

1. Scarcity & Urgency — limited-time, exclusive, “act now”
2. Unpredictability & Curiosity — variable rewards, mystery
3. Avoidance & Loss Prevention — streaks, sunk-cost framing
4. Exploration & Discovery — curiosity-driven content reveals

The 3-gate test

Before shipping any gamification mechanic, run all three gates:

1. Is this mechanic in Black Hat territory? (drives listed above)
   ↓ if no → ship as White Hat
   ↓ if yes → continue

2. Whose goal does it serve?
   ↓ the USER's stated goal (set in onboarding / settings / context) → continue
   ↓ a company metric the user didn't ask for → REFUSE
3. Does it hand off to White Hat for retention?
   ↓ yes — Black Hat sparks action, White Hat sustains → SHIP
   ↓ no — Black Hat is the long-term driver → REFUSE (this burns users out)

Plus one always-on guardrail: the user must be able to opt out without penalty. Streaks the user can pause without losing progress. Leaderboards the user can leave. Energy gates with a free non-paid alternative. Autonomy preserved.

Walking three mechanics through the gates

Duolingo streaks. Drive 8 (Loss Prevention) — Black Hat. Whose goal? The user set “learn Spanish daily” at onboarding. Gate 2 passes. Does it hand off to White Hat? Yes — the streak gets users to drive 2 (Achievement) over time, which is where the real learning lives. Gate 3 passes. Ship. (But pause-without-loss is required, and Duolingo does this.)

Generic SaaS daily login bonus. Drive 6 + 7 — Black Hat × 2. Whose goal? The company’s DAU metric. The user never said “I want to log in daily.” Gate 2 fails. Refuse.

LinkedIn’s “you appeared in N searches this week” notification. Drive 5 (Social) tilting Black Hat. Whose goal? Ambiguous — could be a user goal (track your visibility) or a company goal (get you back into the app). Gate 2 passes weakly. Does it hand off to White Hat? Only if you click through to do something meaningful. If the notification is the goal in itself, it’s manipulation. Conditional — surface a futures-thinking pass.

This isn’t complex. It takes 30 seconds per mechanic. The point isn’t the framework’s sophistication. The point is having any framework at all, ahead of time, that a PM or designer can refer to before they ask AI to build the thing.

What to do Monday morning

If you’re a design lead at a product company, start by giving AI the whole product surface.

Upload the codebase. Upload screenshots. Upload walkthrough videos. Upload onboarding flows, notification copy, lifecycle emails, product specs, design system docs, analytics notes, support tickets, and anything else that shows how the product asks for attention.

Then paste in the audit prompt (included below).

Have AI do the first pass. Not just the inventory. The whole thing.

It should find every gamification mechanic in the product: streaks, badges, leaderboards, daily rewards, level systems, progress bars, achievements, confetti, energy gates, unlock systems, “X friends signed up today” notifications, social-proof banners, scarcity language, loss-framed modals, and any interaction designed to increase repeated use.

Then have it score each mechanic against the framework. Which core drive is it using? Is it White Hat, Black Hat, or mixed? Whose goal does it serve? Does the user have a way out? Would we ship this today if we were building from scratch?

The design leader’s job is to verify the output, not manually produce it.

Read the audit. Challenge the weak calls. Look for missed mechanics. Ask why something passed. Ask what would make it safer. Ask which mechanics should be removed, revised, or refused outright. Then make the call.

Once the audit is done, the AI will interview you.

It should ask the questions a good design ops partner would ask:

• What will your team never ship?
• Where are Black Hat mechanics allowed, if ever?
• What counts as a user-stated goal?
• What requires explicit opt-in?
• Which mechanics need escape hatches?
• Which mechanics are banned in non-gaming surfaces?
• What should happen when engagement metrics conflict with user trust?

It will use that interview to generate a one-page “what we don’t ship” standards doc. Make it concrete enough for sign-off from product, design, engineering, legal, and leadership. No vague principles. No “use good judgment.” Write the refusal lines. Write the acceptable alternatives. Write the conditions under which a mechanic can ship.

Then wire the standard into the tools.

Put it in your design system. Put it in Cursor rules. Put it in Claude Code instructions. Put it in v0 prompts, PR review templates, product spec templates, and design QA checklists. Anywhere AI can generate UI, the gamification standard needs to be in scope before the mechanic gets scaffolded.

This is also why I built this into BADS, the portable design system I’ve been using for client engagements. Layer 2 of BADS already includes a gamification taxonomy that an AI agent reads before it touches an engagement-mechanic component, with explicit “refuse outright” rules for loot boxes with money, streak-repair purchases, daily-login chests on non-gaming surfaces, public absolute-position leaderboards, system-set streaks, and paywalled essential discovered content. The framework is trigger-loaded, so the agent doesn’t pay context cost until it sees an engagement-mechanic keyword in the prompt.

So you have two options.

Do the audit yourself with AI, verify the results, generate the standards doc, get sign-off, and wire it into your tools.

Or work with me to use BADS, where this layer is already built out.

Either way, the work has to move upstream. If AI can generate manipulative mechanics in an afternoon, AI also has to be part of the system that catches them before they ship.

This isn’t about being a purist. It isn’t about leaving engagement on the table. It’s about recognizing that the cost-of-implementation tax that quietly kept manipulative gamification rare for two decades is gone, and replacing it with something deliberate before the cycle catches up to us.

Prompt to Run the 3-Gate Test

Act as a responsible gamification auditor, behavioral design reviewer, and design systems partner.

Your job is to review this product surface for gamification and engagement mechanics, identify ethical risk, recommend what should ship, change, or be removed, then help turn the findings into a standards document and tool instructions the team can adopt.

Do not ask me to manually create the audit. You do the work. My role is to verify, correct, and approve.

Use this process:

1. Inventory The Product

Review all provided materials and identify every gamification or engagement mechanic you can find.

Look for streaks, badges, leaderboards, progress bars, points, XP, levels, rewards, daily bonuses, mystery boxes, unlocks, social proof, scarcity, urgency, countdowns, confetti, achievements, challenges, referrals, status indicators, notifications, "don't lose progress" language, social comparison, ranking, public performance signals, variable rewards, energy systems, paywalls tied to discovery, or any interaction designed to increase repeated use.

Do not skip small mechanics. The cumulative effect matters.

2. Map Each Mechanic To Core Drives

For each mechanic, identify which of these core drives it uses:

* Epic Meaning & Purpose
* Development & Achievement
* Creativity & Feedback
* Ownership & Possession
* Social Influence & Connection
* Scarcity & Urgency
* Unpredictability & Curiosity
* Avoidance & Loss Prevention
* Exploration & Discovery
* Challenge & Competition

3. Classify The Risk

Classify each mechanic as:

* White Hat: empowers the user, builds skill, supports autonomy, or reinforces a goal the user chose
* Mixed: may support the user, but introduces pressure, ambiguity, social comparison, urgency, or competitive risk
* Black Hat: relies on scarcity, fear of loss, unpredictability, compulsion, shame, manipulation, or pressure

4. Run The 3-Gate Test

For every mechanic, answer:

* Is this mechanic in Black Hat territory?
* Whose goal does it serve, the user's stated goal or a company metric the user did not ask for?
* Does it hand off to a White Hat mechanic for long-term retention, or does it depend on pressure indefinitely?

5. Check The Autonomy Guardrail

For every mechanic, determine whether the user can opt out, pause, hide, mute, leave, decline, or reset the mechanic without penalty, lost progress, reduced access, or social disadvantage.

6. Deliver The Audit

Return the audit as a table with these columns:

* Mechanic
* Where It Appears
* Evidence From The Materials
* Core Drive(s)
* Classification
* User Goal Served
* Company Metric Served
* 3-Gate Result
* Autonomy Risk
* Recommendation: Ship, Revise, Remove, or Refuse
* Suggested Fix
* Confidence Level

Be direct. Do not defend a mechanic just because it improves engagement. If the mechanic primarily serves a company metric the user did not ask for, recommend removing or redesigning it. If it can be made ethical through opt-outs, user-set goals, clearer framing, accessibility improvements, or a handoff to meaningful progress, explain how.

7. Identify Behavioral Design Debt

After the table, create a prioritized list of mechanics you would not ship if this product were being built from scratch today.

Group them into:

* Refuse Outright
* Redesign Before Shipping
* Keep With Guardrails
* Safe To Ship

Explain the business, trust, accessibility, and regulatory risk of each Refuse Outright or Redesign Before Shipping item.

8. Interview Me For The Standards Doc

After delivering the audit, interview me so we can turn the findings into a standards document.

Ask me focused questions such as:

* What will this team never ship?
* Where are Black Hat mechanics allowed, if ever?
* What counts as a user-stated goal?
* What requires explicit opt-in?
* Which mechanics need pause, mute, hide, or reset controls?
* Which mechanics are banned in non-gaming surfaces?
* What should happen when engagement metrics conflict with user trust?
* Who needs to approve exceptions?
* What should AI refuse to generate automatically?

Ask one group of questions at a time. Use my answers to draft the standards document.

9. Draft The Standards Document

Create a one-page "what we don't ship" standards document for product, design, engineering, legal, and leadership sign-off.

The document should include:

* Purpose
* Scope
* Definitions
* Allowed Mechanics
* Mechanics Allowed Only With Guardrails
* Refuse Outright Mechanics
* Required Autonomy Controls
* Required Review Triggers
* Examples Of Acceptable Alternatives
* Exception Process
* Sign-Off Checklist

Do not write vague principles like "use good judgment." Write concrete rules a team can follow.

10. Create Tool Instructions

After the standards document is approved, generate implementation instructions for:

* Design system documentation
* Cursor rules
* Claude Code instructions
* v0 prompts
* PR review templates
* Product spec templates
* Design QA checklists

The instructions should tell AI and humans what to refuse, what to flag, what to ask before generating, and what safe alternatives to suggest.

11. Final Output

When complete, provide:

* The audit
* The behavioral design debt list
* The standards document
* The sign-off checklist
* The tool-specific implementation instructions

Your goal is to do the full first pass so the design leader only has to verify, correct, and approve.

People stick around when the game feels good, not when it’s a chore. Now they also stick around when they trust you. The thing AI made cheap is the thing that makes them not trust you. Build the framework. Ship the audit. Talk about it with your team.

If you want help adapting it to your team's product, my website is matthewstephens.com.

Like and follow if this resonated. The original 10 Core Drives post that this builds on is here.