After the Interface: UI, Bricks and The Sculptor's Chisel

The interface is dissolving

The way technology is created and how it is consumed is changing

Most people will soon stop operating software and start briefing it. They will state an intent and expect a result, and whatever happens in between will once again become a black box.

This piece follows Programming after Code, which argued that the programmer’s job is moving from writing instructions to defining intent and its boundaries. The same shift is now reaching the people who use software.

The signs are already here. Working tools now appear in days, described into existence rather than written line by line. Their users are changing just as fast, handing more of their daily work to assistants and expecting software to keep up.

The model I expect to dominate is intent → result. I say what I want, and I get it. I do not want to scroll, search, tick boxes, set filters or click through screens on the way.

That claim is right in direction and too simple in detail. The middle part does not disappear: it becomes invisible to most users, and invisible is not the same as irrelevant. The rest of this piece tests the claim against what we already know, then asks what it means for the people designing these systems.

The interface was always a translation layer

“Computers do exactly what you tell them to do, not what you want them to.”

Graphical interfaces were a workaround, not a destination. Computers could not understand what we meant, so we broke our goals into steps they could parse. Every menu is a vocabulary agreed in advance between the user and the software.

Faceted search shows this clearly. A marketer looking for launch imagery in a Digital Asset Management (DAM) system might set six filters: asset type, campaign, region, rights status, format and date. The same request now fits in one sentence: hero shots of the new pack that are cleared for EU social media until the end of Q2.

The six filters were never the point. They were the user doing the machine’s translation work, one click at a time. Once the machine can translate for itself, that work becomes an overhead.

Seen this way, intent → result is less a revolution than a return. Early computing worked the same way: you submitted a batch job and collected a printout later, with no view of what happened in between. The graphical era was the exception, the period when every user also became an operator.

Each generation of computing has hidden the layer beneath it. Programming after Code traced that path for builders, with each new language trading more of the how for the what. Intent-driven interfaces take the same step for users, hiding the application itself.

The black box was never ‘clinical’

It is tempting to say we trusted the old black boxes blindly. We did not. Deterministic software fails all the time, which is why every serious release goes through testing and quality control before it ships.

The real difference lies in how each kind of system fails. A deterministic bug is reproducible: the same input produces the same failure, every time. That means it can be found and fixed, then locked down with a test so it stays fixed.

A probabilistic system fails differently. The same request may succeed nine times and fail on the tenth, and the failure rarely announces itself. A wrong answer from a language model usually looks exactly like a right one, fluent and confidently formatted.

So quality control changes shape. With deterministic software, you test the system and then trust its outputs. With probabilistic software, you keep judging the outputs, through automated evaluation at scale and human review where the stakes are high.

How much of the black box a user will tolerate depends on two things: how cheap the result is to check, and how easy it is to undo. A suggested image costs seconds to reject. A payment sent or a contract signed cannot simply be waved away.

For those, the pattern becomes intent → proposal → approval → result. The interface shrinks to a single confirmation, sized to the stakes, but it does not vanish.

The lost map

The unknown unknowns

Interfaces taught us things we did not know to ask. A checkbox labelled ‘include archived assets’ tells you that an archive exists. A menu is a map of what the software can do, and you learn that map by brushing past it.

A blank prompt box has no map. You can only ask for what you already know to ask for, which is the old problem of unknown unknowns: we rarely see the full range of what is possible, and more often than not we do not fully know what we want.

This reverses one of the graphical interface’s quiet achievements. Visible options made software usable by beginners, because the possibilities were on screen. Intent-driven interfaces reward people who already have the vocabulary, so experts gain the most while novices risk getting less than they could.

So the job of showing what is possible moves from the interface to the agent. A good agent has to do actively what the menu did passively. The clarifying question becomes the new checkbox, and so does the unprompted offer: ‘I found these, but there are also unlicensed variants; do you want those too?’

Generated interfaces take this further. In November 2025, Google Research described a system that builds a custom interface for each prompt, so users get controls shaped to their need instead of choosing from a catalogue of existing apps. Its human raters preferred pages designed by experts, with the generated interfaces close behind and well ahead of plain text answers.

The checkbox comes back, then, but built for this request and discarded afterwards. That has a cost. A static menu showed every user the same options, while an agent shows only the options it judges relevant.

That judgement is shaped by the agent’s defaults and by the commercial interests of whoever runs it. The filter bubble moves from your news feed to your choices.

Stating intent well therefore becomes a skill, much as searching well became one in the early years of the web. People who can describe what they want, and ask what else is possible, will get far more from these systems than people who cannot.

Fixed bricks, free builds

Not every output should be repeatable. A bank statement must be identical in structure and exact in every figure, every time. A campaign image must not be: give the same brief to a room of designers and you want a room of different answers.

Lego shows how the two can live together. The modern brick was patented in Denmark in January 1958, and bricks from that year still lock into ones made today (Wikipedia). Six standard 2×4 bricks can be combined in 915,103,765 ways.

That variety exists because the bricks never vary. They are made on machines working to tolerances as fine as 10 micrometers, so any brick fits any other. Hand the same set to a group and you get endless different builds, all standing on one rigid standard.

AI systems need the same split. The design question for every component is simple: is this a fixed brick or a free build? Customer Communications Management (CCM) and DAM sit at different points on that spectrum, and the difference is instructive.

In CCM, almost everything is a brick. The figures come from the ledger, and the layout and regulatory wording come from approved, locked templates. AI earns its place in the narrow free layer, interpreting the request and composing the personalised message around the fixed content.

I made the same case from the reader’s side in When AI Reads Your Bank Statement: language may be generated, but figures such as the total due must come from governed data.

DAM sits much further towards the free end. Finding the right image is an act of interpretation: ‘energetic’ and ‘right for a younger audience’ are judgements, not database fields.

Yet DAM has bricks too. A licence that expires on Friday is a hard constraint, and ‘probably cleared’ is not an acceptable answer.

Infographic comparing CCM and DAM. CCM is shown as mostly fixed, with governed figures, templates and regulatory wording beneath a smaller AI interpretation layer. DAM shows a larger interpretive layer for judging mood, audience and image choice, with licence and rights status kept as fixed system-enforced constraints.

Both systems rest on fixed bricks. What changes is how much room the model is given above them.

This leads to the most important design rule here: consistency comes from architecture, not instruction. Telling a model to follow the template is a request, which it will usually honour. Building the system so the model never generates the figures is a guarantee.

Suppose a model follows its instructions reliably 99.9% of the time. That still means roughly one wrong statement in every thousand. Now consider that a large financial institution will send millions and suddenly that 99.9% is no longer acceptable The fixed bricks must be enforced by the structure of the system, leaving the model free only where freedom is wanted.

This is the constitution from Programming after Code, seen from the user’s side. The model proposes; the fixed bricks decide what it may change.

The front door moves

If people stop opening applications, the interface stops being the moat. For decades, software companies competed on the screen, on the dashboard and the workflow. In an intent-driven world, many users will never see that screen at all.

What remains is the capability underneath. Products increasingly become services that agents call on a user’s behalf, through APIs and through standards built for the purpose. The Model Context Protocol (MCP) is the clearest example: in December 2025 it moved to a neutral foundation under the Linux Foundation, co-founded by rival AI labs and supported by the major cloud providers (MCP blog).

This changes the question every product team has to answer. The old question was how a user would find and operate a feature; the new one is how an agent will discover it and decide to trust it.

It also suggests that many of today’s vibe-coded apps are transitional. Programming after Code argued that code would become ephemeral, generated for the moment and regenerated when the world changes. The same now applies to whole applications: many will be summoned for a task and thrown away afterwards.

The less users see of the middle, the more the middle depends on its data. An agent can only resolve intent as well as the underlying information allows. In DAM, metadata and rights records stop being administrative chores and become the thing that makes ‘cleared for EU social’ answerable at all.

Discovery changes in the same way. Brands that once competed to rank in search results will compete to be the option an agent selects, and agents are likely to favour structured, trustworthy data over persuasive copy.

The chisel

A brush adds paint, and a mistake can be painted over. A chisel removes stone, and every cut is permanent. That makes the chisel the better analogy for working with AI, because the scarce skill is no longer producing material but deciding what to permanently remove.

The line usually credited to Michelangelo, that “every block of stone holds a statue waiting to be found”, has no reliable source. He did however express the idea in one of his sonnets: the greatest artist conceives nothing that the marble does not already hold within its excess (Wist). The sculptor’s work is taking away what does not belong.

AI makes marble cheap. It will produce a draft, an image, a design or a block of code in seconds, as often as you ask. For humans, two people can receive the same block, and only one of them will know where to strike.

The tool also has a pull of its own. A chisel never made suggestions; a model does, and its defaults lean towards the average of everything it has seen. Competent output becomes cheap, so taste becomes the differentiator, and taste is mostly the discipline of rejecting what is merely competent.

The harder question is where future sculptors will come from. Masters developed their eye through years of struggle with stubborn material, and apprentices learned by doing the rough work first. If the rough work is automated, the apprenticeship goes with it.

The early evidence points that way. A Stanford Digital Economy Lab study, updated in November 2025, found a 16% relative fall in employment for 22 to 25 year olds in the most AI-exposed occupations. Experienced workers in the same occupations held steady or grew, although the authors caution that other factors may also play a part.

Cognitive offloading (we covered it in Illusion of Productivity) is not new, and it is not automatically harmful: nobody mourns long division. The risk is narrower. A generation that never handles the stone may never learn to see the statue in it.

What is left for us

Intent → result is coming, and for most everyday tasks it will feel effortless. The middle will go dark for most users, as it did in the era of batch jobs and as it does today for the packets behind every email.

But the middle has to become more rigorous as it becomes less visible. That means designing fixed bricks wherever consistency matters, and putting a confirmation step wherever a result cannot be undone.

For the human, two jobs remain, and they are the hardest ones. The first is stating intent: knowing what you want, and asking what else might be possible. The second is recognising when that intent has been met, which is the sculptor’s judgement of when to stop cutting.

The tools will keep getting better at the middle. Whether we get better at both ends is up to us.

Sources