Over the past year the products I work in have grown an assistant. Not a feature — an assistant: a box you write to, which then does the work the menus used to do. It leaves a question I have not been able to put down. If the way you use a product is to describe what you want, what is left of the product?
What actually changed?
Not "AI was added". Design tools have shipped machine learning for a decade — content-aware fill, background removal, smart selection. Those were features: a control in a menu, in a place you could find, doing one thing you asked for by pointing at it.
What is shipping now is different in kind. It is an interlocutor. You do not find it, you address it. And the difference shows up in the interface immediately, because a feature adds a control while an assistant removes the need for one — and a control nobody needs quietly stops being where anybody looks.
Where does the assistant sit?
There are two answers currently shipping, and they are not variations on a theme. They are opposite bets.
Inside the product. Figma put an agent on the canvas. It generates layouts, creates and edits layers, builds from your real components, tokens and variables rather than placeholders, runs bulk edits and design system audits, synthesises scattered feedback into changes, and lets you package repeated work into reusable /commands. Miro made the same call at Canvas 26 in May 2026 with Sidekicks: you talk through a half-formed problem, it asks questions to narrow it, proposes a plan for you to approve, then draws the deliverable on the canvas — docs, diagrams, kanbans, timelines — pulling live context from Jira, Slack, GitHub and Confluence through Connectors.
Outside the product. Sketch made the other bet, and it is worth reading carefully because almost nobody describes it accurately. There is no assistant in the app. Instead Sketch ships an MCP server: a local-only web server at localhost:31126/mcp, off until you switch it on, exposing eight tools — get_document_info, get_layer_tree_summary, get_design_assets, get_screenshot, get_libraries, get_symbol_overrides, get_guide and run_code — that let an outside client read and act on the open document. The client is Claude, or ChatGPT, or whatever you already use. No tokens to buy, no AI tier, no add-on.
What does each bet cost?
Put plainly, because the trade is symmetrical and both halves are real:
- Assistant inside. You keep the interface, so you keep the user's hour and the habit that forms in it. You also keep the bill — inference costs money, which is why it turns up on your pricing page as a tier — and you are betting that one model family stays good enough for long enough.
- Assistant outside. You stay cheap to run and effectively impossible to lock in; the user brings their own model and their own subscription. But the window they spend the hour in belongs to someone else, and attachment forms where the hour is spent.
Which is the question in the title, and Sketch is its sharpest version. If the thinking happens in Claude and Sketch holds the document, is Sketch still an application — or a file format with a viewport?
I have run the outside bet, and it broke
I use Sketch alongside Figma. While I was working in Codex, as I wrote when I compared the two assistants, that MCP connection kept dropping — not once, repeatedly, in the middle of work — and there was no Sketch extension inside Codex to fall back on.
That is the honest cost of the second architecture, and it is not a small one. An in-app assistant, when it fails, degrades into the app. A bridge, when it fails, degrades into nothing: no assistant, and no shortcut either. Reliability is not a footnote to this design decision, it is most of it.
I will say the less comfortable half too. I think Sketch is slower than it needs to be, and it reads the direction of the field late and only partly. Figma has beaten it on pace for years and the gap has not closed. And yet on this one decision Sketch chose the architecture I find harder to argue with: no model lock-in, no AI tier, the document stays the source of truth, and the server stays off until the user turns it on. Being right about the architecture and late about everything else is a real way to lose — which is exactly why it is worth writing down rather than cheering for.
A menu shows you what a product can do. A prompt assumes you already know.
What should a designer take from this?
- You are trading discoverability for recall. A menu is a list of what is possible; a prompt is a test of what the user remembers. The moment the primary surface is a text box, anything a person cannot think to ask for effectively does not exist. Empty states, onboarding and suggested prompts stop being polish and become the product's table of contents.
- Undo carries more weight than the generation does. An assistant editing your document makes larger and less inspectable changes than a person would. The credibility of the whole feature rests on how confidently the change can be reversed, not on how good the first result looked.
- Pick the architecture deliberately. Inside means you own the surface and pay for the inference. Outside means you stay cheap and hand the surface away. Both are defensible; drifting into one because it was the easier thing to build is not.
So — is the application still there?
Yes. I think the alarm is simply pointed at the wrong part.
What is leaving is the command surface: the menus, the toolbars, the fourteen routes to one operation, the years of muscle memory that made a tool feel like yours. That loss is genuine and I would not talk anyone out of mourning it.
What remains is what an application mostly always was — a place that holds the state, shows you the result, and lets you disagree with it. The disagreeing is the job. It just stopped being a menu.