A Six-Cell Strategy for Working with AI: From the Four Quadrants to a 3×2 for Vibe Coding

This article started with a short video by Dr. Xiaohui on Xiaohongshu: The Four Quadrants of Working Effectively with AI. The video sorts prompts to AI into four kinds: known knowns (Express), known unknowns (Ask), unknown knowns (Iterate), and unknown unknowns (Explore). It also makes a key observation: most people only work on Express, while the real ceiling of the collaboration is set by the other three. Those three cannot be reached by writing one perfect prompt; they can only be drawn out inside a collaboration loop.

The quadrants themselves have an upstream source. The video's author mentions they come from a talk by an Anthropic researcher. That researcher is Thariq Shihipar, a member of Anthropic's technical staff, and the original piece is A Field Guide to Claude Fable 5: Finding your unknowns, published on Anthropic's official blog on 2026-07-06. I will come back to this primary source below.

Inspired by this, I wanted to move the framework from the prompt level to the project level: what information is missing in one collaboration session is one question; what model, what harness, and what verification method a project should be equipped with is another. That is how the 3×2, six-cell framework below came about.

From four quadrants to 3×2: adding a capability dimension

First, a point that is easy to confuse: the dimensions in this article are not the same pair of axes as the original quadrants. The relationship is inspiration, not mapping. Shihipar's two axes are whether you are aware × whether you possess, and what they classify is the information inside a prompt: an epistemic state. My axes are goal clarity, method clarity, and capability, and what they classify are properties of the project task itself.

For example, the entire cell “goal clear but method unclear” is, in his framework, just one known unknown: you are aware that you do not know the method. So the 3×2 below is not an upgraded version of the quadrants; it swaps the lens from your epistemic state about the information to the resource state of the task.

In real vibe-coding projects, one more layer needs to be split apart: knowing the method and being able to execute the method are two different things.

An example: a senior database expert and a novice who has only briefly touched databases both know they need to build a database. The expert can complete it end to end without AI; the novice can barely move without AI. Facing AI, the two of them have completely different prompt states and need completely different collaboration styles.

So the framework becomes three dimensions and six cells. First: is the goal clear? That determines what you iterate on. With a clear goal you iterate on implementation; with a vague goal you iterate on the goal itself. Second: is the method clear? That determines who decides the technical approach: you decide, or AI proposes and you choose at the level of consequences. Third: is your capability sufficient? That determines your means of verification. With sufficient capability you can verify by reading code; without it you can only verify by observing behavior, such as tests, previews, and run results.

The third point matters most. Insufficient capability does not change what the AI should do; what it changes is that your quality control must drop from the code level to the behavior level. The whole harness has to be configured around making behavior observable.

The six-cell matrix reads like this: clear goal, clear method, sufficient capability is ① Efficiency mode; clear goal, clear method, insufficient capability is ② Apprentice mode; clear goal, unclear method is ③ Client mode; unclear goal, clear method, sufficient capability is ④ do not start here, go to ⑥; unclear goal, clear method, insufficient capability is ⑤ do not start here, go to ⑥; unclear goal, unclear method is ⑥ Goal-clarification loop.

Note that the two rows differ in kind: the top row contains working modes; the bottom row contains states and routing. Only ⑥ is a place where real work can start. ④ and ⑤ are states you discover yourself in, and the only action there is to merge into ⑥. Once ⑥ finishes and the goal converges, you land back in ①②③ for delivery according to your method and capability at that moment.

The six cells in detail

① Efficiency mode: you could do it yourself; AI saves labor.

In efficiency mode, model choice can prioritize cost-effectiveness because you can backstop and correct mistakes. The harness can have high autonomy: auto-accept edits, run multiple tasks in parallel, use tests and lint as automatic gates, and write a detailed CLAUDE.md to lock in your code style.

The prompt style is to hand over a detailed requirements document and acceptance criteria in one shot, then delegate in batches. Your role is reviewer. The biggest trap is over-reviewing: the time you saved flows right back out. Learn to review only interfaces and critical paths.

② Apprentice mode: you know how it should be done, but cannot write it fluently.

In apprentice mode, use a strong model. The logic is the opposite of ①: you cannot catch its mistakes, so you must lower the probability that it makes them. The harness should be low-autonomy. Turn on Plan mode to see the plan first, and confirm edits step by step. Ask the AI to attach a why-it-is-written-this-way explanation to every change. This can be locked into settings or CLAUDE.md.

Verification also changes: since you cannot fully read the code, move your judgment onto observable behavior. Run every small step and look at the result. The extra output is a learning note maintained by the AI along the way. This is the core difference between ② and ③: you are buying capability, not just results.

This connects directly to a technique in Thariq Shihipar's original piece: the structured interview. Let Claude interrogate the ambiguities in your requirements one by one, prioritizing questions whose answers would change the architecture. For someone in apprentice mode, the value runs both ways: the AI clarifies the requirements, and being interrogated fills knowledge gaps you had not noticed in yourself.

One fork to decide in advance: is this capability worth learning? For a stack you will keep using, take apprentice mode: slow but compounding. For a one-off task, downgrade it to ③: fast but non-compounding. Many people stuck in the pain of ② simply have not realized that choosing not to learn is an option.

③ Client mode: you know what you want, not how to build it.

In client mode, the model choice is strong model plus Plan mode. Have the AI propose two or three technical approaches first. You do not choose at the technical level; you choose at the level of consequences: maintenance cost, deployment difficulty, and compatibility with your existing tools.

The harness should focus on short feedback loops: a preview server, browser tools, screenshot comparison. Your acceptance surface is the rendered result, not the code. The prompt should use user language, not technical language. Give reference sites, screenshots, or hand-drawn sketches. One reference image often saves several rounds of text back-and-forth. That is the key workflow saving.

Write the acceptance criteria in advance, in a form you can check yourself: “opens on a phone without horizontal scrolling,” not “responsive layout.”

Shihipar's structured interview is a core technique in this cell too. The biggest risk of client mode is the unknown knowns: implicit standards so obvious to you that you would never write them into the requirements, such as taste, layout preferences, or an interaction that must never appear. Rather than hoping to write them all down in one pass, let the AI actively ask them out of you. Combine that with another of his suggestions, collecting reference code and reference works, and the implicit standards surface at minimal cost.

The rule for the bottom row: no construction in ④⑤; always route through ⑥ first

The three bottom cells share one fact: the goal is unclear. Writing code toward delivery while the goal is unclear mostly produces waste. So here is a hard rule: ④ and ⑤ are for state recognition only, not construction. When you find yourself in these cells, the only action is to explicitly switch into ⑥'s goal-clarification loop.

The most dangerous thing about ④⑤ is precisely that they look ready to start. The person in ④ is holding a hammer and easily starts swinging, building something nobody wants. The person in ⑤ tends to end up with a half-learned stack and a product nobody wants, losing on both ends. Differences in method and capability do not change the ⑥-first routing; they only change the cost of running ⑥.

④, method clear and capability sufficient: you can prototype quickly yourself, so the clarification loop runs fast and cheap. Focus the prompt on describing your assets and boundaries, such as what data, skills, and audience you have. Let the AI propose a candidate list of goals those assets could unlock, then test them one by one with throwaway prototypes.

⑤, method clear and capability insufficient: let AI do all the prototyping, and freeze learning. Until the goal stabilizes, do not invest in learning any stack. Learning is currently the only cost AI has not deflated. Do not spend it on a direction that may be falsified.

⑥ The goal-clarification loop: the only working mode in the bottom row

⑥'s deliverable is not a product; it is a clarified goal. Starting to build here is legitimate, because after the collapse of construction costs, building has turned from a means of execution into a means of cognition. You cannot meditate your way to knowing what you want, but given a few clickable prototypes, you know within ten seconds which one is wrong.

Judgment is the only thing that cannot be outsourced. Before entering the loop, write down what counts as good as an explicit standard, however rough. Even “I would want to share this with someone” works. Without a yardstick, the loop will not converge.

The harness setup is: use a strong model to generate multiple variants in parallel, then you rank and eliminate, then synthesize. You act only as selection pressure. Note that ①'s cost-effectiveness logic does not apply here. In the exploration phase the bottleneck is the heuristic quality of each prototype, not the quantity. The diversity a weak model offers is diversity within a low-quality region, and this is exactly the moment when your own input is weakest and you most need model quality to raise the ceiling. The extra tokens spent exploring are negligible against the cost of heading in the wrong direction.

This loop has a ceiling: the ceiling of your input sets the ceiling of the output. The model explores around the context you provide; it can hardly reach the frontier of a domain entirely unknown to you. It illuminates the range your judgment can recognize. The mitigation is to expand the input from just yourself to the outside world: have the model bring in domain benchmarks, competing products, and real user feedback as reference points, instead of only making variants within your description.

All code is disposable by default. What deserves keeping is the conclusion notes: which directions were falsified, and why.

The exit condition is: when you can write the goal as a requirement you can accept yourself, even at the behavior level, such as “opens on a phone without horizontal scrolling,” the loop ends, and you land back in ①②③ for delivery according to your method and capability at that moment.

This cell corresponds to the Unknown Unknowns quadrant in Shihipar's piece. His advice is to run a blind-spot pass before starting: have Claude generate a few drastically different directions, for example as HTML artifacts. You are not picking an answer; you are using your own reactions to probe the boundary of the problem space.

Two observations across cells

First, cells are dynamic. Projects migrate, and the migration has a fixed route. The typical path is: ④/⑤, recognizing that the goal is unclear; then ⑥, the clarification loop converges on a goal; then ③ or ②, the method becomes clear during delivery; then ①, capability catches up after doing the same kind of thing repeatedly. Strategy is not set once at project start. At every stage you re-ask: which cell am I in now? Be especially wary of unknowingly starting construction in ④⑤. That self-check question deserves a place in your workflow.

Second, the two frameworks govern different levels and complement each other. Shihipar's quadrants, and Dr. Xiaohui's Express / Ask / Iterate / Explore version, govern information clarification within a single collaboration. This article's 3×2 governs project-level strategy selection. First use the six cells to fix the model, harness, and verification method; then, in each concrete collaboration, use the quadrants to check for information gaps.

Sources

Primary source: Thariq Shihipar (Anthropic), A Field Guide to Claude Fable 5: Finding your unknowns, 2026-07-06. Core claim: in the Fable 5 era, the bottleneck on output quality is your ability to clarify your own unknowns; the prompt is the map, the codebase is the territory, and the gap between them is the unknowns.

Secondary source: Dr. Xiaohui, The Four Quadrants of Working Effectively with AI, Xiaohongshu.