AI in Design Isn't Just About Speed. It's About What You Can Afford to Discard.
— Or, why the conversation about cutting features finally matches the conversation about adding them.
The story about AI in design has mostly been a story about speed. Prototypes in thirty seconds. Variations in minutes. Iteration loops that used to span sprints now closing in afternoons. All true. All worth noticing.
But speed is the surface. Underneath is a quieter shift that matters more, and almost nobody is naming it: the threshold for removing something is finally starting to match the threshold for adding it.
For most of my career, those two thresholds have been wildly asymmetric. Adding a feature had a clear champion, a clear pitch, a roadmap slot, and someone willing to spend political capital making the case. Removing one had none of that. Removal needed someone to start the conversation — and behind the conversation sat the real cost: the design work to figure out what changes, the development effort to deprecate it cleanly, the QA, the comms to whoever was using it, however few. Someone had to argue that the feature's maintenance burden plus its underuse plus the real estate it occupied outweighed all of that. That math almost never penciled out for any single feature. So features accreted. Not through bad decisions. Through tolerable ones nobody had reason to revisit.
That asymmetry is the quiet engine behind a lot of what we call legacy product. It's not villainy or strategic mistake. It's a structural mismatch between how easily things get in and how hard they are to get out.
Cheap iteration changes that. Not because designers got more decisive, or because organizations got more disciplined, but because the conversation about removing something is finally as cheap as the act of removing it. And that's the shift worth paying attention to.
The Customization That Nobody Was Defending
At The Motley Fool, more than a decade ago now, we launched a new product with a customizable home page. Modular components users could rearrange to suit their preferences. Place the cards they cared about up top. Move the secondary stuff down. Hide what they didn't want. The team had built something genuinely cool, and the engineering work was impressive. I liked it. Everyone did.
But I did have the gnawing design question: wait — if we think users would want this a different way, should we set that as the better default?
When I dug, the answer wasn't "users desperately want an alternative” nor was it “users want to customize this." The answer was quieter. Users weren't showing strong conviction in either direction. Most of them accepted what we provided however we provided it. The customization layer was an answer to a question most users hadn't asked.
The feature wasn't wrong. It just answered a question that turned out not to be the urgent one. Customization for its own sake, built before anyone beyond power-users established that customization was the unmet need.
What happened next is the part worth paying attention to.
Nothing.
The feature shipped. It got highlighted in launch communications. It earned its real estate on the page. And then, gradually, the data showed what the early signals had hinted at — most users weren't using it. A few were. Enough that turning it off would have meant breaking something the power-users still valued, however few. Not enough to justify the case for keeping it as a strategic differentiator.
Internally, nobody was defending it. Nobody was fighting for it. It just existed, costing a little. The maintenance burden was tolerable. The real estate it took was tolerable. The fact that it had been pitched as a feature was tolerable, in that nobody pointed at it as a failure.
But removing it would have meant starting the conversation. Design work to figure out what the home page looked like without it. Dev work to deprecate cleanly. QA. Comms to the small group who had customized. Someone — me, presumably, or someone like me — would have had to make the case that the cost of all of that was less than the cost of leaving it alone. That math didn't pencil out for any single feature. So it stayed. Not because it earned its place. Because removing it would have cost more than ignoring it.
That's the era this article is naming. The expensive era. Not because building things was expensive — it was, but everyone talks about that. The expensive part was unbuilding. The asymmetry between how easy it was to add something and how hard it was to take something back ran most of the products I worked on for the better part of a decade.
The modular home page is one example. Every designer reading this has their own.
The Cost Collapsed. All of It.
The story everyone tells about AI in design is a story about speed — the prototype that used to take days now arrives in thirty seconds. That's true, and it's worth noticing, but it undersells what's actually happening.
It isn't just making that got faster. It's the entire stack behind a design decision.
Consider the chain that used to sit behind any meaningful change: the design work to figure out what the change is. The development effort to build it. The QA pass. The communications, internal and external. The roadmap negotiation. The political work of getting it onto someone's plate. Each of those is its own gate. Each of those used to cost real time, real money, and real attention.
What's collapsing isn't one of those costs. It's the cumulative weight of all of them.
A hypothesis you want to test used to require committing to the full chain before you could find out whether the hypothesis was any good. You had to spend the design cost, the dev cost, the QA cost, the political cost — and then you could see if the thing was right. The order was: invest, then learn.
The new order is: learn, then invest. Or, sometimes: learn, then learn again, then maybe invest, then learn that the answer changed.
That's not a faster version of the old workflow. It's a different relationship between thinking and committing. Commitments used to be the price of admission for finding anything out. Now they're optional. You can hold a hypothesis loosely, test it cheaply, and revise it without anyone needing to spend political capital defending the prior version.
Which means the asymmetry that ran most of design for the past decade — cheap to add, expensive to remove — finally has a counter-pressure. Not because organizations got more disciplined about removal. Because the full cost of considering removal, examining the alternative, and acting on it has dropped enough that it's no longer automatically more expensive than ignoring the question.
That's the shift. Not speed alone. The collapse of the cumulative cost stack that made design decisions sticky in the first place.
Built. Watched. Removed.
A few weeks ago, on a personal project of mine called Reawarding, I had an idea for the ranking page. Add a stats block at the top — quick numbers giving users a snapshot of where things stood before they scrolled into the rankings themselves. Seemed useful. Gave context. Felt like the kind of feature a polished product would have.
I built it. Shipped it. Looked at it live.
And almost immediately, the issues were obvious. The block took up real estate above the rankings, which were the actual reason anyone would visit the page. It pulled focus from the content users would want. For a non-power-user landing on the page for the first time, the mostly empty stats added complexity before it added value. The thing I'd thought would feel like polish actually felt like noise.
So I removed it.
Total elapsed time from "this seems like a good idea" to "this is gone" — short. Short enough that I could see the idea fail before I'd invested enough in it to want it to succeed.
Now, this is a personal project, so the comparison is unfair in the obvious ways. There's no team. There's no roadmap. There are no vocal users, however few. It's just me, a hypothesis, and a deploy button.
But here's the thing...
Even with all those advantages, in the old version of this work — even on a personal project — the cost of the experiment would have looked different. Building the stats block from scratch, querying the data, designing the layout, testing it, deploying it — that's hours of work, minimum, before you can see whether the idea is any good. And once you've spent the hours, there's a quiet pull to keep the thing, because you built it. The sunk cost isn't political; it's emotional. You felt each step of doing the work. You want it to have been worth it.
What changed isn't just that the build was fast. What changed is that the build was fast enough that I never accumulated the emotional sunk cost. The hours weren't there. The attachment didn't have time to set. I could see it wasn't right, and remove it without it feeling like a loss.
Scale that up. Imagine that modular home page from forever ago, but with the cost stack collapsed at every step — the building, the testing, the analyzing, the considering-removal, the executing-removal.
In the old workflow, by the time anyone could see the feature in action, the team had already spent weeks getting there. The pitch had been made. The anticipation had been sold. Design reviews had landed. Dev cycles had been spent. The wow was on the calendar. By the time the thing existed in a form anyone could evaluate, raising the question "but why?" wasn't questioning the feature — it was questioning everyone's buildup, every prior approval, every milestone that had moved it forward. That's why the question rarely got asked, even by people who quietly suspected it should be.
The expensive part wasn't disagreement. It was late evaluation. The workflow guaranteed that the cost of seeing whether something was right showed up after almost everyone in the room had already committed to it being right.
Now imagine that same project, but the conversation about whether to keep the customization didn't require a meeting, because the evidence was a deploy and a week of data. Imagine evaluation arriving before anyone had performed conviction. Imagine asking "but why?" when the cost of the question was a week, not a quarter.
That's the world being built right now. Not just faster making. Earlier evaluation — and therefore cheaper questioning. The cost of the doubt finally matches the cost of the doubt being warranted.
What the Designer's Job Becomes
If the cost of evaluation has collapsed, and if removal is finally as cheap as addition, the designer's job changes shape.
Not in the "AI is replacing designers" way the headlines like to frame it. In a quieter, more interesting way: the moment where design judgment matters most is moving.
It used to live at the start. Before anything got built, you wanted a designer in the room — because once the build started, course-correcting was expensive, and reversing was nearly impossible. The judgment had to be front-loaded. Designers became gatekeepers because gatekeeping was the only place where the judgment could affordably operate.
That role made sense in the old cost stack. It doesn't make as much sense now. When evaluation is cheap and removal is cheap, gatekeeping at the start is no longer the only place judgment can live. You can let things get tried. You can let users show you what works. You can hold a hypothesis loosely, watch it for a week, and decide.
Which means the designer's most valuable work is shifting downstream. Not into the prototyping seat — AI is handling more and more of that. Not into the stakeholder seat — that's not the work either. Into the seat where someone is watching the live thing and asking "is this still the right answer?"
That's a different muscle than gatekeeping. Gatekeeping is about holding the line. This is about reading the line in motion. It's the judgment to notice when something that was right last quarter is wrong this one. The judgment to see polish that's become noise. The judgment to say "yes, we built that, and now we should take it down," without it being a referendum on anyone's prior commitments.
The designers who'll matter most in this era aren't the ones who can prototype faster. AI can do that. They're the ones who can look at something live, working, in front of real users, and ask the question that used to be too expensive to ask: but is this still right?
That's the job becoming visible. Continuous evaluation. Continuous discard. Continuous rearrangement of what the product is, based on what users keep showing rather than what anyone once believed.
The expensive era of design rewarded conviction. The cheap era will reward something quieter — attention.