From Design Fiction to a Working Tool

A future scenario can leave a reader with a pleasant problem. The imagined system is vivid enough to discuss but has no handle, so it waits at a comfortable distance while the working day continues with its small, stubborn tasks and not one of them has agreed to become speculative.

One practical architecture closes that distance by pairing each future scenario with pseudocode—a plain algorithmic description without commitment to a programming language—and a detailed prompt for an agentic development platform. Together they describe what I call an ancestor tool, a smaller current system that carries part of the future system’s purpose without pretending to be the finished future.

That sequence matters because speculation becomes useful only when it changes the next available action. A future-facing exercise can identify a capability worth wanting. Pseudocode can show the operations that capability would require. A prompt can turn those operations into a request that a present-day platform may help a practitioner develop. The final system will not be the imagined future technology. It is not meant to be. It is a foundation with a visible lineage.

The future scenario needs a near-term relative

Design fiction works by placing an imagined technology in a situation where its consequences can be examined. It can expose a question that ordinary planning has kept out of view. What would people need to preserve? Which judgment would still require a person? What kind of record would have to exist before a system could act responsibly?

Those questions are valuable, yet they do not automatically yield a build. The technical section supplies the missing middle. It asks what the speculative technology’s earlier, limited version would do with the tools available now. That version may automate a ten-minute task described in the chapter and extend toward the larger process around it.

The phrase “ancestor tool” is exact here, I think. An ancestor has a relation to what follows without being a disguised copy of the later thing; a current tool may collect, organize, or analyze information more narrowly, require more human attention, and operate over fewer sources than the speculative system. Those limits do not weaken the exercise. They reveal where the work actually begins.

Pseudocode keeps the logic visible

Pseudocode describes computational logic in ordinary structural terms. It can state what a system receives, what it examines, what it produces, and what happens when a condition changes, without requiring a reader to know the syntax of a particular programming language.

That is useful in knowledge management because the practitioner may understand the process before they understand the implementation. They may know that a tool should accept a record, identify a condition, create a useful result, and retain enough context for later review. The pseudocode gives that sequence a form that can be inspected and questioned.

It also prevents a familiar kind of hand-waving. A future claim can sound persuasive when the operations inside it remain hidden. Once the operations are named, a reader can ask whether the inputs exist, whether the outputs would help, and where the system needs human judgment. The question becomes practical. It is no longer whether the future tool would be impressive. It is whether its smaller ancestor can do a defined job.

Natural language is part of the build path

The paired prompts address agentic development platforms such as Cursor, Claude Artifacts, or v0. The point is not that a prompt erases technical difficulty. It is that natural-language descriptions and language-agnostic logic can let a knowledge management practitioner request a working foundational system without first becoming a conventional programmer.

That access changes who can participate in implementation. A practitioner can describe the problem, inspect the proposed logic, and use the platform to generate a first working version. The platform does not make every decision trustworthy by itself. It gives the practitioner another way to move from a well-specified process to a system that can be tested.

The boundary remains important. A generated tool has to be checked against the work it is meant to support. The pseudocode is useful precisely because it leaves the intended logic available for review. A practitioner can compare the result against the steps, revise the prompt, and see where the implementation has wandered from the process.

Build the small version that changes the task

The first builds should automate ten-minute fixes while supporting the broader processes around them. This is a disciplined starting point. A short, concrete task has a defined scale. It gives a current system something specific to do, and it gives a person something specific to evaluate.

The resulting tool may be modest. It may not possess the imagined system’s full range, autonomy, or reach. It can still matter because it makes a recurring piece of work easier to perform, inspect, or continue. As capabilities expand, that tool can evolve. Its relation to the design fiction remains visible because the original scenario and the ancestor logic were kept together.

Speculation does not have to float above implementation. Pair the future scenario with visible logic, build the smallest ancestor that changes a real ten-minute task, and then let that modest tool argue back. Its failures and usefulness will tell us more about what the future claim must eventually answer than another page describing how impressive the imagined system will be.