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

Share post

More

More

Detangling complex AI built prototypes

Detangling complex AI built prototypes

I made a small Design Spec Gatekeeper file for ux teams working with AI-assisted tools.

I made a small Design Spec Gatekeeper file for ux teams working with AI-assisted tools.

AI is a multiplier. If the judgment is shallow, AI makes shallow work faster.

AI is a multiplier. If the judgment is shallow, AI makes shallow work faster.

And what comes next. Design/Engineering Co-authorship

And what comes next. Design/Engineering Co-authorship