I've sat through a lot of sprint demos this year. And I've noticed something.

The demos got better. The products didn't.

Every two weeks there's a new screen, a new toggle, a new button with a little sparkle icon. Leadership claps. Then a customer opens the product and can't do the one thing they bought it for any faster than last quarter.

I wanted a feature in my demo talk track, so I vibe-coded a mock dashboard that sold the value prop. Real customer conversations then went somewhere else entirely. The mock is still in production. It means nothing, it only raises distracting questions, and it got there because the idea hadn't matured and the upstream plumbing wasn't in place.

In August I wrote about governance theater, my take on Bruce Schneier's "security theater": AI governance that reviews the code but never changes the decision. It gives the look of control without the substance.

This is the sequel. I call it Feature Theater. It means shipping work that looks like progress, at a speed that keeps anyone from asking whether it should exist.

Governance theater performs control. Feature Theater performs value. Both play to people who read dashboards rather than use products, and both win for the same reason: the performance is easier to measure than the result.

Building got cheap. Deciding didn't.

Two years ago, a feature cost a team a week or two. That was annoying, but the cost did something useful. It forced a conversation. Is this worth two weeks? What are we not doing instead? The price of building acted as a filter.

AI removed the filter. Now a first version costs an afternoon and a prompt. So we build all of them.

But the cost of deciding didn't drop. Understanding a customer, choosing between two good ideas, telling a VP "not this quarter": none of that got cheaper. It just got skipped, because skipping it no longer slows anything down.

So we get more output with the same amount of judgment, spread thinner. That's what mediocrity at scale looks like. Not bad work. Average work, everywhere, all at once.

Why speed gets rewarded even when it produces garbage

Nobody sets out to ship junk.

Velocity is visible: a demo, a changelog, a slide. Quality mostly shows up as an absence: the ticket never filed, the customer who didn't churn. You can't screenshot an absence.

Ship five shallow features and you have five things to point at. Make one workflow actually work and you have one, and it looks smaller.

Speed is also cheap to claim and expensive to disprove. Proving a feature is mediocre takes months of usage data. The reward comes now. The bill comes later, and it goes to someone else.

That's speed-before-sense economics. It's not a character flaw. It's a pricing error. We pay for motion and never invoice for direction.

The feature treadmill: "add AI" as the default

Then there's the treadmill.

Somewhere in the last two years, "add AI" stopped being a product decision and became a default setting. A note-taking app gets a chatbot. A form gets a "generate with AI" button. A settings page gets a summary of your settings.

Some are actually useful. Many exist because a competitor added one, or the roadmap needed an AI line item.

The question "does this user need AI here?" quietly turned into "where else can we put AI?" Those are very different questions, and they produce very different products.

The treadmill keeps moving because stepping off looks like falling behind. Nobody wants to explain why the competitor shipped twelve AI features and we shipped two, even if our two are the ones customers use.

The board wants a number

Which brings us to the board.

Boards and investors are under real pressure to show an AI story. Nobody wants to fund the next company that missed mobile. But "show me AI progress" has to become a number, and the easiest numbers are adoption metrics: features with AI, engineers using copilots, AI interactions per user, share of code written by AI.

Goodhart's Law, in its popular form: when a measure becomes a target, it stops being a good measure.

Make AI adoption a KPI and adoption will go up.

That's what you asked for. AI gets bolted on. Usage gets nudged with pop-ups and default-on toggles. The number goes up and to the right.

What it doesn't tell you is whether anyone's work got better. It was designed to be reported.

I've sat with leadership teams who kept getting the same question: what's your AI strategy? The reliable answer was "our people are all using AI." That's an adoption metric. When someone asked where it added real value, the answer usually landed on faster summaries and reports. Useful, maybe. Strategy, no.

Who mediocrity pays

Mediocre AI products are often bad for customers and often fine for platforms. That took me a while to see clearly.

Think about how AI is priced. Usage-based billing charges for tokens whether the answer was useful or not. A wrong answer bills the same as a right one, and a rambling one bills more than a short, correct one. Seat licenses renew on "everyone's using it," not "everyone's better at their job."

None of that requires bad intent. Flat-rate products feel the opposite pressure, but wherever the dashboard counts engagement, more interactions is the business, and quality per interaction is a cost center.

Consumer products work the same way. An assistant that needs three follow-ups to get it right generates three times the engagement. On the platform's dashboard, "good enough to keep using, never good enough to finish the job" can look identical to success.

That's why I say the industry's real product is mediocrity at scale. Not because anyone designed it that way. Because mediocrity is what much of the incentive structure pays for.

Announced vs. actually works

Keynote after keynote this year promised agents that run your business and search that just answers. Some of that is real. A lot of it is a demo that works on stage.

Gartner put a forecast on it back in June 2025. It predicted that over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value, or inadequate risk controls. In the same release, it called out "agent washing," rebranding existing assistants, RPA, and chatbots as agents, and estimated that only about 130 of the thousands of agentic AI vendors are real.

The consumer version is even more visible. In January 2026, a Guardian investigation found that Google's AI Overviews were serving misleading health information at the top of search results. One example the experts called "dangerous" and "alarming" was raw liver function test ranges, given without the context that could tell someone with serious liver disease their results weren't normal. Google removed AI Overviews for some of the flagged liver test queries. The Guardian reported that slight rewordings of the same question could still bring up AI summaries. Google said its clinicians found that in many instances the information was not inaccurate.

I'm not citing this to pile on Google. It has one of the most capable AI teams in the world, and that's the point. Even with that talent, a feature can ship at massive scale, sit in the most visible spot on the page, and still put misleading health information in front of people, at the top of the page.

A small October 2025 Nielsen Norman Group study of Google's AI Mode (7 participants) found something similar: people mostly liked it, but in one session it cited a research paper and author that didn't exist.

Announced. Shipped. Visible. Not yet working as announced. That's Feature Theater at planetary scale.

It feels like speed

The most dangerous thing about Feature Theater is that it feels great from the inside.

In mid-2025, METR ran a controlled study with experienced open-source developers working in mature codebases they knew well. With AI tools allowed, their tasks took 19% longer. Before the study they expected a 24% speedup. Afterward, they still believed they'd been about 20% faster.

That was early-2025 tooling. METR itself now calls those results out of date. It believes developers are likely faster today, but says its newer data is too skewed to say by how much. I'm not quoting the original study to say AI makes you slow. I'm quoting it for the gap between what people felt and what happened. That gap is the whole stage.

Google's 2025 DORA report (nearly 5,000 technology professionals) shows the same tension from another angle. 90% of respondents use AI at work, and more than 80% say it has made them more productive. Yet 30% report little or no trust in AI-generated output.

Nearly everyone uses it, and almost a third don't trust what it produces. That gap is what I call the verification tax. The time you saved writing gets re-spent reading, checking, and auditing. Sometimes you break even. Sometimes you don't. Few teams I've worked with measure which.

And the checking matters. Veracode's 2026 GenAI Code Security Report found that in its benchmark tests roughly 44% of AI code generation tasks introduced a risky security vulnerability, with an average security pass rate of 56%, barely changed from its first report. Syntax is basically solved. Security isn't. Veracode's fall 2026 update cut that vulnerability rate to about 38%, mostly on one easier class, cross-site scripting. That's still roughly four in ten tasks.

"It compiles and the demo works" is a very low bar. Feature Theater never asks for more.

The loop nobody closes

Now put it together.

We ship an AI feature. We measure that it shipped. We measure that people clicked it. We report adoption. We get credit. We ship the next one.

What most teams I've worked with rarely measure is whether it improved the outcome it was meant to improve. Did customers resolve issues faster? Did errors go down? Did it cause new problems somewhere else?

Without that, there's no signal to stop. A feature that made things slightly worse looks exactly like one that made them slightly better. So the shipping continues, and the only feedback is applause.

That's how theater sustains itself. Not through deception. Through a feedback loop with a missing wire.

The engineers who can see it

The people trapped in this are mostly not the villains.

Many of the best engineers I know see Feature Theater clearly. They know the AI summary panel won't get used. They know the agent demo only works on the happy path. They know when a giant generated diff got fifteen minutes of review.

And they ship it anyway. Not because they don't care, but because the system makes caring expensive.

Push back, and you're "slowing the team down." Take the extra week to make it right, and your velocity drops. Ship it, and the problem rarely traces back to you, because the outcome rarely gets measured. The career-safe move is to ship.

That's the sad part of mediocrity at scale. It doesn't need bad engineers. It just needs a system where good judgment is a liability.

I've watched strong developers accept Cursor or Claude Code's answer as the right one, even when it wasn't right for their company or project. Crowdsourced popularity travels through AI faster than enterprise discipline. You can have good reasons for sticking with an older library. I've seen teams burn tokens and hours refactoring onto the hot new algorithm, only to throw the work away when institutional knowledge finally shows up. That isn't a coding failure. It's a process failure that happened before anyone wrote a line.

How to spot Feature Theater on your team

A few signs I've seen. I've been guilty of a few myself:

  1. Nobody can say who asked for it. The feature exists because it was easy, not because a customer, a metric, or a strategy pointed at it.
  2. The spec was written after the code. Or by the same model that wrote the code. Or never.
  3. The demo is the deliverable. If a feature only has to survive a ten-minute screen share, it'll be built to survive a ten-minute screen share.
  4. The KPI is adoption, not outcome. You know how many people clicked the AI button. You don't know if their work got better.
  5. Release notes are getting longer, but support tickets aren't getting fewer.
  6. Nobody has removed anything in six months. Theater only adds scenes. Good products also cut.
  7. Review is a rubber stamp. The diff is huge, the reviewer has fifteen minutes, and "LGTM" is the only realistic answer.

If three or more sound familiar, you're not moving fast. You're performing.

"Should we ship?" not just "Can we?"

My suggestion: build slower, and ship less, of what matters.

I know how that sounds in 2026. But with AI, the answer to "can we build it?" is almost always yes. The only question that still filters anything is "should we?" That question needs time, context, and someone willing to say no. A feature has to earn its place with an outcome, not a demo.

My own team isn't immune, so we added a simple rule. Nothing gets coded until it has a written spec and the concerns that spec raises are resolved. Then we decide. Spec-before-code helps catch compliance, security, and compatibility regressions. No developer can hold every rule in their head, or every reason why a house preference beats the popular recommendation from the web. A good, aligned spec helps surface those problems before anybody commits code that causes drift.

A few habits that help, whatever tools you use:

  • Ask "what would we have to believe for this to matter?" before "how long will it take?" The second question has stopped being useful.

  • Write the why down and keep it next to the code. Otherwise the next AI-generated change can quietly undo it.

  • Measure one outcome per feature that you can't fake in a demo. Time to value. Tickets resolved. Steps removed. If you can't name one, that's your answer.

  • Give reviewers small diffs and real time. If your review process can't say no, it isn't a review. It's an audience.

  • Celebrate deletions. Seriously. Put them in the release notes.

  • Report the verification tax honestly. Say, four hours saved writing minus three hours checking is still a win. Just a smaller one.

The point

AI is a gift. I use it every day, and I build on it. But it hands us a choice that scarcity used to make for us: what's worth building?

Now we have to make it on purpose. Teams that do will build fewer things, and better ones. Teams that don't will put on a great show for a while.

The audience always leaves eventually. The question is whether you were building something they'd come back for.

My question: what's one feature your team shipped this year that nobody would notice if you deleted it tomorrow?

Honest answers welcome. I'll go first in the comments.

Sources

  • Veracode, "2026 GenAI Code Security Report" (blog summary Jul 28 2026): ~44% of AI code generation tasks introduced a risky vulnerability; 56% average security pass rate. https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk/ · Report: https://www.veracode.com/resources/analyst-reports/2026-genai-code-security-report/
  • Veracode, "Fall 2026 GenAI Code Security Update" (Oct 29 2026): pass rate 56% → 62%, vulnerability rate ~44% → ~38%. https://www.veracode.com/blog/fall-2026-genai-code-security/
  • DORA / Google Cloud, "2025 State of AI-assisted Software Development": ~5,000 respondents; 90% use AI at work; >80% report higher productivity; 30% trust AI output "a little" (23%) or "not at all" (7%). https://dora.dev/research/2025/dora-report/ · Google blog (trust split): https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/ · https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
  • METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," Jul 10 2025. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ (arXiv 2507.09089). Follow-up, "We are Changing our Developer Productivity Experiment Design," Feb 24 2026: https://metr.org/blog/2026-02-24-uplift-update/
  • Gartner press release, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," Jun 25 2025 (URL checked Nov 1 2026; includes "agent washing" and the ~130 real vendors estimate). https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
  • The Guardian, "'Dangerous and alarming': Google removes some of its AI summaries after users' health put at risk," Jan 11 2026. https://www.theguardian.com/technology/2026/jan/11/google-ai-overviews-health-guardian-investigation · Original investigation, Jan 2 2026: https://www.theguardian.com/technology/2026/jan/02/google-ai-overviews-risk-harm-misleading-health-information
  • Nielsen Norman Group, "Google AI Mode: Powerful Search, Poor Usability," Oct 17 2025 (7-participant qualitative study). https://www.nngroup.com/articles/google-ai-mode/
  • Previous essay in this series: "Why Your Company's AI Strategy Is Security Theater," QCoda blog, Aug 17 2026. https://qcoda.com/blog/governance-theater

Yes, AI helped fix typos and grammar. No, it did not write the thinking. Hero image generated with Leonardo.ai.