--- title: "I built it with AI, so I built a way to learn it" url: https://akdarrah.com/posts/i-built-it-with-ai-so-i-built-a-way-to-learn-it author: Adam Darrah published: 2026-11-11T20:57:44Z updated: 2026-11-11T20:57:44Z tags: ["ai","claude-code"] --- # I built it with AI, so I built a way to learn it Last week we shipped a whole new part of the product at work. I built almost all of it with Claude. Then someone asked me to teach it to a teammate, and I realised I couldn't, not properly. I knew what it could do. I could have given the tour from memory. But I didn't know it the way I used to know things I'd built by hand: which rule kicks in when, what happens at the edges, why a number on the screen is what it is. ## The problem with building fast When I wrote every line myself, I learned the feature while I built it. Every bug I fixed taught me a rule. Every screen I tested taught me a flow. By the time it shipped, I was the expert whether I meant to be or not. AI skipped that part for me. The code got written, reviewed and tested, and it works. But the hours of clicking through it, the part that made me the expert, never happened. The obvious fix is to sit down and use the real thing as every kind of user. That's a couple of hours, and it has a trap: as soon as I needed test data, I'd ask Claude to create a bunch of it. And then I'm not learning anything. ## A simulation you do, not watch So I had Claude build me a training simulation instead. It's a single HTML page. It opens on a menu of roles: what is it like to be the manager, the employee, the person at the front desk. Pick one and it walks you through the feature, step by step, in a mock of the real screens. The part that makes it work is the order of things in every step: 1. **You do the first one by hand.** You type the name, pick the option, click save. Not a video of someone else doing it. 2. **It asks you what you think happens next**, before the answer is on screen. If you get it wrong, it tells you why. 3. **Then a button fills in the rest.** You added the first person; it adds the other six. You approved one request; it decides the other two. You see the data appear without typing it all. 4. **It shows you the rule you just used**, with the line of code it came from. ![The example tour: I guessed wrong, so it tells me why and shows the rule and where it lives in the code](/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NzMsInB1ciI6ImJsb2JfaWQifX0=--bab299f2d7f4c2ce5d15008bb2fe0f34fa6fc3d0/feature-tour-library-demo.jpg "The example tour from the skill, a made-up library app. I guessed wrong, so it explains why and shows the rule with the line of code it came from.") At the end there's a short quiz and a results screen you can copy and send back. Each role takes about fifteen minutes instead of a couple of hours. And because it's one file with no server and no login, I can send it to the teammate I'm supposed to be teaching, and they can do the same thing. ## Every rule comes from the code The risk with a simulation is that it teaches a made-up version of the product. If the mock says a loan lasts three weeks and the real app says two, it has made someone confidently wrong. So the rules don't come from me or from the docs. Before building anything, Claude surveys the code for each role, then re-reads every cited line on the main branch, because my local checkouts were weeks behind. Every number, threshold and error message lives in one facts table, each with the file and line it came from. Nothing on a screen is typed in by hand; it's all computed from that table. That checking step paid for itself. It caught rules I would have taught wrong: a setting that's shown in the UI but never enforced, two different "late" thresholds with similar names, and demo data in one of the apps that used round numbers which weren't the real defaults. ## Making it look like the real thing The first version looked like a generic web app, and it felt like one. It got much better once Claude looked at the real product running locally and copied the design system's actual values: the fonts, the navigation, the buttons. It also caught a layout I'd never have guessed from the code alone, where a whole screen was organised differently than I'd assumed. If you build one of these, show it the real product early. ## I turned it into a skill I did the first role, it worked, and I immediately wanted it for every other part of the app. So I packaged the method as a Claude Code skill: survey the code per role, verify every fact, look at the real product, design six to eight steps per role, build it, walk it, and stop after the first role to check it's actually helping before building the rest. It's on GitHub: [akdarrah/feature-tour](https://github.com/akdarrah/feature-tour). It comes with a tiny example tour of a made-up library app, where you add a book, lend it out, and take it back nine days late to find out what the fine is. It's not a new idea. Simulations and interactive tutorials have been around forever. What's new is that one now takes an afternoon instead of a sprint, so it's worth building one just to learn the thing you shipped last week.