Every week I open a product that's added AI, and every week it's the same thing: a chat box in the bottom-right corner. Sometimes it's a sidebar. Sometimes it's a slash command that opens a text field. But the shape is always the same. You type a prompt, the machine types back, and you're left staring at a blinking cursor wondering what you're supposed to ask next.

I don't think we're getting this right. And I include myself in that "we." Sam has a chat feature. I'm not against chat. But I think the industry has treated the chat box as the entire AI interface, and that's where things break down.

•   •   •

The problem is affordances. A blank text field tells the user nothing about what's possible. It doesn't say "I can draft a quote for you." It doesn't say "I can reconcile your budget against last month's invoices." It just sits there, waiting, and the user has to already know what the system can do in order to use it.

Amelia Wattenberger made this argument back in 2023 when she wrote that chatbots aren't the future of interfaces. Her point was that chat inputs lack the visual cues and scaffolding that decades of software design developed. No indication of what's possible. No structure for iterative refinement. A button that says "Create Quote" tells you exactly what will happen when you click it. A chat box that can also create a quote, somewhere in its bag of tricks, tells you nothing.

This is the gap. Chat is powerful precisely because it's open-ended. But open-ended is also disorienting. Most users don't want infinite possibility. They want the right three actions surfaced at the right moment.

•   •   •

The same problem shows up in the developer ecosystem right now with MCP servers and CLIs. A lot of energy is going into building tool protocols, ways to let Claude or ChatGPT interact with your product. You expose your app's functionality through MCP, and suddenly an LLM can create Notion databases, update Basecamp projects, manage Linear issues, all through conversation.

This is genuinely useful plumbing. But it has the same affordance problem, just one layer deeper. Connect the Notion MCP to Claude and you can create a database, add a page, update a property, set a relation. But the user has no idea any of those actions exist. They're buried behind a text field that could do anything, which in practice means the user only discovers capabilities by accident or by reading documentation that most people will never open.

Building the pipe isn't the same as designing the experience. An API is not a product. An MCP server is not an interface. These are the layers underneath. Important, necessary, but not where the user lives.

•   •   •

Here's what I think the answer looks like, and it's what I'm trying to build toward with Sam (AI Admin Assistant for Builders).

Chat stays. It's there for the open-ended stuff, the questions a builder has at 9pm about cash flow, or the "what should I be worried about this week" prompt that doesn't map to any single feature. That's a legitimate use of a conversational interface. The problem is open-ended, and the user needs to think alongside the tool.

But when there's a specific action the user can take - putting together a quote, reviewing a variation, chasing a subcontractor, that action should have its own interface. You click "Create Quote" and the quote UI appears: line items, margins, client details, the actual artifact you're building. And critically, you can edit it directly. Click a line item, change the number, rearrange the rows. People know how to work with a form. They've been doing it for decades. That muscle memory doesn't disappear because an AI is involved.

The chat doesn't disappear. It sits alongside, like a co-pilot. You're talking to Sam while watching the quote take shape. You say "bump the margin on excavation to 15%" and you see it update. Or you skip the chat entirely and just type the number in yourself. Both paths work. The user picks whichever feels faster in the moment.

This is the thing I think most AI-powered products are missing: the artifact has to be directly editable, not just AI-driven. If the only way to change the quote is to ask the AI to change it, you've made the experience slower than a spreadsheet. The whole point is that the AI handles the tedious setup, pulling in the client's details, pre-filling from the last similar job, calculating the margins, and then the user takes over, tweaks what needs tweaking, and ships it. The chat provides flexibility. The designed interface provides affordances. Direct editing provides speed. You need all three.

•   •   •

I think this is the design problem of the next few years: how do you take the raw capability of a language model and give it shape? Not just "here's a text field, talk to the AI," but interfaces that show the user what's possible, that present the AI's work as something tangible they can see and adjust, and that reserve conversation for the moments where conversation is genuinely the right tool.

What does a project management tool look like when the AI has already read every update, identified the three things at risk, and presents them as a priority stack with one-tap actions? What does email look like when the model has triaged your inbox and shows you a screen of five messages that need your brain, with drafted replies already attached? These aren't chat interactions. They're designed interactions, shaped by the AI's understanding but presented through interfaces that respect how people actually work.

The background work matters too. A language model is brilliant at reading unstructured information, classifying things, triaging. These are operations that should happen before the user opens the app. The builder shows up and the invoices are already matched, the overdue items are already flagged, the variation request that came in by email is already parsed and waiting for review. None of that needs a conversation. It needs a system that's paying attention when the user isn't.

•   •   •

The chat box was a fine first draft. It proved that people want to interact with AI, and it gave us a universal input that works for nearly anything. But "works for nearly anything" and "is the best interface for this specific thing" are completely different standards. We have the plumbing now, the APIs, the MCPs, the CLIs. What we need is the design layer on top. Surfaces that make the AI's capabilities visible, that give users a map instead of a blank field, and that treat conversation as one tool in the kit rather than the whole kit.

The builders who get this right won't be the ones who shipped the most capable chat window. They'll be the ones who figured out what their users actually needed to see.

~ Kosta