Perri: Too many features shipped, and now the product feels worse

Here is something worth sitting with for a minute. Your team ships more than ever. The product still feels worse. And now AI agents are about to start building on top of the mess you already have. Two things are colliding, and both land on your desk. Let me catch you up.

The deep cut

• Speed without a system is a bill, not a win. Twenty features shipped and the product feels worse is the build trap.
• Agents fail on when-to-use, not what. One DevOps lead found guardrails written as plain text fix the drift a component library cannot.
• A number is not an explanation. Miscalibrated confidence scores pushed misuse of AI output past 41% when the system was confidently wrong.

The debt nobody put on the balance sheet

A design team has a great quarter. Twenty features out the door, three journeys redesigned, stakeholders happy. Then the product feels heavier. Navigation gets clumsy. Patterns stop matching. Customers need more hand-holding. Nothing is broken, but everything is worse. That is experience debt, the cost of hundreds of reasonable-looking shortcuts that compound.

Melissa Perri named the trap behind it in her book: teams that measure success by output shipped, not outcomes reached. The tell is simple. Every new feature adds another exception. Different parts of the product feel unrelated. Simple changes suddenly need five teams and three legacy systems. If that sounds like your last three sprints, you are not shipping fast. You are borrowing.

A design system is not a defense

Here is the part leaders get wrong. You have a component library, so you assume consistency is handled. It is not. A design system keeps your buttons and type coherent. It cannot decide whether a feature should exist, whether two journeys should behave the same way, or whether shipping something creates real value. You can have a beautifully governed library sitting inside a badly fragmented product.

The fix is not a redesign. It is a change in how decisions get made. Validate the problem before you build the screen. Agree on the experience outcome before you write the backlog. Ask one blunt question at every review: am I solving this screen, or improving the experience? Those are cheap words and expensive habits. Start the habit now, before agents make the fragmentation faster.

The repository agents cannot read

Now the second collision. Agents are starting to generate UI, and a study of 20 design systems found only two had adopted Figma's Code Connect, the tool that maps components to real code. When your system is scattered across Figma, code, and Storybook with nothing connected, the agent guesses. Then it draws its own button instead of yours.

One enterprise DevOps lead treated this head-on and made AI-readability a formal requirement, equal to accessibility. Docs got rewritten for retrieval: plain-language component summaries, usage guidance, working code, guardrails written as text. The finding that matters for your roadmap: agents rarely fail on what a component is. They fail on when to use this one versus that one. That decision lives in your team's heads, undocumented. Get it out.

Explain the decision, not the model

The same lesson runs through AI features themselves. When a system returns an answer and the person cannot tell whether to trust it, the instinct is to expose more: confidence scores, logs, a debug panel. It backfires. Research showed a confidence score of 0.87 tells a user nothing they can act on. It just hands them a number to over-trust.

What works is layering. Show the result plainly. Add one short reason next to it, why this, based on what. Keep the deep evidence one click away for the few who need it. Match the depth to the stakes: a writing suggestion needs a one-liner, a refund or a database migration needs the full trail. This is the same discipline the Claude workflow demands of documentation. Agents need to know why a rule exists, not just what it says. Write the reasoning down, or watch the drift return.

Three questions for your team

• Which of the seven experience-debt signs are we already living with, and which one are we going to stop feeding this quarter?
• If an agent read our design system today, could it tell when to use one component over another, or would it guess?
• For our highest-stakes AI action, does the interface show a reason a user can act on, or just a score they will over-trust?