Wayfinder Turns Foggy AI Projects Into Navigable Maps

Source: Matt Pocock · Speaker: Matt Pocock · Video ID: F3lL98Pj90o · Original title: “/wayfinder: Nothing is too big to plan anymore”

The limiting factor in AI-assisted software work is no longer whether an agent can write code; it is whether the work can be decomposed, remembered, and advanced across sessions without losing the thread. Matt Pocock’s Wayfinder reframes large projects as maps through fog: start with a destination, expose the frontier, resolve decisions, and only then turn the map into implementation.

Who Is Matt Pocock?

Matt Pocock is a TypeScript educator, developer tooling builder, and creator of AI workflow skills aimed at “real engineers.” His work is unusually practical because it starts from the habits of professional software teams — issue trackers, specs, prototypes, reviews, and implementation tickets — then adapts those fundamentals to agents instead of pretending agents remove the need for structure.

The Core Problem: Single-Session Planning Makes Ambition Smaller

Pocock’s starting frustration is familiar to anyone using coding agents seriously: most planning workflows are tied to a single session. A “grill me” or “grill with docs” session can interview the user, capture requirements, and produce a useful plan, but it still lives inside the context limits and “smart zone” of one conversation. For small work, that is enough. For large work, the user starts unconsciously shrinking the project to fit the agent.

That inversion is the warning sign. The work should not be constrained to fit AI. AI should be organized to fit the work. Wayfinder is Pocock’s answer: a skill that can orchestrate planning across multiple sessions, track dependent decisions, create parallel branches of work, and preserve the reasoning trail in an issue tracker.

Large work does not move in a straight line from idea to implementation. It moves through fog, and the job of planning is to reveal enough of the map to make the next decision safely.

The Map: Destination, Frontier, Fog, and Tickets

Wayfinder begins with a simple model. There is a start point: a vague idea or problem. There is a destination: the state the user wants to reach. Between them is fog. The first move is often a grilling session, where the AI interviews the user to establish the basic premise and definition of done. Sometimes that resolves enough uncertainty to proceed. More often, it reveals new work: a prototype, a research task, another discussion, or a real-world action.

Conceptually, those items form a map. Each item on the map is a ticket, and each ticket gets its own agent session. Wayfinder tracks the frontier — decisions that can be made now — and the fog: questions that cannot be answered until some research, prototype, or discussion happens first. As tickets resolve, the frontier moves. New tickets become available. Blocked work unblocks.

This matters because it gives AI planning a durable external memory. The agent does not need to hold the entire project in one conversation. The issue tracker becomes the map, and individual sessions become expeditions to resolve specific regions of uncertainty.

Why the Issue Tracker Is the Right Source of Truth

Pocock demonstrates Wayfinder inside a public course video manager repository, where a parent map issue contains sub-issues for decision tickets. A resolved ticket — for example, a discussion around closing clips during a publish race — writes its resolution into the ticket and also rolls a summary back up to the parent map.

The key design choice is that Wayfinder is issue-tracker agnostic. Pocock uses GitHub, but the workflow can be configured for Linear, Jira, or any tracker through setup map skills. That makes the map visible, linkable, reviewable, and recoverable by humans and agents. Instead of relying on one huge chat transcript, the project accumulates structured decisions in the same place engineering teams already coordinate work.

The issue tracker also separates two kinds of tickets that are often conflated. Wayfinder’s tickets are primarily decision tickets: research, prototypes, discussions, and tasks that resolve uncertainty. Later, after the map is complete, the team can create implementation tickets from the resulting spec.

The Four Ticket Types That Keep Planning Moving

Wayfinder’s map can contain four kinds of tickets, each designed for a different kind of uncertainty.

The prototype ticket is especially important. Pocock anticipates the objection that Wayfinder looks like heavy upfront planning, even waterfall. His answer is that prototypes are the antidote. Low-fidelity planning becomes dangerous when it floats too long without contact with reality. A prototype is a high-fidelity feedback loop: it shows what the thing could feel like before the team commits to a polished implementation.

From Map to Spec to Implementation

Once the map has resolved enough fog, Wayfinder can produce a spec. Pocock’s example is a command-K command palette in his CVM diagram window, including icon picking, searching other diagrams, copying diagram content, and saving larger chunks of work. The first Wayfinder session explored the repository, invoked the grilling skill, asked what “done” looked like, recommended a spec, and created seven tickets. Only three were immediately takable; the rest depended on earlier decisions.

After walking those tickets in separate sessions, Pocock created a spec from the map by calling “to spec.” The draft was so dense that it exceeded GitHub’s character limit, which is a useful signal: the map had captured substantial decision history rather than merely producing a shallow checklist. From there, his familiar flow continues: map to spec, spec to tickets, implementation ticket by ticket, then code review.

The improvement over older approaches is provenance. A traditional spec becomes the sole source of truth, even though it is only a summary of the conversation that produced it. A Wayfinder-generated spec links back to the original decision tickets. If an agent or human gets confused, they can inspect the primary source.

When Wayfinder Is Worth the Process

Wayfinder is not for every task. Pocock’s rule is straightforward: if the work can be planned and completed in one session, use one session. If the way to the destination is already clear, walk the path directly. Wayfinder is for work where the destination is meaningful but the route is unclear.

That includes more than coding. Pocock has used it to plan courses, engineering work, and even building a garden office: commissioning a site survey, identifying contacts, researching firms, and figuring out dependencies. The shared pattern is fog, not software. If a project needs several kinds of learning before it can be executed, a map is useful.

He also pushes back on the idea that this is traditional spec-driven development. In his framing, a spec is just a destination document for multi-session work. It does not need to live forever. Once the spec is represented in the code, the issue containing the spec can be closed and effectively discarded. The enduring artifact is the built system, not a permanently maintained requirements document.

Key Lessons

Why This Matters for Diffie

For Anand and Diffie, Wayfinder’s most relevant idea is that AI products need workflow architecture, not just model capability. Diffie is selling into frontend teams whose real pain is not “we need another AI tool.” Their pain is that modern UI work creates fog: product intent, visual behavior, browser-specific bugs, design-system constraints, regression risk, and release timing all interact. A tool that merely runs tests is useful; a tool that helps teams navigate uncertainty around releases is much more strategic.

This suggests a sharper ICP and GTM angle. Diffie should look for teams where frontend changes are large enough that single-session/manual QA breaks down: complex dashboards, design-system migrations, AI UI surfaces, multi-role workflows, and high-frequency releases. Those teams need something like a release map: what changed, what must be verified, what is blocked, what evidence exists, and where risk remains foggy.

The outbound message can borrow Wayfinder’s language without copying the product. Instead of “AI browser testing,” lead with the buyer’s felt problem: “Your frontend release has too much fog for manual QA and too much surface area for brittle scripts.” Then show how Diffie clears the frontier: it explores flows, captures evidence, turns ambiguous risk into concrete failures or confidence, and gives engineering attention back to the team.

There is also a product lesson. Diffie’s output should not be a disconnected report that dies after one run. The most valuable artifact may be a durable, linked decision trail: what was tested, what changed, what failed, what got fixed, and what remains unverified. Wayfinder’s issue-tracker design is a useful analogy. If Diffie can write confidence and uncertainty back into GitHub, Linear, or the pull request itself, it becomes part of the team’s operating system rather than a separate QA dashboard.