The Case for Leaving It Alone: Why Stable Software Beats Constant Reinvention
Last week, Slack changed the Activity screen. The data I need is still there - technically nothing is broken. But I opened it and felt that familiar unease: something moved, and I didn't ask for it. I wasn't in control. Meanwhile, Jira has been reshuffling things throughout the entire year, one small change at a time, each one just disorienting enough to pull me out of my flow.
Neither change was catastrophic. That's not the point. The point is what these constant micro-disruptions add up to, and why this matters more than ever as AI accelerates how fast we build software.
The muscle memory tax
When you use a product every day, something remarkable happens: you stop thinking about it. Your fingers know where the buttons are. Your eyes scan the right spot for the information you need. You develop shortcuts, habits, workflows. You become fast - not because the tool is fast, but because you are.
Every redesign resets that clock. Not because the new design is bad, but because it's different. The cost isn't measured in pixels moved; it's measured in thousands of micro-interruptions across millions of users, each one pulling someone out of the actual work they sat down to do.
There's an unspoken arrogance in frequent redesigns: the assumption that the design team's newest idea is worth more than the accumulated efficiency of an entire user base. Sometimes it is. Usually it isn't.
"Natural pace" isn't a bug
Companies often treat stability as stagnation. Investors want to see momentum. Product teams want to ship. Designers want to design. The entire incentive structure of a software company pushes towards change for the sake of change.
But what if the natural pace of a mature product - the pace where changes are infrequent, deliberate, and genuinely necessary - is actually the right pace? What if the best thing a product team can do, once they've built something that works, is resist the urge to keep touching it?
The most beloved tools in the history of software - Excel Google Sheets, Vim, IntelliJ - earned that status partly because they respected their users' investment. They evolved, but slowly. They added, but rarely rearranged. They understood that predictability is a feature.
AI acceleration
This same principle should be front of mind as we bring AI into software development.
The current narrative is breathtaking: AI can write code faster, generate UIs in seconds, refactor entire codebases overnight. And it can. But speed of creation is not the same as speed of value delivery. If anything, AI makes it easier than ever to fall into the trap of constant reinvention.
When generating a new feature or interface takes thirty minutes instead of three weeks, the temptation to regenerate, redesign, and re-ship becomes almost irresistible. The cost of change drops to near zero - for the developer. For the user, the cost stays exactly the same.
AI-assisted development needs a philosophy of restraint to go with its philosophy of speed. The question should never be "can we rebuild this?" It should always be "should we?"
What this means in practice
If you're building software with AI, consider a few principles:
Optimise for user learning curves, not development cycles. The fact that you can ship a new interface every sprint doesn't mean you should. Every change your users have to absorb is a withdrawal from their trust and patience.
Use AI to improve what's invisible. Performance, reliability, error handling, accessibility - these are the places where AI-driven iteration creates pure upside. Better load times don't require anyone to relearn anything.
Treat your UI as a contract. When someone builds a workflow around your product, they've made an investment. Honour it. Change the contract only when the new terms are clearly and significantly better - not just different.
Version your interfaces, not just your APIs. If you must make major changes, let users opt in. Give them time. Respect the transition. AI makes it trivially easy to maintain multiple interface versions - use that power.
The deeper point
We are entering an era where the cost of building is collapsing. AI will make it cheap to create, iterate, and reinvent software at a pace we've never seen. But the cost of learning - the human cost of adapting to new interfaces, new workflows, new mental models - hasn't changed at all. If anything, as software becomes more central to every job, the cost of disruption is going up.
The companies that win the AI era won't be the ones that ship the most changes. They'll be the ones that understand when to stop changing. The ones that use AI's power not to move fast and break things, but to move thoughtfully and fix things - quietly, invisibly, without making anyone relearn their job.
Sometimes the most valuable thing a product team can do is nothing at all.
What's your experience? Have constant UI changes in tools you rely on impacted your productivity? I'd love to hear how others are thinking about this tension between innovation and stability.