After experiencing the viral gameplay of Fable 5, I realized I got the very first step of using AI wrong

After Fable 5's comeback, a wave of creative use cases has gone viral online. Every time people see a new one, they can't help but wonder: Why didn't I think of using it that way?

A recent popular creation is the Tom Riddle Diary inspired by Harry Potter, where a developer modified their reMarkable tablet into a magical journal using Fable 5. When you write prompts on the paper, the text automatically fades out, and the AI's response slowly fades in, appearing on the page as if by magic.

This video has already amassed millions of views on X. Other users quickly replicated a similar function on iPad: they used AI to generate a single HTML file that opens directly into a magical notebook, where writing prompts on the screen triggers a magical-style response.

Another trending use case comes from Ammaar Reshi, Head of Product and Design for Google AI Studio, who built a game with Fable 5. He successfully ported the 2003 game *Command & Conquer: Generals – Zero Hour* to iPhone and iPad without using any emulator.

Even the head of Claude Code left a comment expressing surprise. Ammaar shared the full implementation experience in his open-source GitHub repository, detailing how to run the game on your own iOS device, his development journey, and the remaining issues with the project.

Even more fascinating is the "Fable 5 Self-Portrait" that has gained over 3 million views. A user asked Fable 5 to show its most expressive form.

Instead of using any existing video generator, Fable 5 wrote its own rendering engine in the computer terminal, synthesized its own voice, and built a generative ASCII encoding engine from scratch to depict its most expressive form.

When some users questioned whether Fable 5 was actually involved in the process, the creator shared the simple prompt: "Hey Fable, use ASCII characters, through voice, audio, and animation, make a short video to express your truest inner world."

Fable 5 has fully demonstrated its power in widening the gap between different AI users.

Even with basic use cases, some people can use Fable 5 to create a game that is almost ready for public release. Starting from the initial concept, game art, 3D models to coding, a user perfectly cloned *Subway Surfers* in Rork using Fable 5, with a total development time of just 1 hour.

As model capabilities improve, users who know how to leverage the model, write better prompts, apply more refined Skills, and choose appropriate frameworks will achieve far better results than most other users running the same Fable 5.

Being able to use Fable 5 at all is a basic threshold, but being proficient in using Fable 5 creates an even more obvious performance gap.

A Y Combinator partner posted on X saying Fable is extremely powerful, and commenters pointed out that what he has experienced is only the tip of the iceberg.

A Claude Code engineer posted on X a few days ago, focusing on the topic of how to break through productivity bottlenecks when using advanced AI models, using Claude Fable 5 as an example, by "mapping out unknown territories".

In our view, this methodology can be applied not only to Fable 5, but also to the most powerful models we have access to, helping us tap into the model's full potential while discovering our own capabilities.

Original article link: https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns

The Map Is Not the Territory

This philosophical concept from the 1930s, a famous "semantic proposition", describes the inherent difference between our perception and real-world reality.

Just as a map cannot fully capture all the details and complexity of the real world, our descriptions of things are only simplified abstractions, which usually cannot accurately reflect the full picture of the external world.

APPSO shared our reflections during the period when AI models were being released rapidly, mentioning a similar viewpoint.

In the current context of AI development, the prompts, skills, context we feed to AI, and more detailed requirement specifications, are all just "maps" — our descriptions of the task at hand.

The complex codebase, real-world business scenarios, practical constraints, and operational rules are the actual "territory".

Between the "map" and the "territory" lie all kinds of unknowns. If you give a navigation system a route map, it can tell you how to get from point A to point B, but road conditions and other on-site details cannot be fully covered by a single prompt.

When we practice Vibe Coding and input a prompt like "Help me make an editor toolbar", Claude will discover during execution: how to reuse existing components, where to place buttons, how to store state, whether elements will crowd each other out on mobile, and whether you prefer a minimalist design or a feature-dense layout.

Even if your prompt describes the task in great detail, it is only a compressed version of the full work. The real details will only be exposed during Claude's execution process.

These details are called Unknowns: unknown items or blank areas. Some of these blanks we are aware of, some are standards we have in mind but cannot clearly describe, and others are gaps we do not even realize exist.

Specifically, based on real-world AI collaboration experience, Claude Code engineers categorize these unknowns into four quadrants:

• Known Knowns: The requirements clearly written in our prompts.
• Known Unknowns: Issues we realize we do not yet understand, and need to investigate or make decisions about.
• Unknown Knowns: Intuitions we take for granted, too obvious to write in documents, but can immediately judge when we see them — such as hidden aesthetic preferences or muscle memory.
• Unknown Unknowns: Blind spots we do not even realize exist, things we do not know we do not know.

The more powerful the model is, the more these unknowns are amplified.

In the past, we often thought AI tools were not useful because they were "not smart enough" and the code they wrote contained bugs. But with the Claude Fable 5 generation, a new reality has emerged:

The ultimate bottleneck hindering project progress is no longer the AI's code compilation ability, but the human ability to discover and clarify our own "unknowns".

In other words, do not rush to throw requirements at AI — first help it identify the parts you did not explain clearly, and the details you have not fully thought through yourself.

How to Expose Unknowns

In the past, the most common tip for AI usage was to write prompts clearly, specifically, and completely.

With more capable models, the problem has become more nuanced. Instead of writing longer and longer instructions, we should apply targeted practical skills and prompt templates before development, during the development process, and after development is completed.

Show Me 10 Demos First

If we are entering an unfamiliar code module, or using a framework we have never touched before, the smartest approach is to directly say to Claude:

I am about to integrate a new authentication module, but I know nothing about the authentication logic in this codebase. Please help me perform a "Blind Spot Pass" to find the "Unknown Unknowns" I haven't realized yet, and teach me how to ask you better questions.

For those hard-to-articulate "Unknown Knowns", do not let AI modify production code directly. First ask it to generate independent HTML pages with mock data.

For example, when doing front-end design, many engineers struggle to describe their ideal interface in specific words, but they can immediately point out flaws once they see the finished product.

In this scenario, we can tell AI:

I want to build a data dashboard, but I have no eye for design. Please generate an HTML page with 4 completely different design directions, so I can get a clear sense of what works.

This is not a waste of computing resources. The core logic of exposing unknowns is to use extremely low-cost trial and error, avoiding the expensive cost of fixing errors in core code.

Through low-cost HTML prototypes in pre-development demos, we can align mutual expectations, and bring our implicit judgments in our minds to the surface.

When the task will affect the overall architecture, it is best to let AI interview us in reverse, to clarify our vague ideas.

Ask questions whose answers will change the solution — for example, whether data is stored on the front end or back end, permissions are tied to users or teams, and a certain process is completed in one step or split into approval stages.

Please act like an interviewer, asking me only one question at a time, to help me clarify the ambiguous parts of the requirements. Prioritize key questions that will affect architectural design.

If you still can't express your needs clearly, you can even feed excellent existing source code or cases (even in different programming languages) to AI, and ask it to replicate the design with pixel-level accuracy.

When you are almost ready to start full development, ask AI to write an implementation plan, and put the critical parts that require your decision — such as data models, interface definitions, and UI workflows — at the top for review, leaving mechanical refactoring work for later.

Loop Engineering and Harness Engineering

In the real-world "territory", even the most perfect plan will encounter various edge cases that deviate from the original design.

During the execution of most long-cycle tasks, a smart Agent will continuously discover potential issues in the task — for example, a third-party library is incompatible, or an interface's response speed slows down. At these moments, AI needs to make independent decisions.

Without proper safeguards, after AI runs for an hour, we can only see which files were modified, but not why the changes were made. AI's self-correction may solve the immediate problem, but it could also quietly plant hidden bugs we are completely unaware of.