For decades, the way we interact with software has followed the same pattern: someone builds an interface, and we learn to use it. We click buttons, navigate menus, fill out forms. Every new tool means a new UI to master, a new set of conventions to internalize, a new cognitive load to carry.
That era is ending. Not with a bang, but with a quiet shift that engineers have actually been rehearsing for years.
Engineers Already Know This Pattern
If you’ve spent any serious time writing code, you’ve spent serious time shaping your tooling. Emacs users have spent decades turning their editor into an operating system: email, terminal, file management, version control, database queries, all without leaving a single window. IntelliJ users know the same instinct: why open a separate terminal when the IDE has one built in? Why switch to a browser to read docs when you can pull them inline? VS Code users install dozens of extensions to compile, debug, inspect logs, query databases, run containers, all from one tool.
The pattern is always the same: collapse everything into one environment and interact with it through a single, familiar interface.
The difference is that this used to require deep configuration knowledge. You had to know which plugin to install, how to configure it, what keybindings to set. It was powerful, but it was an engineer’s game.
MCP Makes the IDE Pattern Universal
The Model Context Protocol (MCP) changes who can play this game. MCP is an open standard that lets AI assistants (Claude, ChatGPT, Perplexity, and others) connect to external tools and services through a uniform interface. Your AI assistant becomes the IDE. The MCP servers are the plugins. And the “configuration” is just natural language.
Instead of learning a platform’s UI, you describe what you want. Instead of navigating five different dashboards to cross-reference data, you ask a single question and the AI orchestrates the calls across all of them. Instead of context-switching between tabs, apps, and browser windows, you stay in one conversation.
This is not theoretical. Today, you can connect Claude to your calendar, your database, your Stripe account, your project management tool, your CRM etc and interact with all of them through plain English. Tomorrow, you’ll do it through voice while walking to your car.
What This Means for Product Builders
If you’re building a SaaS product today, this should reshape how you think about your roadmap. The traditional playbook says: build a great UI, make it intuitive, reduce friction, optimise onboarding. And that still matters … for now. But the competitive moat is shifting.
The question is no longer just “How intuitive is your interface?” but “How complete is your MCP server?”
A product with a mediocre UI but a comprehensive, well-designed MCP server will increasingly beat a product with a beautiful UI but no programmatic access. Because the user isn’t interacting with your UI anymore; they’re interacting with their AI, and their AI is interacting with your API.
This doesn’t mean UIs disappear overnight. There’s enormous inertia. People are comfortable with visual interfaces. Complex data visualisation still benefits from graphical rendering. And there will always be cases where seeing a dashboard is faster than describing what you want to see. But the trajectory is clear: the UI becomes optional, and the tool layer becomes essential.
The Inertia Is Real, but the Direction Is Not
We’ve seen this pattern before. Command-line tools didn’t disappear when GUIs arrived; but GUIs became the default for most people. Now the pendulum swings again, except the “command line” is natural language and the “power user” is everyone.
People will keep using UIs for a while. Some will prefer them permanently, just as some developers still prefer GUIs over terminal-based workflows. But the marginal user, the one choosing between your product and a competitor’s, will increasingly choose based on how well your product integrates into their AI-powered workflow, not how pretty your settings page is.
What You Should Be Doing Now
If you’re building a product:
- Invest in your API and MCP server as seriously as your UI. They’re not secondary interfaces, they’re becoming the primary ones.
- Design your tool surface for completeness. Every action a user can take in your UI should be available through your MCP tools. If it’s not, that’s a gap your competitors will fill.
- Think in terms of composability. Your product is no longer a destination. It’s a capability that gets woven into someone’s AI-orchestrated workflow alongside a dozen other tools.
- Don’t neglect the UI yet. But recognise that the ROI of UI polish is declining while the ROI of tool completeness is rising.
The Engineer’s Instinct Was Right All Along
Engineers who spent years perfecting their Emacs configs or their IntelliJ setups weren’t being precious about tooling. They were optimising for something real: the ability to do everything from one place, through one interface, without context-switching.
MCP democratises that instinct. Your Claude, your ChatGPT, your Perplexity: that’s your IDE now. And every product that wants to stay relevant needs to ship the plugins for it.
The future of software interaction isn’t a better button. It’s no button at all.







