TL;DR: A working app and an understood app are not the same thing — and the gap stops being harmless the moment people start paying. Reading your code line by line is the slowest way to close it. Go top-down instead: get a map of what the product does and where each behavior lives, then drill into the two or three risky spots that actually matter. You're not learning to code. You're building a mental model good enough to direct the AI — and to sleep at night.
There's a specific moment that catches vibe-coders off guard. Not the build — the build was the fun part. It's later, when the thing you shipped quietly catches on, a few real people start using it, some of them start paying for it, and you realize you can't fully explain the product they're paying for.
It works. You can see it works. But if a user emailed you right now asking what happens when their subscription lapses, or whether their data is safe in some edge case you've never hit, you'd have to go open the files to find out — and you're not even sure you'd understand what you found.
When it was a toy, that was fine. Not understanding your own side project costs nothing. Paying users flip it. Now there's a real price on every behavior you've never looked at: a refund, a leak, a furious customer, a bug that's been quietly running in production while you slept.
Reading your code is the right instinct — done the slowest way
So you do the sensible thing: you start reading it. Maybe you paste snippets into Claude or Codex and have it walk you through line by line. It's painfully slow, especially with no coding background, and it's also genuinely rewarding — you catch a flawed bit of logic here, a better approach there, and for the first time you feel a little less like a passenger in your own product.
Keep that instinct. The people who tell you "you can't read code without a CS degree" are wrong about what you're actually doing. You're not trying to write code. You're building a mental model precise enough to direct the AI better next time — a different skill, and a learnable one that doesn't require the first.
But the way most people do it — bottom-up, snippet by snippet, hoping understanding accumulates — is the slowest possible path in. You can read a hundred lines and still not know whether they matter.
Go top-down: get the map before you read the code
Before you read a single line of actual implementation, ask your agent for a map of the whole thing. Not "explain this file" — a structural overview:
- The major parts of the system, and what each one is responsible for.
- How data actually flows from "user does X" to "result Y" — the real path through the files, not a tidy diagram.
- Where external or variable input enters, and what each entry point quietly assumes about that input.
- Which parts are risky — the spots where being wrong would hurt the most.
Read that first. Now you have a frame. Instead of trying to read everything, you drill line by line into only the two or three risky spots that actually carry consequences. Everything else, you can leave as "I know roughly what this does and where it lives" — which, for guiding an AI, is enough.
This is the same shape as the behavior map people reach for when they inherit a codebase they didn't write. You're in the same position — you just happen to be the previous owner. The agent wrote most of it; you accepted it; you never made it yours. (I've written before about why that product feels like a stranger.)
The trap: "just ask the agent to explain the whole thing"
The obvious shortcut is to skip all of this and have the agent summarize the entire repo for you. Thirty seconds, a confident paragraph, done.
It doesn't work the way you want it to. A summary is reconstructed from the same code you can't yet trust, stated with the same confidence whether it's right or wrong, and gone the moment the session closes. When you're the one on the hook for the product, a summary you can't check is just a more articulate version of not knowing.
The fix isn't to skip verification. It's to verify the parts that matter — to lay each risky behavior next to the actual code and check it against what you know the product is supposed to do. That confirmation step is the whole game. The map tells you where to look; your own product judgment tells you whether what you found is right.
Worst-first, and the bug class to hunt
You don't have to understand everything. You have to understand the things that would hurt. Start where being wrong is expensive: billing, auth, anything touching a user's data or access.
And hunt one bug class specifically: the "only tested on the inputs I happen to have" blind spot. If your app parses uploads, calls an external service, or handles formats you didn't personally try, ask the map directly: where does this depend on input I've never tested? That whole category of bug lights up before a user ever trips it — which is exactly the kind of thing that's been silently breaking for someone while it works perfectly for you.
One more distinction worth holding onto: tests tell you the code works; they don't tell you what it's supposed to do. A green test suite and a clear mental model are different things, and you need the second one to make decisions. The map is what tells you which paths are even worth testing.
What you get back
You get to answer the support email without spelunking. You get to change pricing or permissions without the fear that you'll break a behavior you didn't know existed. You get to brief your AI with specifics — "this is how billing actually works, don't touch the grace period" — instead of vague hopes. And the slowness is real but temporary: the moment you start recognizing repeated patterns, that's your model forming.
A working app got you your first paying users. Understanding it — top-down, worst-first, against the evidence — is how you keep them.
I built Stewie Reflect to give you that top-down map without the painful first pass. Point it at your repo and it writes an owner's manual for the product inside — what each part does, the behaviors grouped by what they're for, every claim linked back to the file that backs it, and the risky spots and gaps surfaced honestly. It's read-only and never runs your code. It won't replace your judgment — you still confirm the parts that matter — but it turns "I don't understand my own app" into a morning of reading instead of a month of archaeology. Run it on your repo and see what it surfaces.
