Loading page...
Loading page...
Here's a pattern I keep seeing: a team identifies a problem, spins up a project, designs screens, builds a workflow engine, ships a UI. Three months later they learn the workflow was wrong, the requirements shifted, and half the screens never get used.
The product worked. They just built the wrong one.
We default to building products because that's what we know. Identify a need, design an interface, code the logic, ship it. The entire muscle memory of software development is oriented around producing artifacts: screens, buttons, dashboards, deterministic pipelines.
But most product risk doesn't live in execution. It lives in commitment. You're betting weeks or months of engineering on assumptions about what users need, how they'll use it, and what the workflow should look like. Every screen you design is a guess. Every hardcoded workflow is a prediction about a future you haven't observed yet.
The cost of being right is a product. The cost of being wrong is also a product, just one nobody uses.
Meanwhile, the industry response to every problem is now "build an AI agent." Customer support? Agent. Internal ops? Agent. Sales enablement? Agent.
The result is predictable. BCG found that 14% of workers already report "AI brain fry," with mental fog, slower decisions, and active intent to leave. Productivity actually drops after workers adopt more than three AI tools. And 71% of office workers say new tools appear faster than they can learn them.
Here's the part people forget: every new product, every new agent, every new interface is something a user has to learn. That's not free. Screen layouts, navigation patterns, where the settings live, what the buttons mean. Multiply that across a dozen tools and you've burned hours of productivity just on orientation. The UI that was supposed to save time becomes the thing that costs it.
The answer isn't building a better agent. It's not building one at all.
Skills are composable workflows written in plain language. An agent reads them and knows how to do a thing: write a blog post, generate a quote, review a PR, run a deployment. They cost minutes to create because you write them with an agent. If they're wrong, you rewrite them in minutes. If nobody uses one, you delete the file.
MCP servers are the plumbing. They give an agent access to external systems: your database, Slack, GitHub, Salesforce, whatever. One standardized interface that any agent can call.
Together, a skill that calls MCP tools IS the product. You just didn't build a UI for it. You didn't force anyone to learn a new interface. The user stays in their own agent, their own environment, their own flow. No context switching. No onboarding. No "where do I click."
This isn't a minor efficiency gain. It's a fundamentally different product development posture. Instead of shipping an artifact and hoping it matches reality, you ship a capability and let usage tell you what it should become.
Requirements always shift. That's not a risk to manage. It's a constant.
Skills cost minutes. UIs cost weeks. When it's that cheap to try something, you can afford to go build, learn, and iterate instead of designing everything upfront. Place ten small bets instead of one big one. Learn from what sticks. Kill what doesn't.
The teams that win aren't the ones that predicted the future correctly. They're the ones that made it cheap to be wrong.
Look at your next three planned features. How many of them could be validated as a skill first? How many of those UIs are you building because users actually asked for a screen, versus because building a screen is just what you do?
Most things never need the UI.