Challenging the Chatbot | Rubric Labs
Challenging the Chatbot<br>Intelligent applications need new interaction patterns<br>July 7, 2026·Sarim Malik·Analysis
Table of Contents<br>Chevron iconInteraction Pattern Examples<br>1. Keystroke Intelligence<br>2. Ambient Intelligence<br>3. Inline Transformation<br>Where This Leaves the Chatbot
Chatbots have become the de facto interface for AI-native software.
My daily stack is filled with chat-first coding agents like Codex and Claude Code. Much of what we build at Rubric is chat-first by design.
There are multiple factors that make chatbots compelling :
People already know how to use them
You can show up with a rough idea of what you want and still reach a solid outcome
There's a built-in feedback loop: you ask, the model responds, you refine, etc.
People now reach for a chat thread for work that used to require menus and forms. Not only has software development changed, but the way we use has fundamentally changed. Which raises a more existential question: what exactly is software?
At its core, user-facing software is a human-computer interface. It is how people express intent to a machine and how the machine reflects state back. Every button, filter, menu, and chat box is part of a translation layer between you and the computer. Once you see software that way, it becomes clearer why language may be the best way to express intent. But this does not mean that it is the best way to express state.<br>On a podcast, Naval Ravikant describes AI models as natural language computing , where you say what you mean instead of learning command syntax or navigating menus.
If natural language is the new input , the larger design question starts to center around where intelligence can shape the translation layer. In this post, we will look at a few different ways intelligence can fit into new ways we use computers.
Interaction Pattern Examples
1. Keystroke Intelligence
One useful pattern is to let language capture intent, then immediately turn that intent into visible, editable application state.
Traditional dashboards often make users translate their goal into filter logic. For example, if you want to find large software purchases from last quarter that still need approval, you have to know which fields exist, which menus to open, and how the product names each status or category. In other words, you have to internalize a data model and a software interface before you can get your answer.
An intelligent interface would let the user start with the goal instead , where the system can interpret the request, apply the relevant structured filters, and show the resulting filter state back to the user so that it can be inspected or edited.
Let's look at a concrete example. Imagine a traditional banking product called Ledger , which has a table of transactions and a handful of filters for fields like amount, merchant, department, and policy. If you've used Brex or Ramp, Ledger probably feels familiar.
Usually, those fields become a dynamic form made of filter buttons. The user has to assemble the right combination by hand.
Click around the figure below to feel how much of the interaction is spent translating intent into interface mechanics.
Amount<br>Merchant<br>Department<br>Policy
Amount > $1,000Cross icon
MerchantAmountDepartmentPolicyAWS$2,840EngineeringNeeds reviewOpenAI$1,320EngineeringNeeds reviewFigma$1,180DesignApproved<br>Showing 3 of 5 transactions
Traditional software asks the user to assemble the right filter combination by hand.Copy<br>Even in this small static example, you probably spent a few seconds learning the interface. And even when it works, the outcome may not map exactly to what you had in mind. The interface can only express the shapes its developers anticipated. If you want to ask for the same information in a slightly different way, you run into the edges of the product.
That is one reason traditional software can feel frustrating. You have to learn the product's vocabulary and remember how to operate it later. But the advantage of this type of software is that it is predictable . The whole team will get the same output given identical inputs.
We still want that deterministic trust. So the opportunity is to find a compromise: let language express intent, then turn that intent into visible, editable state.
Try the flow below by describing the transactions you want to see in the input.
Amount > $1,000Cross icon
MerchantAmountDepartmentPolicyAWS$2,840EngineeringNeeds reviewOpenAI$1,320EngineeringNeeds reviewFigma$1,180DesignApproved<br>Showing 3 of 5 transactions
Intelligent software can use language to assemble filters while preserving visible, editable state.Copy<br>In our local runs, most requests landed in the 300-700ms range, which is close enough to the latency people already tolerate in normal software interactions. The cost is also small enough to change the product math. One representative request cost 0.000842¢ , which means you could run roughly 1.2 million filter...