The changing face of software

I remember learning to use Google; bringing words together in a shape I'd never use to speak to a human:

best sushi brooklyn open late

In 1995 this non-sentence would have been gibberish - yet by 2005 we had all learned how to do this. A pile of keywords arranged for a machine. The skill was in learning which words mattered, which ones got in the way, how to reformulate a reasonable question when the search box failed to understand it.

If you nailed it, you were "good with computers", and the world's information became available to you.

The same bargain runs through the rest of software. A form asks us to split a name into two fields even when the name does not divide that way; a date field demands its preferred format; a dropdown contains every option except the one we need. To book a table, we take a request we could say in one breath ("can you get me in around seven next Tuesday?") and translate it into a date picker, a party-size selector, and whatever availability the system decided to expose. Resume portals and ATSes ask for a PDF and then for the same information to be keyed in again.

The red error message says we failed; but isn't the software also failing to understand us? My autocomplete systems still can't fill in the 'State' field correctly across all address forms.

All of this was a huge upgrade over doing things with pen and paper, so there was cause for celebration at the time, and the decades have normalized this state of affairs. People develop skills to conform to the needs of machines. Using software means turning the fuzzy reality in our heads into the rigid representation a computer can accept: where the settings live, which sequence of screens completes a task, how a company divides its customers, invoices, and projects in its database. The interface exposes the data model; the person does the translation.

Intent before interface

Graphical interfaces made this translation far easier. In his 1983 paper on "direct manipulation," Ben Shneiderman described the appeal of operating on visible objects through rapid, incremental, reversible actions (1). Instead of memorizing command syntax, a person could point at a file, move it, and see the result.

That design principle still matters. A visible object can be inspected; a stable layout can be learned; an action that previews its consequence and offers undo gives the user control and confidence. The graphical interface replaced recall with recognition and opened computing to far more people.

But it kept a deeper constraint: the product still had to decide, in advance, the valid things a user could say. Menus, buttons, fields, and screens formed a friendlier grammar, but they were a grammar. If your intent did not fit it, you adapted.

LLMs change the bargain because ambiguity no longer causes immediate failure. You can begin with an outcome before you know the right command, give an incomplete answer and get a useful follow-up question, correct yourself halfway through. The system can connect "send the revised one to Sarah" to a document and a person already in context rather than demanding two fully specified identifiers.

The first public description of ChatGPT emphasized this conversational behavior: it could answer follow-up questions, admit mistakes, challenge incorrect premises, and reject inappropriate requests (2). The interface looked almost aggressively simple, but the novelty was not the text box. The model took on more of the interpretation.

"Chat is the new UI" has dominated the last 18 months, but is too narrow a reading. Natural language is an input layer; conversation is only one possible output. Sometimes the right response is a sentence; sometimes it is a chart, a confirmation, a phone call, a generated report, or an action that happens quietly and leaves a receipt. The breakthrough is that software can understand intent before deciding which representation is useful.

A phone call in Dolores Park

I took a call sitting on the side of a hill in Dolores Park in San Francisco. For 25 minutes, I told Boardy where I was in building a startup, what I hoped the next step might be, and what I needed from meeting other people.

Once the call began, there was no screen to study, no empty dashboard waiting for me to populate it. I talked.

Boardy describes itself as an "AI Superconnector," an AI networking agent that facilitates professional introductions (3). That makes the call more than novel onboarding; conversation is the product's raw material. The useful input is the story: what I was trying to do, where I was stuck, and which kind of person could help.

A form could ask for all of that; I would only give it worse answers.

"What are your goals?"

"Who would you like to meet?"

"Describe your company."

Each question looks reasonable above a text box; together they put the work on me. I have to decide what matters before the product knows enough to help, compressing the messy version into startup shorthand and giving the answer I think the form expects.

This call worked differently. Boardy's Australian voice added some novelty, but the voice was not why it worked. It felt like talking to a practiced interviewer, someone who knew when to follow a lead, how to draw out the narrative, and when to ask a better second question. I could begin with a loose answer and talk my way toward what I meant.

It was the first time in my life I had a conversation with a computer that I enjoyed.

Afterward, Boardy messaged me on WhatsApp, and every few days it suggested someone in its network I might enjoy talking to. I never logged in, never installed an app; the experience was a phone call, messages, and introductions, the same forms a good human networker would use.

That absence of a traditional interface is a product decision. The standard instinct in software is to build a place: a web app, a mobile app, a home screen where the user can see the product exists. Sometimes that place is necessary; sometimes it is only another room the user has to remember to visit, another tab, another inbox.

The design question is not what an AI networking dashboard should look like, but how a good networker behaves.

Phone, WhatsApp, Slack, Telegram, and email can be more than acquisition or notification channels. For some products, they can be the user experience. They already carry social norms, identity, notification controls, and interaction patterns people understand. A product can arrive where the work is happening rather than demanding a new habit, destination, or login.

This does not make product design free. It moves the design work. How should the agent introduce itself, what should its vibe be? Which question produces an honest answer instead of a polished one? What should it remember? When is a follow-up welcome? When should it stop? A beautiful settings page cannot rescue a bad conversational experience. In a channel-native product, timing, judgment, tone, and restraint are interface design.

Screens become responses

The same shift applies to visual software.

A customer asks for another dashboard. They want pipeline by region, segmented by account tier, with monthly and quarterly views. Product scopes it, design adds it to reporting, engineering builds the query, permissions, chart, filters, export, loading state, and empty state. Six weeks later, another customer asks for almost the same report, except their regions differ and they care about product line.

This is how a product becomes a filing cabinet of screens.

For most of software history, product teams had to predict useful questions and encode the answers into permanent interfaces. Good teams found common patterns and made reusable workflows, configurable knobs and more branches to help 'personalize' the software. But reporting sections still accumulate frozen answers to questions someone once guessed users would ask.

Now the customer asks:

Which enterprise accounts are most likely to miss their onboarding date, and why?

The product can interpret "enterprise," "onboarding date," and "risk" using the organization's definitions; query only the records this user may access; and assemble a ranked table, a chart of delay factors, and a short explanation linked to the sources. That particular arrangement may only need to exist for this question and this moment.

This is no longer speculative as an interaction pattern. Google Research has demonstrated systems that generate interactive visual experiences for a prompt and has begun bringing them into Gemini and Search. Its own evaluation is mixed: human-designed sites were still preferred most, generated interfaces followed closely, and standard text or markdown outputs trailed. Google also notes that generation can take a minute or more and can contain inaccuracies (4). A separate 2025 study of generative interfaces found up to a 72% improvement in human preference over conversational interfaces across its tasks (5).

The evidence supports a useful claim, not a maximal one: for information-dense or exploratory work, a generated interface can beat a long conversation. It does not prove that generated software should be unconstrained, or that a model should improvise consequential controls.

At a desk, that onboarding-risk question may become an interactive web report with filters and drill-down. In a car, it should become a short spoken briefing with the two accounts that need attention. In Slack, it may be one chart, three lines, and links to the underlying records.

The product, its state, and its permissions do not change; only the surface does.

The dashboard is one render target among many, a single expression of what the product knows and can do. Underneath sit the real primitives: capabilities, judgment, durable state, permissions, and business rules. The product assembles an interface on top of them for the task and the available attention.

This is more demanding than putting a copilot beside an existing app. Identity and permissions have to survive across surfaces: a Slack response must not reveal an account the user could not open on the web. A spoken summary needs a path back to inspectable detail; generated charts need source links and known definitions, not plausible shapes.

The surface still needs design: voice requires ruthless prioritization; shared channels require care with sensitive information; web reports need keyboard access, readable hierarchy, and reliable interactions. "Generate some HTML" is not a product strategy.

Research on adaptive interfaces offers an older warning worth keeping. In a controlled 2008 study, predictability and accuracy both improved satisfaction; accuracy also improved performance and use of the adaptive area (6). Adaptation has to be right often enough to earn trust, and users need a stable mental model of what may change.

What should remain stable

Stable interfaces are excellent for frequent, predictable, or high-stakes work. Nobody wants payroll approval controls to reinvent themselves every Friday. An operator responding to an incident needs known controls, not a fresh composition that happens to look elegant. What used to be a semiannual UI redesign that resulted in momentary "hey, you moved my cheese!" reactions from customers could become a daily frustration if you're not careful.

Direct manipulation remains valuable for the same reasons it won in the first place: visibility, immediate feedback, incremental action, and reversibility. Generated interfaces should inherit those properties rather than discard them.

A useful rule:

• Generate the answer when the question is occasional, exploratory, or highly contextual. One-off research questions, curiosities, and cross-cutting "how does x connect to y", especially when trying to correlate disparate data sources without a perfect UI, are all good candidates.
• Stabilize the workflow when the task is frequent, predictable, consequential, or benefits from learned spatial memory. Bonus points for learning a user's preferences, way of working, and voice.
• Combine the two when language is the fastest way to express intent but a visual preview, edit step, or confirmation is the safest way to finish. Think about 'copilot' experiences which can use your UI faster than any human, or can do it via voice when they have french fries in one hand.

Moving a meeting is a simple example. "Find 30 minutes with Maya next week and avoid mornings" is a better starting point than navigating calendars. But before the software changes anyone's schedule, a stable confirmation showing the proposed slot, attendees, and conflicts beats a confident sentence claiming to have understood.

Intent first does not mean intent only. The product chooses an interface in service of the job rather than forcing the job through the interface it already has.

For builders, the first design question changes. Instead of starting from "what screens does this product need?", start from:

1. What outcomes can the product reliably produce?
2. What context must it understand, and what ambiguity must it resolve?
3. What state, permissions, definitions, and approvals govern the work?
4. Which surface fits the moment: conversation, a stable workflow, or a generated artifact?
5. How can the user inspect, correct, undo, or confirm what happens?

For a long time, a power user was someone who had memorized enough of a machine's expectations to move quickly.

That is a backwards standard: software should become unusually good at understanding people, not the other way around. The interface is no longer where the product has to begin. Intent is.

Making that flexible experience dependable requires a new application layer, and a new set of primitives underneath it. More on that soon.

References

1. Ben Shneiderman. "Direct Manipulation: A Step Beyond Programming Languages." Computer 16, no. 8 (1983): 57–69. doi.org/10.1109/MC.1983.1654471
2. OpenAI. "Introducing ChatGPT." November 30, 2022. openai.com/index/chatgpt
3. Boardy. "Boardy — The AI Superconnector." Accessed July 2026. boardy.ai
4. Google Research. "Generative UI: A rich, custom, visual interactive user experience for any prompt." research.google/blog/generative-ui
5. Jiaqi Chen, Yanzhe Zhang, Yutong Zhang, Yijia Shao, and Diyi Yang. "Generative Interfaces for Language Models." arXiv:2508.19227, revised May 2026. arxiv.org/abs/2508.19227
6. Krzysztof Z. Gajos, Katherine Everitt, Desney S. Tan, Mary Czerwinski, and Daniel S. Weld. "Predictability and Accuracy in Adaptive User Interfaces." CHI 2008. PDF

Start building on Runtype.