Challenging the Chatbot

Intelligent applications need new interaction patterns

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:

1. People already know how to use them
2. You can show up with a rough idea of what you want and still reach a solid outcome
3. 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. 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.

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.

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 searches before spending $10.

And of course, inference costs keep falling, latency keeps improving, and smaller models keep getting better at narrow structured tasks. That makes it reasonable to imagine interactions like this eventually feeling instantaneous enough that the user does not think about the model at all.

These are the sorts of questions we've been asking ourselves at Rubric. Where is it worth spending a little intelligence on each keystroke? The answer seems to be that anywhere the product is trying to capture intent, translate vague language into application state, or help the user shape a query. That's where this pattern starts to open up.

2. Ambient Intelligence

Ambient intelligence is work the product does in the background. People like to talk about "proactive software," and ambient intelligence is one way software can be more proactive, where intelligence is running at all times but only interrupts the interface when it has something useful to surface.

As an example, imagine a CRM product called Pivotal. Instead of waiting for a sales rep to ask a question, Pivotal scans account activity and prepares recommendations for the user to inspect.

The product gathers data from inside the CRM and recommends an action to the user. While some recommendations are just nice to have, critical ones catch something that would have otherwise gone unnoticed.

As discussed previously, one of the factors that makes the chatbot compelling is its feedback loop. A surfaced recommendation is only half of that loop. The other half is a way to give the model feedback as it works in the background.

In this case, the recommendation arrives as a dedicated action item, with a link that takes the user to the right place inside the product. The user can then interact and provide feedback accordingly.

Ambient intelligence is most useful when it feels like the product did useful work and brought it back at the right moment, with clear ways to inspect what it found and shape what happens next. It shouldn't feel like magic out of thin air, but rather a configurable part of the product.

3. Inline Transformation

The first two patterns applied intelligence around the interface. The third pattern embeds it directly inside the content the user is working on.

Consider how you might write and edit using ChatGPT or Claude. You copy a paragraph into a thread, describe a change, and get back a rewritten block of text. Then you paste it over the original and reread everything, not knowing whether the model made edits you didn't want or didn't notice.

With inline transformation, the user selects the exact text they want to change, describes the change in place, and reviews a diff exactly where the text lives. For this example, imagine an essay-writing tool called Pencil. Instead of a chat panel next to the document, Pencil puts the model inside of the document.

The model sees the selected text, some surrounding context, and the instruction, then returns only the replacement.

The feedback loop from the ambient pattern shows up here too in a compressed fashion. Accept and discard are the thumbs up and thumbs down, and because the edit is scoped, rejecting one costs nothing. The user stays the editor; the model is a collaborator that proposes diffs.

Where This Leaves the Chatbot

The chatbot is still currently the best interface we have for exploration and for work that has no fixed shape yet, where models assemble decision paths on the fly (Primitives over Pipelines), but it is just the beginning of this design space.

The three patterns above share the same shape: language captures the intent, the product turns that intent into visible, editable state, and a feedback loop lets the user steer what happens next. Edited filters, thumbs on a recommendation, an accepted or discarded diff.

Future interfaces will look like the software we already know, with intelligence embedded wherever users are trying to express what they mean.