Main idea

Faced with a tool you want to make write elsewhere — for instance a conversational assistant toward a personal server — the spontaneous question is: how do I get it to call my service? That leads to building an interface, then observing that it cannot be called, then looking for a workaround.

The other question, put in its place, changes the ground: where does this tool already know how to write? It no longer asks you to open a path, it asks you to inventory the ones that exist. The answer may be a spreadsheet, a file space, an already connected service — something mediocre from the point of view of the intended architecture, but available immediately.

The first question bears on an obstacle, the second on a resource.

Why it matters

It is a cheap switch: it costs only a rephrasing, and it comes at the moment you are most boxed in — after a technical failure, when the energy goes toward the workaround.

It also produces a result of a different nature. What you get isn't the architecture you wanted, but a path that works right away and that you will be able to replace later.

Nuances and limits

The inventory of existing paths may be empty, and the question then stays unanswered.

And what it yields is a compromise: accepting a tool you wouldn't have chosen, with its limits. The risk is settling into it for good instead of treating it as a stage.

Open questions

• At what point do you decide a workaround path has become the definitive architecture?