When the Interface Became Optional

I no longer use a CMS for my websites.

There is no control panel for me to log into. No page builder. No plugin menu. No form with a field for the headline, another for the body text, and a green button promising to publish everything if I dare press it.

Websites are code.

My documents are Markdown. My digital employees read and edit both directly. When I want to edit a text, move an element, or build a new page, I describe what I want. An agent finds the relevant files, changes them, runs the tests, and shows me the difference.

I don’t need to know exactly which component needs to be opened. I don’t need to remember the syntax. I also don’t need to learn an administration system that someone else has decided should be my access to my own website.

On the surface, it is a small technical change. I have simply swapped one tool for another.

But a CMS was never just a tool for saving text. It was a translator between humans and machines.

The human said: New article.

The CMS translated it into database fields, files, HTML, relations, and publishing logic. The human got buttons and forms. The machine got structured instructions it could execute.

We built these kinds of interfaces because humans and machines did not speak the same language.

Now I have an employee who speaks both.

The Compromise That Came to Resemble Nature

The modern CMS solved a real problem.

If an editor had to know HTML, CSS, server setup, and version control to fix a typo, the web would be a somewhat quieter place. The CMS made content accessible to people who had something to be said, but did not necessarily want to become software developers first.

It was an enormous democratization. But it came at a price.

To make the machine simple, the system had to decide in advance what the human could desire.

There had to be a content type called article. The article had to have specific fields. The image had to be placed where the theme allowed. The publishing process had to follow the workflow the system knew. If you wanted something else, you had to find a plugin, write an extension, or learn to live with the template having other plans.

We gained easier access to the machine by accepting the system’s conception of the world.

This does not only apply to CMSs.

A spreadsheet turns calculations into cells, rows, and columns. A CRM turns relationships into contacts, companies, pipelines, and activities. A project management system turns work into tasks, statuses, and deadlines. A word processor turns knowledge into pages with typography, margins, and a blinking cursor.

All these systems have made complex machine actions accessible to humans. And all these systems have simultaneously taught humans to formulate their work in the way the system could understand.

When we say today that a company “works in” a certain system, we often mean it quite literally. The work has assumed the form of the system.

This is not necessarily bad. Constraints can create order. A shared data model can prevent every employee from inventing their own reality. A fixed workflow can ensure that an invoice is actually approved before the money leaves the account.

But the compromise became so common that we stopped seeing it as a compromise.

We began to believe that every human activity naturally required its own system with menus, fields, and buttons.

The Universal Translator

AI does not only change what the machine can do. It changes the relationship between intention and execution.

A language model can understand a human description of a desired result. It can simultaneously read code, structured data, documentation, error messages, and test results. It can move from “make the homepage calmer” to the concrete changes in layout, typography, and components that make the homepage feel calmer.

This does not mean that the translation is always correct. It also does not mean that human intention is unambiguous. Two people might mean different things by the word calm, and a model might choose the prettiest interpretation rather than the right one.

But the translation has become possible.

Google describes AI code generation as code created from a user’s conversational prompt or natural description. The code can be written faster, but that is only the first consequence. Natural language can now serve as an entry point to material that previously required a specialized human language.

AI does not speak code the way a programmer does. It does not understand a system through experience, responsibility, and a stable internal model of the world. It calculates probable and useful connections between descriptions, patterns, and actions.

Nevertheless, the practical consequence is hard to overlook: the human can express an intention, and the agent can work directly in the system’s material.

It makes the user interface optional.

Not always. Not for everyone. And not necessarily tomorrow. But as a principle.

If I want to publish an essay, a developer does not first need to build a form with the fields the essay requires. I can give the text to an e-agent that already knows the website’s content model, links, design rules, and publishing process. The agent can create the file in the correct format, check the metadata, run the validation, and prepare the change for my approval.

I do not encounter the system’s form. I encounter an employee who can work within the system.

In From tool to being, I wrote that what is crucial about an agent is not whether it is conscious, but whether it takes initiative and fulfills a sustained role. Here, another consequence emerges. When the tool becomes an employee, the human no longer needs to operate every tool the employee uses.

A CFO does not need to know the database language to ask why costs increased. An editor does not need to know the component hierarchy to change a front page. A leader does not need to know which API connects two systems to request that an approved decision be implemented in both places.

The AI stands between intention and technical material. Not as yet another control panel, but as a translator and executing employee.

Markdown is Not the Point

I live in plain text.

My websites are code. My documents are Markdown. Instructions, research, decisions, and editorial notes reside in files that can be read directly by both humans and agents.

Markdown was originally designed as a readable and easy-to-write text format that could be converted into structurally valid HTML. Its most important feature was not that it was technically clever. It was that the source text could still be even read as text.

This makes the format remarkably suitable for a human-agentic organization.

An agent can search the files, follow links, compare versions, change the structure, and render the content as a website, PDF, or something else entirely. I can open the same source and read it without a specialized program. Neither of us needs to first export the document from a proprietary container to understand what it says.

But the point is not that all humans must now learn Markdown.

That would be a strange conclusion to a text about technology becoming less visible.

The point is that the organization’s canonical material can exist in an open, structured, and version-controlled form, while the human gets the view that suits the situation.

A document does not need to be the place where knowledge lives. It can be a rendering of knowledge.

A spreadsheet does not need to be the only reality for the organization’s numbers. It can be one view of the same data.

A dashboard does not need to show the same twelve graphs to everyone every Monday. It can be created for the question that is actually being asked.

A website does not need to be edited through a CMS. It can be the public rendering of code, content, and rules that already exist in the organization’s shared material.

Today, many systems mix three things together: the underlying knowledge, the rules for how it may be changed, and the interface the human sees. AI makes it possible to separate them.

It is a greater change than a new text field with a chatbot next to it.

When the Document Becomes a View

Imagine a quarterly report.

Today, data is pulled from several systems. Someone copies numbers into a spreadsheet. Another writes explanations in a document. Diagrams are exported as images. The file is sent back and forth with names like Quarterly_report_final_v7_corrected2.docx.

In the end, the organization’s knowledge about the quarter is scattered between source systems, cells, comments, emails, and the wording that survived into the final PDF.

An agent-native version starts somewhere else.

The numbers have a canonical structured source. The definitions of key metrics are documented. The qualitative explanations have owners and provenance. The agent can compile a report for the board, a short version for employees, and an interactive overview for management from the same underlying material.

The three products do not need to be identical. They are different views for different people with different needs. But they should be traceable back to the same reality.

This is where the connection to The Human-Agent Organization becomes clear.

If AI is to be a first-class participant in the organization, the company’s reality must be readable by it. Data, roles, decisions, and workflows cannot only reside in interfaces built for human hands and human eyes.

But the opposite is also true.

If the organization’s reality can only be a read by the agent, we have not built a human-agentic organization. We have simply replaced one inaccessible system with another.

The canonical layer must be structured enough for the machine and understandable enough for the human. The views may be different. The truth must not be private.

That is why plain text, open formats, explicit links, and documented provenance matter more than they did when all work was performed through a fixed interface. They are not nostalgic developer preferences. They are common ground for work.

Less Technology. More Software Discipline.

It creates a paradox.

AI makes technology less visible to the human, while software development disciplines become more important.

I do not need to write the code myself. But I need even more to know what was changed, why it was changed, whether the change works, and how I can revert if it does not.

In a CMS, control lies, among other things, in roles, fields, previews, and a publishing button. When the agent works directly in code and text, control shifts to version history, branches, reviews, automated tests, permissions, and deployments.

GitHub describes version control as a system that tracks the history of changes and makes it possible to restore previous versions. The history can show what was changed, who did it, when it happened, and why. Branches make it possible to propose changes without altering production, and pull requests make the proposal subject to conversation and approval.

This is not only useful for software developers.

It is exactly the questions I want to be able to ask a digital employee.

What did you change?

Why?

Which rules did you follow?

What did you test?

Who approved it?

Can we undo it?

When the website becomes code, editorial governance becomes software governance.

When documents become version-controlled sources, knowledge management becomes software governance.

When agents change the organization’s systems based on human intention, software development principles become management principles.

This does not mean that all leaders must learn Git commands. It means they must understand the difference between a draft and production. They must know why a change must be reviewable. They must be able to define which tests show that the intention was actually met. They must decide which actions the agent may perform itself, and which require human approval.

Previously, humans learned technology to be able to operate the machine.

Now, AI can handle much of the technology, but the human must be able to lead the one who does.

It is the same movement I described in An AI agent needs a job description. An agent must have a mandate, not just a prompt. Git, tests, and access control are the technical side of the mandate. The job description says what the agent may do. The system must determine what it actually can.

The Buttons Also Protected Us

It is tempting to make the user interface the villain in this story.

It stood between humans and pure freedom. Now AI can lead us around it. Farewell to forms, licenses, and plugins. Enjoy the code.

It is not that simple.

Buttons and fields limit, but they also protect.

An editor with access to three fields cannot accidentally delete the routing for the entire website. A CRM can enforce that a contact has an ID before it is saved. A publishing button can require a specific role. A spreadsheet shows the calculation in a form a human can examine. A fixed user interface makes the system’s capabilities visible and bounded.

When the agent can work directly in the material, its surface of action becomes larger. That is precisely why freedom requires more discipline.

Google, for example, is working with A2UI, an open format for agent-generated user interfaces. An agent can assemble the form or visualization that fits the situation. But Google simultaneously emphasizes that a remote agent should not send arbitrary executable code to the user’s device. Instead, the agent sends a declarative description and must choose from components that the client has already approved.

Even in a world with generative interfaces, structure, rights, and trust return.

They just return at a different level.

We do not escape system design. We escape the pretense that the same fixed interface is the best translation of any intention.

And we do not escape specialized systems. A surgeon should not perform a critical action through a free conversation if a validated workflow can reduce risk. An employee should not be able to bypass data protection by formulating their intention creatively. A financial system must still have transactions, controls, and clear lines of authority.

The false choice is between fixed systems and boundless conversation.

The real question is which parts of the system should be fixed, and which can be created or translated in the moment.

From User to Leader

Software has long called the human a “user.”

The word reveals the relationship. The system has the possibilities. The human uses them.

The user learns which buttons exist. The user adapts their task to thely workflow. The user becomes skilled at making the system do what it was already built to do.

With an agent, the relationship shifts.

The human does not necessarily describe every click. They describe the result, the consideration, and the boundary. The agent chooses the tools and performs the work.

It looks less like operation and more like management.

“Update the article with the new point, but do not change the published versions yet. Preserve links. Run the validation. Show me the difference.”

That instruction does not contain a sequence of buttons. It contains an intention, a mandate, some quality criteria, and an approval boundary.

It is also harder than pressing a button.

A button often hides complexity by limiting choice. When the human must instead formulate the intention, unclear thoughts become visible. What does “better” mean? Which parts may be changed? What must be preserved? When is the task finished? Who owns the consequence?

AI does not make the human unaccountable. It moves human responsibility away from the details of execution and toward direction, criteria, and boundaries.

One can certainly get an agent to build a website without being able to code. One cannot get a good website without being able to take a stand on what it should be.

The Organization Without a Control Panel

I do not know how far this movement will go.

CMSs are unlikely to disappear. They will change, have agents built-in, and continue to be the right solution in many places. The spreadsheet will likely survive too, because cells are an excellent way to think with numbers. Humans need stable visual surfaces, not just conversations with invisible systems.

But we should stop assuming that the interface is the system.

A document is a possible view of knowledge.

A spreadsheet is a possible view of data.

A dashboard is a possible view of a situation.

A website is a possible view of code, content, and design rules.

When AI can translate between human intention and structured material, the view can emerge as needed. Sometimes as a conversation. Sometimes as a form. Sometimes as a diagram. Sometimes as the familiar page with fields and a green publishing button.

The difference is that the button no longer needs to be our only way in.

It requires a different kind of organization. An organization with open and structured sources, clear owners, explicit permissions, version history, validation, and the ability to roll back. An organization where the agent can read reality without scraping it from the human’s screenshots, and where the human can understand and control the changes the agent proposes.

In that organization, the human works with meaning. The agent works with the material. The system remembers what happened.

It is not less technical underneath.

It is less technical to be a human within it.

We built software interfaces because humans and machines did not speak the same language. Now we have gained an employee who speaks both.

It does not make the rules redundant.

It makes the interface optional.