AI and Life · Essay
Interfaces translated human intent into machine procedure. As AI becomes able to carry more of that procedure itself, the application may stop being the place where ordinary work has to happen.
I have been rebuilding parts of the infrastructure around my own work recently, and one thing keeps becoming more obvious to me: a surprising amount of what we call using software is really a person translating a decision they have already made into the sequence of operations a collection of systems require.
Publishing an article is a simple example. By the time I decide to publish, most of the meaningful work is already done. I have written the piece, changed the title several times, decided what I am actually trying to say, adjusted the structure, worked on the description and metadata, and eventually reached the point where I am comfortable putting my name on it.
What happens next may involve a database, image generation, object storage, metadata, a website, and eventually social or email distribution. Those are all real parts of the system, but they are not new decisions. They are the mechanical consequences of a decision I have already made.
Historically, that distinction did not matter very much because software could not do much with the decision itself. It needed the procedure. If I wanted to publish something, I had to express that intention in the vocabulary of the systems involved: fill these fields, upload this file, choose this status, copy this value, trigger this operation, verify the result.
The interface was the mechanism through which a human translated an outcome into something sufficiently precise for a machine to execute.
That arrangement has shaped software for so long that it is easy to treat it as inevitable. I am not sure it is anymore.
This is not really an argument against dashboards, forms, or graphical interfaces. I still find them useful, and in many cases necessary. When I am configuring something for the first time, investigating a failure, comparing states, or making a consequential change, I want to see what is happening.
The part I am starting to question is why the interface has to remain the normal execution path for routine work.
If I decide that a domain should point to a particular application, the meaningful decision is the relationship between the domain and the application. The rest is implementation. One system has a value, another system needs a record, perhaps a certificate needs to become valid, and eventually somebody should check whether the route actually works.
I can do those steps myself. I have done them many times. But the fact that I know how to do them does not mean my attention is the right place to execute them every time.
I wrote about a related problem in I Think I Became the Middleware. There, I was mostly interested in the amount of information people still carry between systems that are otherwise highly automated.
What I am noticing now is that the same issue exists one level above the individual handoff. We do not only carry information between systems. We often carry the entire procedure.
An AI assistant that tells me which menu to open and what value to paste does not change this very much. It may be easier than reading the documentation, but I am still the runtime.
The interesting change with AI is not that software has become conversational. It is that software can increasingly operate with a less complete procedural specification.
A system can interpret ordinary language, inspect several sources, use tools, compare current state with intended state, execute multiple operations, and check what happened afterward.
None of this is perfectly reliable yet, and the boundaries matter enormously, but it expands the amount of work that can move from “a person must perform the procedure” to “a person can define the outcome.”
That changes how I think about the systems I am building.
When I publish an article, I do not want to think first about the database, the image generator, the storage system, and the website as separate destinations. From my point of view, they are components involved in carrying one operation.
The database can store the article. The media system can create and store images. The website can render the current published revision. Those systems still need clear contracts and boundaries, but I should not necessarily have to operate each of them individually.
From this perspective, applications start to look less like places I go and more like capabilities available to a larger system.
This connects to something I have been exploring in I’m Trying to Build Myself Out of the Loop. The goal is not to remove the human from everything. It is to become more precise about why the human is there.
If I am making a judgment, taking responsibility, applying taste, or dealing with an unusual situation, my involvement may be exactly what the system needs.
If I am there because three pieces of software need somebody to carry a procedure between them, that is a different problem.
There is an obvious catch.
“Publish this article” is only a useful instruction if the surrounding system already knows which site I mean, where the content belongs, what the publication rules are, which credentials it can use, how media should be handled, and what counts as success.
Without that context, natural language does not remove complexity. It simply turns the configuration screen into a long conversation.
Instead of filling in twenty fields, I answer twenty questions.
This is one reason I have become much more interested in persistent operational context. Not chat history in the broad sense, but the actual state and rules that allow a system to understand what an instruction means inside a particular environment.
The better that context is, the less I should have to repeat.
If I need to explain my infrastructure, my accounts, my defaults, and my previous decisions every time I ask for something to happen, the system is not really carrying much. It is waiting for me to reconstruct the environment around the task.
There is a useful design test here. When an ordinary operation repeatedly returns to a person for information the system could reasonably already know, that is probably a context problem before it is an intelligence problem.
I do not think this leads to a world without interfaces.
There are many situations where direct interaction is better. I may want to browse, compare, inspect, experiment, or understand the state of something before I know what outcome I want. Interfaces are particularly valuable when the goal is exploration rather than execution.
They also matter for control. As software becomes capable of acting with more autonomy, visibility into what happened, why it happened, what authority was used, and how to reverse it becomes more important rather than less.
What changes is the role of the interface.
Today, the interface often serves two purposes at once: it helps me understand the system and it makes me execute the system’s procedure.
I think those two functions may begin to separate.
I still want software to help me understand what is happening. I am less convinced that I should need to manually carry every ordinary operation simply because the system has historically been organized around screens.
There is also a broader question here about what happens to the capacity this creates. In What Happens to the Time AI Saves?, I wrote that saving time is not the same thing as receiving it back. A more capable system can simply create room for more work.
The same warning applies here.
Removing interfaces from routine operations is not automatically freedom. It may simply allow us to operate more systems at once. The surrounding incentives still decide what the released attention becomes.
For a long time, the product and its interface were almost inseparable. You used a piece of software by going into that piece of software.
That assumption becomes weaker when another system can use its capabilities on your behalf.
A product may still have an excellent interface, but an increasing amount of its actual use may happen through software acting for people rather than people navigating the product directly.
That makes a different set of qualities important.
Can the product expose what it can do clearly? Can authority be delegated narrowly? Can another system understand its current state? Are its operations predictable? Can the result be verified? Can the human inspect and override what happened when necessary?
These used to sound mostly like API or infrastructure questions.
I suspect they are becoming product questions.
The change I notice in my own work is fairly simple. I am asking less often which application I need to open and more often what I actually want the system to accomplish.
The interface is still useful when it helps me understand, explore, or decide.
But once the decision has been made, I increasingly expect the software to be able to carry more of what comes next.
That is what I mean by intent replacing the interface.
Not that the interface disappears.
That it stops being the place every intention has to pass through.
Continue the conversation
Essays and field notes on AI, systems, work, building and life.