One map of the code, for engineers and agents

Navigate code by meaning,
not text.

Poka Yoke gives engineers and coding agents the same resolved map of the code — and of what it does at runtime. Deterministic static graph, live telemetry overlay, and an MCP surface both can query.

Free for individual use · Source-available alpha · Runs locally on your machine

Why it exists

Text search finds strings. It does not find structure.

Coding agents spend most of their budget discovering what already exists — call chains, overrides, interface implementors — and re-discovering it after every edit. On a small script, that works. On a large, complex codebase, it quietly drifts.

One resolved map

Static structure and live telemetry are correlated to the same node IDs, so a trace lands on a real function, not on a string that happened to match.

Agent-free generation

Compile-based graph generation. Same code, same graph, same IDs — no tokens spent, no drift between runs. Regenerating costs nothing.

MCP tools, not dumps

Agents query the graph directly — callers, callees, path-trace, type hierarchy — instead of reading the whole codebase into a prompt.

“Static analysis is incomplete by nature. The best published Python call-graph tool reports about 99% precision and 70% recall. Poka Yoke reports what it cannot resolve instead of guessing.”

How it fits together

One graph. One telemetry stream. Two audiences.

People use it through the visualizer; agents use it through MCP. The same artifacts sit underneath both.

Source Code, AIDL, Gradle
Static graph Stable node IDs
Overlay Live telemetry
Visualizer For humans
MCP For agents

For humans

  • Filter large graphs without losing the plot
  • See a live trace rendered on the same view as the structure
  • Inspect call sites, parameters, imports, data definitions
  • Unresolved edges drawn differently from resolved ones

For agents

  • symbol.search, callers.get, path.trace
  • Plan against stable node IDs that survive edits
  • Edit the graph to state a plan before writing code
  • Read only the spans the plan touches — not the whole codebase

The discipline

T2D2 — Test² Telemetry² Driven Development

Poka Yoke is the reference implementation of a methodology that extends Test-Driven Development's core move — write the check before the thing it checks — to the level of architecture and intent, not just function-level correctness.

A shared, checkable contract between what a human asked for and what a human-plus-agent pair actually builds — from before the first line of code to whatever the system does in production.

Read the methodology →

The 60-second version

See it in 11 slides.

The product story, from "what it is" to "where it pays off". Use the arrows, the ← → keys, or swipe. Autoplay off by default.

Poka-yoke · working name · early-stage product

Navigate code by meaning, not text.

Poka-yoke gives engineers and coding agents the same resolved map of the code, and of what it does at runtime.

How the pieces fit

Source code
›
Agent-free graph generation
›
Graph with stable ids
›
Visualizer for humans / MCP tools for agents
Running app
›
Agent-free code and IPC instrumentation
›
Live telemetry overlay
›
Graph edit and diff for both

One graph and one telemetry stream, used by people through the visualizer and by agents through MCP.

Agent-free, deterministic graph generation

No tokens spent. Generating or regenerating the graph makes no model calls.

Same code, same graph. Output is reproducible, so before and after graphs compare exactly.

Stable ids. Each function's id hashes its signature, so unchanged code keeps its id across regenerations.

Reported, not hidden

Unresolved and ambiguous calls are listed in the graph rather than guessed.

Static analysis is incomplete by nature. The best published Python call-graph tool reports about 99% precision and 70% recall (PyCG, ICSE 2021).

Agent-free code and IPC instrumentation

Code instrumentation

Telemetry the coding agent cannot write, skip or fake.

Each step carries its graph node id and source location.

A library feeds the visualizer live today. A web path is next.

IPC instrumentation

A journey id travels across process boundaries.

One user action reads as one trace, not a set of fragments.

Calls across processes look local to the caller, so a trace needs a carried id to stay connected.

A trace shows what ran and when, only for paths that executed. It does not show that the output was right, so it complements tests.

Strict journey: every step knows its journey and its caller

Illustrative journey A · no caller journey J-42 B · caller A journey J-42 C · caller A journey J-42 D · caller B journey J-42 Arbitrary state rides along, in one standard form

Journey id plus caller id. Every instrumented call carries both.

Order rebuilt as a graph. Component traces reassemble into what called what, and in what order.

State in one standard form. Arbitrary state travels with the journey without ad hoc plumbing.

Follows established practice: W3C Trace Context carries a trace id and parent id, and W3C Baggage carries application state.

Code visualization built to be filtered

entry handler send() ui svc db cache live trace

Filters keep large graphs usable. Show only the relations, projects or paths you need.

One map. Live traces are drawn on the same view as the structure.

Honest edges. Unresolved calls are drawn differently from resolved ones.

Large node-link diagrams turn into hairballs, which is why filtering matters (Yoghourdjian et al., IEEE TVCG 2020). Whether this reduces cognitive load has not yet been measured in a user study.

MCP tools: the graph replaces search, not reading

Text search
Search › Read hits to tell real from noise › Verify, then search again
Graph
Query the closure › Plan against stable node ids › Read only the planned spans

Reading code stays. The graph is built by deterministic tools, so generating or regenerating it spends no tokens. It removes the discovery reads that come before reading. Tool definitions also load into context, so net savings depend on a compact tool surface.

What text search cannot see

The question Text search gives you The graph gives you
Which method does this call resolve to? Every textual match, sorted out by reading One resolved node
Every implementor of an interface Per-language patterns, import aliases, manual de-duplication One query
What overrides this method? Read each class in the hierarchy A direct overrides relation
Does my plan survive an edit? file:line hits drift after any edit above them Node ids stay stable for unchanged signatures

Modeled token cost on a closure-shaped task

Text search plus reading Graph query plus targeted reads Small closure ~20 callers · 4.4× fewer 22K 5K Medium closure ~200 callers · 4.5× fewer 100K 22K Large closure ~1,200 callers · 3.4× fewer 420K 123K

Modeled estimate at about 10 tokens per line on both sides. Hosted frontier models now offer windows of about 1M tokens, so these tasks fit; the saving is cost, latency and focus, not fit. A measured benchmark on real tasks is the next step.

Graph edit and diff for planning and validation

Edit the graph to state the plan
›
Implement
›
Regenerate and diff

Humans and agents use the same edit and diff tools.

The diff runs on stable ids and shows as a visual view and a list.

Versioned graphs give an exact before and after.

Example diff output (illustrative) + added Service.send(msg, journeyId) − removed Service.send(msg) = unchanged everything else

The diff checks structure against the plan. It does not check behavior or whether the plan was right. Whether it raises fidelity to requirements is being tested.

Where it pays off, and where it does not

Pays off

Closure-shaped tasks: find every caller, thread a parameter through a call chain

Re-checking a plan after edits

Long multi-step tasks, where tokens add up in cost and latency

Does not

Understanding what a function is trying to do

First orientation on an unfamiliar codebase

Graphs with many unresolved or ambiguous calls

Next: a measured benchmark on real tasks, with the resolution rate reported alongside the savings.

Origin

A narrow, practical irritation.

Poka Yoke started from a specific irritation: videocoding works fine on a small script and falls apart on a large, complex codebase. Not because the model gets dumber — because nothing in the workflow tells it, or you, when the shape of what's being built has quietly drifted from what was asked for.

The gap doesn't announce itself. It shows up weeks later as a bug nobody can explain, or never shows up at all and becomes technical debt with no paper trail.

The instinct that follows from that is old, not new — it's Deming's, from a Toyota factory floor seventy years before any of this: catch the mistake by the shape of the process, not by inspecting the output afterward. Applying that to code meant asking what the equivalent of a factory's physical jig or gauge would be for software. The answer turned out to be a graph — a structural map of what the code actually looks like, that could exist before the code does, be checked against the code once it's built, and keep being checked after it ships, against what the system actually does at runtime.

A second, personal influence shaped how that graph gets used day to day, borrowed from Heinlein's Waldo — build tools to build tools, and give an agent its constraints before its instructions, not after. That ordering produced better results than the more natural instinct of stating the goal first and hoping the constraints get respected.

“Poka-yoke” is a Japanese term from lean manufacturing — a mechanism that makes a mistake impossible to pass on, rather than a check that catches it afterward.

About

Built by BreakThrough Technologies LLC.

Poka Yoke is being built by Tyrone Thomas at BreakThrough Technologies LLC. The methodology is free and will stay that way; any commercial tooling built on it sits alongside it, never in front of it.

The alpha focuses on Android / mobile-mesh architectures — where static parse, compile-time accuracy, and live telemetry correlation genuinely pay off — with broader language and platform support on the roadmap.

Free alpha

Try Poka Yoke.

The alpha ships as a local-first bundle — parsers, graph generator, viewer, and MCP server — for evaluating the discipline on a real codebase.

Download free alpha →

Requires macOS or Linux · Python 3.11+ · No account required.

Contact

Tell us what you're building.

Design-partner conversations, bug reports from the alpha, or methodology questions — all welcome. We read everything.