Gleb Stroganov

My agent built this app with my design tokens. Then I checked which ones it actually used. Building notes, from the Storybook Workbench audit. The answer sits in one map: every place a token is used, the blast radius of a change, and how each token connects to pages. Before: I searched for a token, found the files and guessed the screens. The agent did the same, one file at a time. After: the skills read the code into a map with 4 levels: tokens, components, the components inside them, and pages. The Usage Explorer in Storybook walks it. In the video: --color-brand-600, a palette step, sits in 102 components. One of them, SkillsetTabResources, carries 32 tokens, 20 of them palette steps. Its page pulls in 98. The agent reads the same map. Today it is read-only: we see every connection and the blast radius of a change before anyone edits a line. That is the foundation for the next step. All the context is in one place, so the map can grow into live previews: change a token, watch the pages it touches, then let the human or agent make the edit, in the map we both use - inspect live and ship.

My agent sees the app as 598 files. I see it as screens. A flow runs through both, and neither of us could see it whole. Building notes, from the Storybook Workbench audit. We have the evidence. Now we render the chaos. One file and one map. Now my agent and I see it whole. Before: to review a flow, I clicked through localhost and guessed. The agent read the router, the buttons and the modals one file at a time. We checked different halves. After: sb-flows pulls the flow out of the code into flows.json. Storybook draws it as a map: a column for each role, a box for each page, an arrow for each link. So I see each flow by the roles the code defines. sb-flows first guesses a page's role from its path: 7 public, 84 for signed-in users. The agent checks that guess against the code. Here the paths name two roles, author (47 pages) and member (26), and the guess put the sign-in page in the wrong column. The idea comes from the user-flow reports in Google Analytics: one path you can read at a glance. Here the path comes from the code, so it shows where a flow breaks before a user finds it. We walk a flow together. I follow it on the map, a state story for each step. The agent re-runs sb-flows after a change and checks the same path in the file. That takes about 2 seconds. It is more than an audit. The map lists the next work: pages without stories, links still to find, and the states each page needs, 533 over 91 pages. One gap: the scanner finds only 9 links between pages so far. Most of the links in sidebars and headers are not on the map yet. That is my next fix. The demo and the repo are in the reply.

80,604 lines of code. 5 JSON files. My agent only reads the files. Building notes, from the Storybook Workbench audit. That is one vibe-coded app: 598 files. An agent can read some of it, but it can't hold all of it, and two readings can differ. Scripts do the extraction. sb-inventory, sb-flows and sb-health read the code and write 5 JSON files: components and who imports them, props at every call site, routes, tokens, design-system findings. About 80 seconds on that app. The agent works on top of the files. It sorts the findings, asks the next question and decides what to fix. It never counts. The output still has to earn trust, so it gets checked: 1. Same code, same files. Two runs, identical. 2. Totals add up inside each file: 146 used + 200 unused = 346 tokens. 3. Every number I show is a claim with a command. The build re-runs it: 14 of 14 match. 4. A count that looks odd sends the agent to the source. What I end up with is a foundation for the next task. Five JSON files hold the evidence, and each finding points back to a file in the code. Storybook renders the same files, so the agent and I inspect one shared surface. The evidence and the flows are ready now. Next is the part I like most. We render the chaos.

AI gave me a lot of speed on UI work. It also gave me a lot of scattered pieces. Before: the agent writes a component in minutes. Then I check it by hand in 6 places: AGENTS.md, DESIGN.md, Figma, chat history, the PR diff and localhost. None of them shows the whole UI, and the agent reads only 4 of them. That worked for one component. It broke at scale: I could not stay in a loop with the agent and keep control of the UI. So I stepped back and rethought the flow. After: I built Storybook Workbench, a set of agent skills. They read the code and build one shared map in Storybook: - components: real vs dead, by imports - tokens: drift from DESIGN.md - design: parity with Figma - flows: every route - states: one story each - decisions: a ledger the agent and I both write Now the agent reads the map and logs what it did. I check its work with my eyes, in the same place. The first audit on a vibe-coded app found 31 dead components out of 469, and 6 accessibility bugs that no build caught.