What the heck did the AI actually build?
DAte
Aug 7, 2026
Category
AI
Reading Time
~3min

Ever been vibe coding hard and end up with a really cool prototype but have no idea what AI built?
My team was. It gets worse when you try to hand-off a prototype for someone else to work on. It lookspolished and contained a surprising number of screens, flows, and ideas.
But we kept running into basic questions:
What is actually in here?
How does it all connect?
What came from the requirements?
What did the AI quietly invent along the way?
So I created a solution.
TL;DR
UX Cartographer inventories a prototype, maps its screens and flows, compares the experience against the product requirements, and surfaces:
Dead ends and broken paths
Missing states
Inconsistent navigation and terminology
Duplicated concepts
Friction and product drift
Engineering and QA already have tools for auditing code, performance, and test coverage. UX needs something different. We need a spatial view of the product.
AI prototypes are becoming very good at looking finished before they are actually finished. We are generating faster than we can document, understand, and align around what was created.
That creates cognitive debt.
The prototype exists, but the team no longer has a reliable shared understanding of it.
So I designed the audit itself differently.
Under the hood, UX Cartographer is a prompt-native audit system, not a generic code scanner. It runs a structured playbook of nine focused analyses that:
Inventory screens and routes
Map navigation and user flows
Check loading, empty, error, and permission states
Reverse-engineer the critical jobs the product supports
Compare what was built against the PRIt reverse engineers the jobs to be done, based on what was built
Each audit produces dated, reusable artifacts, including product maps, screen inventories, flow diagrams, state-coverage reports, navigation analysis, JTBD alignment, a weighted UX Health Score, and a prioritized fix queue. The documentation evolves with the product instead of slowly rotting in a wiki.
Every significant finding is labeled:
Observed: directly visible in the prototype
Inferred: strongly suggested, but not confirmed
Unknown: impossible to determine from the available evidence
The system also follows 15 explicit guardrails:
Map before improving
Never score what was not reviewed
Never invent screens or flows
Do not jump to redesign before understanding what exists
Do not generate new UI unless explicitly asked
The job is understanding, not unsolicited redesign
Mapping the flows
For UX practitioners, that distinction matters. This is not component linting or a generic UX checklist. It creates a navigable picture of whether the experience actually holds together:
Where users may get lost
Where important states are missing
Where the prototype drifted from the requirements
Where polish is masking unfinished product logic
UX Cartographer is my attempt to help teams keep their bearings while still moving fast.
If you are building with AI and feeling the gap between “it looks done” and “we actually understand it,” I would love to hear how you are handling it.

Yvonne Doll
UX, AI Design Leadership


