Our screens were making decisions nobody had written down

When an AI assistant operates your product, the decisions your screens made quietly have to be written down.

An AI assistant helped me draft this. The rules it describes, the examples and the final edit are mine.

Someone asks their assistant to notify the subscribers. They mean the active ones. Never the expired ones, unless they say so.

Nobody had ever had to write that sentence down. In front of a dropdown you decide in a second, without noticing you decided: the list is there, the three options are visible, your eye does the choosing. An agent has no dropdown. It has a sentence, and it has to get a decision out of it.

For a few months now, the owners of apps built with GoodBarber, where I’m CTO, can run their app from the AI assistant they already use: it connects to our platform and can read a catalog, publish an article, send a notification. Being able to do all that doesn’t tell the assistant where to start, so we wrote one instruction file per common task, in plain text and in public. Writing them is where we found the rules.

A screen decides quietly

That was the surprise of the exercise, and it came back with every file: we kept running into rules nobody had written, held up by habit and by the layout of a screen. A default value is a decision. So is the option you show first, the one you leave out, and the confirmation you ask for. Nobody ever argued about them, because nobody ever had to put them into words.

Take the screen away and the decision is still there, with nothing holding it up. So you write it down, which means owning it, re-reading it, and being able to change your mind about it.

Never guess

The second rule of the same family: never guess which person the user means. The instructions have to search all three lists a person could be in (prospects, active subscriptions, expired subscriptions), keep going after the first match, and ask the user to pick when several match.

Stopping at the first result is the easy mistake. OpenAI researchers have shown that standard training and evaluation reward guessing over admitting uncertainty: graded on how many answers it gets right, a system is always better off taking a shot. Instructions that don’t say keep looking inherit that pull. And as with anything that changes something, nothing goes out without an explicit confirmation.

None of these decisions was new. They all existed already, scattered across habits and screen layouts. Written down, they became something a team can review and argue about.

Design the silences

The call that sends a notification returns an acknowledgement and a processing time. No recipient count: delivery happens later, to the devices that opted in.

An assistant reporting back wants to fill in the blank. “Notification sent to 3,412 subscribers” is exactly the sentence you expect at the end of a task, and nothing in the response entitles it to write it. It would have been wrong about half the time.

So the file says what the system doesn’t tell you, and the report template carries that note in plain sight. On a screen, a designer would have handled this with a status label or an empty state. For an assistant, it takes a line of text: the interface’s silences get documented along with its answers.

Name the half-done state

Publishing an article means creating it, adding paragraphs one at a time, then ordering them. Several steps, and nothing that binds them into one operation you could cancel in a single move.

The rule we wrote: if a paragraph fails after the article exists, no automatic undo. We don’t delete what exists. We stop, and we list exactly what’s missing, so the person can pick up where it broke. Undoing automatically, across steps that aren’t one transaction, means firing a second series of calls that can fail in turn, on real work. Named in the report, a half-done state takes a few minutes to fix.

In design terms, it’s an error state, written out for a reader who can’t see the screen. Every task that builds something in several steps carries it: publishing an event, assembling a gallery, launching a product. The ones that only read don’t need it.

One file, two readers

These files are a little odd. The same file is read by a person for the idea and followed by an assistant for the action. Each one has the same skeleton: the goal, the order of steps, the shape of the result with a filled-in sample report, the guardrails, and two or three related tasks to suggest next.

That last line is the one we thought least about, and the one that changed usage the most. A customer segmentation ends by offering to build the matching promotion; a weekly digest ends by offering to go look at stock levels. Taken together, the files started to read like a map of the product.

We made them public for a simple reason. Talking to your app instead of learning its screens is worth nothing if nobody knows what to say to it. I once wrote that the unit of interface was becoming a verb to define rather than a pixel to draw. Half that sentence was missing: you also have to say when the verb gets used, in what order, and what never happens without asking first.

If you design screens that an assistant will soon operate on someone’s behalf, here is a first exercise: list the decisions each screen makes on its own, the default, the options it hides, the confirmation it asks for. Those are the first lines of the assistant’s instructions.

—

Dominique Siacci, CTO at GoodBarber. I write about the architecture bets behind a no-code platform, and where AI fits in.

Originally published at dev.to on August 5, 2026.

Our screens were making decisions nobody had written down was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.