The one-line take

It wears the skin of liminal-space horror, but the actual film renders a broken inner world as physical space — a symbol, not a setting. Its biggest weakness is that the filmmakers didn’t commit to that reading.

What if almost everything is Mary’s delusion?

Here is my reading: almost everything in this film happens inside Mary’s fictional world. At minimum, the film makes far more sense watched that way.

The film’s own lore supports it. The Backrooms are described as a misremembered copy of every place that ever existed — a space that reshapes itself by projecting the memories, fears, and traumas of whoever enters. At that point the Backrooms are no longer some physical other-dimension; they are a definition of the mind itself.

• What kills Clark is not an external monster but his own warped self-image fused with the pirate mascot — Pirate Clark. The moment he faces himself, that self-image devours him. That’s a psychological drama, not a creature feature.
• The story poses as Clark’s downfall in the first half, then quietly swaps protagonists: Mary the therapist, her schizophrenic mother, the stone tied to her childhood memories, and her own entrapment in the maze at the end. A person whose job is entering other people’s mental labyrinths literally enters one.
• In the final shot, the real interrogation room where Mary sits is replicated inside the Backrooms. The film deliberately dissolves the boundary between reality and inner world as it ends.

And this is the essential question the film circles: the horror premise that “the Backrooms physically exist” is, frankly, juvenile. An alternate dimension behind the wall is a teenager’s fear. What is urgent for an adult is the fear that you yourself might be mentally breaking down — the world stays normal while you crumble (mental illness, dementia). Read this way, the film finally becomes something an adult can watch seriously.

The extension: dementia, and mental collapse as space

This reading isn’t limited to trauma or psychiatric illness. The core of the Backrooms’ dread was never the monster — it’s the cognitive dissonance of spaces no sane mind would produce: the structure of the rooms, the placement of the furniture. It resembles the fear we feel in the real world when we brush against the non-everyday — mental breakdown, dementia.

• Architecture that is itself subtly wrong
• Furniture arranged the way no one would arrange it
• The dissonance everything together gives off

This sense that space itself is wrong overlaps with first-person accounts of dementia. Dementia is not “memories disappearing” — it is the map of the world breaking down. When someone says “I want to go home” while sitting in their own house, the home they mean is not the physical one; it’s the old world inside their head. Film that sensation and you would get something very like the Backrooms. Trauma, psychiatric illness, dementia — the failure modes differ, but the structure of the fear is the same: getting lost inside your own interior space. This film gives that structure a physical form.

Why 6/10: the metaphor it refused to define

Having assembled every piece needed for that reading, the film never defines the Backrooms as a metaphor for a broken mind’s world. The Async research organization, the global spread of portals, the sequel setup — it ends with half its body still on the side of sci-fi literalism.

The result: you can’t always tell whether an ambiguity is working negative space or just something left on the floor, and the lingering haze after the credits feels less like interpretive pleasure and more like unfinished business. Fully committed as a portrayal of a broken inner world, this could have been a masterpiece. Watched as a monster movie, it’s mediocre. It stopped in between — and that’s the 6.

The REPL Analogy

LLM CLI can also be interpreted as the new REPL for agentic applications.

In the old workflow, a developer used ipython, a shell, or another REPL to understand APIs before writing production code. The REPL was where the developer discovered:

• which APIs were needed
• how the APIs behaved
• what inputs and outputs looked like
• which errors occurred
• what error handling was necessary
• what sequence of calls satisfied the requirement

After that exploration, the developer wrote a script, then extracted functions and modules.

nbdev made this workflow more explicit. Exploration is executed and recorded in a notebook, library functions are implemented after that, tests are added right after each implementation (TDD), and stable functions are exported with nbdev-export into reusable modules.

LLM CLI can be thought of as playing the same role for LLM apps. It is the place to explore the task before deciding what should become durable infrastructure.

Progressive Export

The practical development path is:

flowchart LR
  explore["Interactive<br/>LLM CLI exploration"] --> skills["LLM CLI<br/>with skills"]
  skills --> implement["LLM implements<br/>tools"]
  implement --> export["LLM exports<br/>tools to MCP"]
  export --> mcp["LLM CLI<br/>with MCP tools"]
  mcp --> app["App runtime<br/>with LLM calls"]
  app --> agent["Automated app<br/>or personal agent"]

  classDef exploration fill:#eef2ff,stroke:#4f46e5,color:#111827;
  classDef skill fill:#fff7ed,stroke:#ea580c,color:#111827;
  classDef tool fill:#f0fdf4,stroke:#16a34a,color:#111827;
  classDef appc fill:#f8fafc,stroke:#64748b,color:#111827;
  class explore exploration;
  class skills skill;
  class implement,export,mcp tool;
  class app,agent appc;

The first stage should be loose and interactive. Let the LLM try to do the whole task. This reveals the real shape of the task: what the LLM handles well, what it gets wrong, which tool calls repeat, where output needs to be structured, and where deterministic code is safer.

The next stage is skill. A skill records a reusable procedure that the LLM can follow. This is useful while the workflow is still exploratory or mostly interactive. It reduces reinvention, but the LLM still has to read the procedure, reason through it, call commands, and interpret outputs. A skill is slow and costly because it involves external LLM calls, but as a procedure written in natural language it takes little initial implementation effort.

The next stage is Tool/MCP. Once a capability becomes stable, repeated, or important for reliability, cost, or speed, it should be promoted into a typed external tool. At that point, the LLM no longer needs to carry the full procedure in context. It only needs to choose a tool and provide structured arguments.

The final app can then be small. Much of the unreliable or verbose behavior has already been exported into reliable external tools. The app replaces the interactive LLM CLI with its own LLM-call “loop”, but keeps the same task knowledge, MCP boundaries, schemas, and verification rules discovered during exploration.

The app becomes a thin harness (loop) around those tools: UI, scheduling, persistence, permissions, observability, verification, and the remaining LLM calls.

For an OpenClaw-like or Agent-Sin-like personal agent, the path becomes:

flowchart LR
  human["Human + LLM CLI<br/>explore a task"] --> skill["Repeated procedure<br/>becomes a skill"]
  skill --> mcp["Stable capability<br/>becomes MCP"]
  mcp --> intent["App calls LLM<br/>for intent / routing"]
  intent --> execution["App calls MCP tools<br/>for execution"]
  execution --> channel["Scheduler / chat channel<br/>runs without CLI"]

  classDef exploration fill:#eef2ff,stroke:#4f46e5,color:#111827;
  classDef skillc fill:#fff7ed,stroke:#ea580c,color:#111827;
  classDef tool fill:#f0fdf4,stroke:#16a34a,color:#111827;
  classDef appc fill:#f8fafc,stroke:#64748b,color:#111827;
  class human exploration;
  class skill skillc;
  class mcp,execution tool;
  class intent,channel appc;

This path is not strictly linear. Building a skill or MCP tool often reveals new edge cases, and operating an app reveals new failure modes. Those observations should loop back into LLM CLI exploration. The loop is:

flowchart LR
  explore["Explore"] --> export["Export"]
  export --> operate["Operate"]
  operate --> observe["Observe"]
  observe --> explore

  classDef loop fill:#f8fafc,stroke:#64748b,color:#111827;
  class explore,export,operate,observe loop;

What Gets Exported

The key movement is exporting work out of the LLM.

At first, interactive LLM conversation may do everything:

flowchart LR
  request["Understand request"] --> apis["Choose APIs"]
  apis --> sequence["Decide sequence"]
  sequence --> parse["Parse output"]
  parse --> errors["Handle errors"]
  errors --> summary["Summarize result"]

  classDef llm fill:#ecfeff,stroke:#0891b2,color:#111827;
  class request,apis,sequence,parse,errors,summary llm;

As the workflow matures, repeated and fragile parts move outward:

flowchart TB
  llm["LLM<br/>understand request<br/>route<br/>judge<br/>summarize"]
  skill["Skill<br/>remembered procedure<br/>for interactive use"]
  mcp["MCP<br/>typed reliable<br/>execution boundary"]
  app["App<br/>automation<br/>persistence<br/>verification<br/>UX"]

  llm --> skill
  llm --> mcp
  mcp --> app

  classDef llmc fill:#ecfeff,stroke:#0891b2,color:#111827;
  classDef skillc fill:#fff7ed,stroke:#ea580c,color:#111827;
  classDef tool fill:#f0fdf4,stroke:#16a34a,color:#111827;
  classDef appc fill:#f8fafc,stroke:#64748b,color:#111827;
  class llm llmc;
  class skill skillc;
  class mcp tool;
  class app appc;

This is harness engineering from the application side. The goal is not to eliminate the LLM. The goal is to leave the LLM with the smallest useful role and move execution, verification, persistence, and integration into deterministic components.

Export Only When It Hurts

The progression is not a rule that everything must become MCP. If an interactive LLM CLI workflow works, is used rarely, and failure is cheap, it can stay there.

Export work only when there is pressure:

• repetition: the same procedure is used often
• cost: the LLM spends too many tokens rereading or rediscovering the procedure
• reliability: mistakes are no longer acceptable
• automation: the workflow must run without a human watching
• sharing: multiple agents, apps, or people need the same capability
• security: secrets, auth, permissions, or side effects need a stronger boundary

This keeps the workflow aligned with YAGNI. Skill is often the right intermediate step because it is cheap to create and helps prove whether MCP is worth the maintenance cost.

What Stays in the LLM

The LLM should keep work where ambiguity is useful:

• understanding open-ended user intent
• routing between tools when the rules are not stable
• summarizing and explaining results
• judging tradeoffs that do not have a deterministic rule
• adapting to user-specific preferences
• handling exception patterns that are still changing

Deterministic components should take over work where consistency is more valuable than flexibility:

• repeated API calls
• parsing and validation
• authentication and secrets handling
• persistence
• verification
• retries and failure classification
• latency-sensitive or high-frequency work

This is the practical meaning of leaving the LLM with the smallest useful role.

Skill vs MCP

Skills are excellent while exploring and while a human is still in the loop. They are cheap to create, easy to edit, and close to how people naturally describe workflows.

But skills can be expensive for production app usage. A skill may consume tokens every time the LLM reads or reasons through it. It may also leave too much room for command-construction mistakes or inconsistent interpretation.

MCP is better when the capability needs to run often, run unattended, or be shared across clients. It gives the LLM a smaller and more structured interface:

tool_name(arguments) -> structured result

For an app, this matters as opex and reliability. A frequently used skill can become ongoing token cost. A frequently used MCP tool becomes a stable service boundary.

MCP also changes who can call the capability. A skill usually assumes an LLM CLI session: the LLM reads the skill, follows the procedure, and calls commands. MCP exposes a tool boundary that can be called by an LLM client, another agent, or an ordinary app. Once a capability is MCP, it no longer exists only inside an interactive LLM session.

This is the key step that allows the interactive CLI to disappear from the final product. The app does not need to run Claude Code or Codex as its user interface. It can make its own LLM call, expose the same MCP tools, validate the structured tool results, and return a response through its own UI, chat channel, or scheduler.

But replacing the CLI means the app must own the harness that the CLI used to provide implicitly:

• tool-call loop
• context injection
• permissions and approval flow
• structured output validation
• transcript and tool tracing
• error handling and retry policy
• sandbox or access boundaries

So the final app is not just a raw LLM API call. It is a small LLM runtime around MCP tools.

Structured Output Still Matters

Even after work is moved into MCP tools, some LLM calls remain. Those calls should use structured output whenever possible. Pydantic-style schemas, typed results, validation, and explicit failure states are part of the harness.

The same principle applies at every layer:

• reduce ambiguous free text
• define typed inputs and outputs
• validate results
• make failure visible
• keep the LLM’s degrees of freedom where they are useful

Observability is also part of the harness. The app should record enough information to improve the system later: tool traces, validation failures, retries, cost, latency, user corrections, and cases where the LLM needed human help.

Source Ideas

This framing connects three ideas from the harness engineering discussion:

• Tejas Kumar: reliability can improve without changing the prompt when verification and deterministic handlers are added around the model
• Shingo Irie: useful personal agents separate what should be done by LLMs from what should be done by programs
• Newbee/Nishimi: understanding cannot be outsourced, which is why the initial exploration stage is not waste

Essay Thesis

LLM CLI is the new REPL for agentic applications. We first explore the task interactively, then export repeated and fragile behavior into skills, promote stable capabilities into MCP tools, and finally replace the interactive CLI with a small app runtime that calls an LLM over those reliable tools.

The deeper change is that application development is no longer only about writing control flow directly. It is about discovering, shaping, and hardening the harness that lets an LLM operate safely over useful capabilities. The best path is progressive export: start with the LLM, keep what benefits from ambiguity, and move the rest outward only when the pressure is real. The next step, I think, is to build a mechanism that lets the LLM implement skills automatically when they are needed (to be researched).

Timing, capacity, and luck

The core of the film is a tragedy of timing: Sachi alone passes the bar exam. It is not that Tamotsu lacked ability — the order of passing was simply wrong. Had they passed together, had Tamotsu passed first, everything might have been different.

The very qualities that attracted them as lovers become the source of friction the moment their positions change. Sachi’s easygoing nature starts to look like insensitivity to Tamotsu; Tamotsu’s meticulousness starts to feel stifling to Sachi. Neither of them has changed — only the relationship is dying.

Two people locked inside a shared framework

Tamotsu’s real tragedy is not failing the bar exam year after year. It is that he shared with Sachi the framework that “passing the bar = my worth as a person.”

Inside that framework, Sachi supported him and sacrificed herself. So when Tamotsu tried to step out of the framework — toward something closer to who he actually was, like running an NPO — to Sachi it looked like the goalposts being moved, a betrayal. Because it retroactively erased the meaning of her self-sacrifice.

Tamotsu was fighting his own identity. Sachi was fighting the promise the two of them had made. They appeared to stand on the same battlefield, but they were fighting different wars.

The married friends as a mirror

The presence of a couple in their circle who did not divorce elevates the film from a divorce story to a universal question. Those friends are not portrayed as the “success case.” They too may have quietly given things up, endured things out of sight. Or maybe their trials simply arrived on a different schedule.

What the contrast conveys is that whether a relationship survives is not a function of the depth of love or the quality of the partner, but a combination of timing, capacity, and luck. That is why the film carries a universal sadness: a tragedy with no one to blame. Neither party is at fault — two unfinished people, battered by the world, exceed their capacity, wound each other, and at some point can no longer find the way back.

Knowing yourself

What stayed with me after the film is the importance of knowing what you truly need. If Tamotsu had understood earlier who he was, he might not have collapsed everything into the single point of the bar exam. He might have found happiness more flexibly, without dragging Sachi down with him.

Of course, that’s hindsight. No one fully understands themselves when they are young. Which is exactly why this story could happen to anyone — and exactly why this film hurts.

Knowing yourself is, I think, a necessary condition for happiness. Not a sufficient one. You cannot control timing or luck, but if you know what you actually need, you can at least avoid grinding yourself down on the wrong battlefield.

Yukino Kishii’s and Hio Miyazawa’s performances are what make this “no one is at fault” story hold together. Because you can empathize with both, you can save neither. After the credits, I couldn’t get up for a while.