The Chair Test: Why Believable Futures and Better Code Reviews Start by Preserving What Works

What makes a future feel real, or a software system feel understandable? Surprisingly, the answer may be the same: the future must respect what already works.

A believable science fiction world does not redesign every familiar object merely to signal that time has passed. A chair may remain a chair because the human body has not changed, gravity has not changed, and sitting still solves the same problem. Likewise, an intelligent review of a codebase does not begin by proposing an entirely new architecture. It first asks what the existing system is already doing, why it does it that way, and which constraints are more important than they appear.

These are not just parallel examples. They reveal a general principle about design, prediction, and intelligence: the most convincing improvements are usually conservative about fundamentals and radical about relationships. They leave stable necessities alone while changing how those necessities interact.

The uncanny valley of unnecessary novelty

We often recognize bad futurism through an excess of invention. Every object has a glowing interface. Every routine has been automated. Familiar things have received futuristic names without acquiring a meaningful reason to exist differently.

Imagine a novel set in the year 2400 that describes a “personal ergonomic repose platform” and then explains that people use it to sit down. The problem is not that the object is technically impossible. The problem is that nothing in the surrounding world justifies the change. The author has mistaken elapsed time for progress.

The same mistake appears in technology products. A company may announce a revolutionary workspace, a new programming framework, or an autonomous vehicle feature whose main evidence of advancement is that it replaces ordinary language with an elaborate interface. A chair becomes a “dynamic posture optimization system.” A simple configuration file becomes a visual orchestration layer. A code review becomes a cascade of suggestions to rewrite everything.

This is novelty as decoration. It adds visible difference without adding functional necessity.

The more convincing alternative is continuity with selective transformation. In a plausible future, most objects remain boring because most problems are already solved adequately. Change concentrates where the old arrangements create friction, risk, or new possibilities. The chair stays recognizable, but perhaps it adjusts itself for an injured person, monitors circulation in a hospital, or folds into a spacecraft where every cubic centimeter matters. Its identity persists while its relationships change.

That distinction matters because people do not experience systems as collections of features. They experience them as environments. An environment feels credible when its parts appear to have evolved in response to real pressures.

A believable system is not one in which everything is new. It is one in which every important change has a reason.

Codebases are historical artifacts, not blank canvases

A mature codebase is much closer to a city than to a blank sheet of paper. It contains deliberate structures, abandoned roads, temporary scaffolding that became permanent, and peculiar shortcuts that make sense only when you know the history of the neighborhood.

When someone asks for a high level explanation of how a codebase works, the real request is rarely a tour of folders and functions. They want a mental model: where the system receives information, how it transforms that information, where decisions are made, what it stores, and how results move back into the world.

That model must account for more than explicit design. It must include the invisible forces that shaped the system: deadlines, compatibility requirements, old data formats, deployment limitations, team boundaries, and failures that happened often enough to produce defensive code. A strange function may be a design flaw. It may also be a treaty with a legacy client that no one dares to break.

This is why the best first step in software work is often not construction but reconnaissance. Before suggesting next steps, an intelligent reviewer needs to identify:

1. The system’s stable necessities: what must remain true for users, operators, or neighboring systems.
2. The system’s major flows: how an input becomes an output, including the points where state changes or decisions occur.
3. The system’s seams: where components communicate and where failures can spread.
4. The system’s historical residue: duplicated logic, compatibility layers, temporary fixes, and conventions that no longer have obvious owners.
5. The system’s unrealized capacity: capabilities already present but poorly exposed, documented, or connected.

Only then do recommendations become meaningful. Otherwise, “next steps” are often a disguised preference for the reviewer’s favorite architecture.

A codebase can be improved in many ways, but the first question should not be, “What would I build?” It should be, “What is this system already trying to be?”

That question protects against a common failure of both human and artificial intelligence: confusing unfamiliarity with dysfunction. A system may look inelegant because it is carrying obligations that are invisible from a narrow view. Good analysis makes those obligations visible before judging them.

The chair test for intelligent design

We can turn the connection between believable futures and code review into a practical test. Call it the chair test:

Before changing a familiar component, ask whether its basic form is constrained by reality, or merely inherited by habit.

A chair’s basic function is constrained by anatomy and physics. Its materials, dimensions, sensors, and context can change dramatically, but the core affordance is stable. A codebase contains similar elements. Authentication, persistence, error reporting, input validation, and deployment may have familiar forms because they serve enduring operational needs. Replacing them wholesale may create activity without improvement.

Other parts are less fundamental. A manual approval process may exist only because no one has connected two systems. A repetitive data transformation may be a leftover from an earlier storage model. A command line interface may remain the best tool for experts, while a small visual layer could make it accessible to everyone else. These are opportunities for transformation because their current shape is not dictated by the underlying problem.

The chair test therefore separates a system into two categories:

1. Invariants

These are the things that should change slowly because they express deep constraints. Examples include the need to preserve user trust, maintain data integrity, support recovery after failure, or provide a comprehensible path from action to consequence.

2. Accidents

These are things that exist because of history rather than necessity. Examples include arbitrary naming conventions, duplicated adapters, manual handoffs, outdated abstractions, or interfaces designed around the limitations of a tool that has since disappeared.

The danger is that accidents often look more visible than invariants. A developer sees an awkward module and wants to replace it. A futurist sees an ordinary chair and wants to redesign it. But visible awkwardness is not proof of conceptual importance. Sometimes the awkward component is merely a removable shell around a sound underlying function.

The most valuable redesigns preserve invariants while removing accidents. They do not ask every part to become futuristic. They ask which parts are preventing the whole system from adapting.

Why “next steps” should follow explanation

There is a subtle sequence hidden in the request to review a codebase, explain it, and then suggest what to do next. The order is not administrative. It expresses a theory of responsible change.

Explanation comes before optimization because optimization depends on the objective. If you do not know what the system is for, you cannot tell whether complexity is waste or protection. If you do not know where a boundary lies, you cannot tell whether moving it will simplify the system or merely transfer complexity elsewhere.

Consider an online payment service. A reviewer might notice that several components perform similar validation and recommend consolidating them. That could reduce duplication. But if one validator protects an internal API, another handles untrusted browser input, and a third enforces rules required by a payment provider, merging them may erase distinctions that keep the system safe.

The same principle applies to imagined futures. A believable future does not remove familiar objects simply because they are old. It understands the problem each object solves, then explores what new conditions alter the solution.

This produces a useful design sequence:

1. Describe the current world accurately.
2. Identify the pressures that make change necessary.
3. Separate essential constraints from historical accidents.
4. Change the smallest number of assumptions required.
5. Observe the new consequences before expanding the redesign.

This sequence is deliberately less dramatic than a total reinvention. Its advantage is that it makes causality legible. When a change works, you can understand why. When it fails, you know which assumption to revisit.

For AI systems, this discipline is especially important. An AI can generate plausible code, architecture diagrams, product concepts, and future scenarios at extraordinary speed. But plausibility is not understanding. The ability to produce many alternatives can hide the absence of a model of the existing world.

An AI that immediately proposes a new framework may be exhibiting verbal fluency rather than intelligence. An AI that can explain why the current framework exists, identify its constraints, and recommend one targeted change is demonstrating something more valuable: situated judgment.

Radical change belongs at the level of relationships

If fundamentals should often remain stable, where should innovation happen? The answer is usually in the relationships among stable parts.

A chair becomes more powerful not when it stops being a chair, but when it connects to a new context. It may become part of a medical monitoring system, an adaptive workplace, or a compact habitat. Similarly, a database, an API, and a user interface may each remain recognizable while a new connection among them eliminates hours of manual work.

This is a general pattern of technological progress. The internet did not make documents cease to be documents. It changed who could access them, how quickly they could circulate, and how they could link to one another. Smartphones did not eliminate cameras, maps, calendars, or telephones. They recombined them into a device whose value came from their proximity and coordination.

The deepest opportunities in a codebase often look like this. They are not missing features in isolation. They are missing relationships:

• A logging system that records events but does not connect them to deploys.
• A customer database that stores history but does not expose it at the moment of support.
• A test suite that catches regressions but does not run against the environments where failures actually occur.
• An internal tool that contains valuable operations but forces every user to understand the underlying implementation.

In each case, the parts may be adequate. The system is weak because the parts cannot cooperate effectively.

This suggests a sharper definition of innovation:

Innovation is often not the invention of a new object. It is the discovery of a new relationship between objects whose individual purposes were already understood.

That definition also explains why some futuristic products feel fake. They announce new objects while leaving the old relationships intact. A polished interface does not matter if the underlying workflow still requires the same ten manual handoffs. A robot that looks advanced but cannot navigate the social and physical constraints of a household is less useful than an ordinary appliance integrated thoughtfully into daily life.

A practical method for better reviews and better futures

The combined lesson can be applied to software planning, product design, organizational change, and even personal projects. Use a four layer review before proposing transformation.

Layer one: The surface

What does the user or operator encounter? List the visible actions, outputs, delays, confusions, and workarounds. Do not yet explain them.

Layer two: The mechanism

Trace the actual flow beneath the surface. Where does data enter? Where is it transformed? Which component owns each decision? What happens when something fails?

Layer three: The constraint

For every awkward feature, ask what might require it to exist. Is it protecting compatibility, security, latency, reversibility, or trust? Treat every strange thing as evidence before treating it as a mistake.

Layer four: The relationship

Look for high leverage connections. Which existing capabilities are isolated? Where does information become unavailable precisely when it would be useful? Which handoff could disappear if two already adequate components were allowed to communicate?

At the end, recommendations should be expressed as hypotheses rather than proclamations. Instead of saying, “Rewrite the service,” say, “If the duplicated transformation exists only because the old storage format is still supported, introducing a translation boundary may let us remove one copy without changing external behavior.”

That sentence is less exciting, but it is testable. It preserves what may be essential, identifies the assumption behind the improvement, and gives the team a way to learn.

Key Takeaways

• Explain before you optimize. Build a reliable mental model of a system before recommending structural change.
• Use the chair test. Distinguish constraints imposed by reality from habits inherited from history.
• Preserve invariants, remove accidents. Keep trust, integrity, recoverability, and clear responsibility stable while challenging needless complexity.
• Search for missing relationships. The largest gains may come from connecting existing capabilities rather than adding new ones.
• Make changes as hypotheses. State what you believe, why you believe it, and what evidence would prove you wrong.

The mature imagination is not the ability to make everything strange. It is the ability to see which familiar things deserve to remain familiar, and why.

A chair in the future can still be a chair. A codebase can retain its old language, its familiar data model, or its unglamorous operational routines. What matters is not whether the surface looks new. What matters is whether the system has become more responsive to the pressures around it.

The future, in software and in fiction, becomes believable when it remembers the past without being trapped by it. The best intelligence does not erase the world before acting. It studies the world closely enough to know where a small change can reorganize everything.