TL;DR: Your coding agent shipped good code. The problem was never the speed — it's that the product grew past your understanding while the deploys stayed green. Reclaiming it isn't a rewrite and it isn't a slowdown. It's re-authoring what you already shipped, behavior by behavior, until you can speak for your own product again.
You vibe-coded a working product. Claude Code, Codex, Cursor — whatever's in your loop wrote most of it, and it wrote it well. The tests pass. Users are using it. None of that is the problem, and going slower wouldn't have helped.
The problem is quieter than that. Somewhere along the way the product got bigger than your understanding of it. You can still read any single file. What you can't do is speak for the thing — tell a user what happens in an edge case, tell an investor what your product actually promises, tell yourself which behaviors you decided on purpose and which ones are agent defaults that quietly became canon.
I've written before about how vibe-coding gets you here, and about what it feels like to ship a stranger. This is the other half of that story: not the pain, the move out of it.
Reclaiming is not rewriting
Here's the trap people fall into. They feel the gap, decide they've "lost control" of the codebase, and reach for a rewrite. As if the way to understand your product is to type all of it again yourself.
That's the wrong target. The code isn't the thing you lost. The code is right there, working. What you lost is the layer above the code — the set of decisions about what your users get and don't get, what's allowed and what isn't, what happens at the edges. That layer never lived in the code in the first place. It lived in your head, and your head couldn't keep up with how fast the agent shipped.
So reclaiming doesn't mean re-typing the implementation. It means re-authoring the understanding. The code can stay exactly as it is. What changes is that you go back through what shipped and make each meaningful decision yours again — explicit, written down, separated from the accidental.
The move, behavior by behavior
You don't have to do this for the whole product at once. That's the part that makes it feel impossible. Do it the way the damage is distributed: worst-first.
Start where being wrong would hurt most. Billing. Auth. Entitlements. The places where a silent agent-default becomes a refund, a leak, or a furious user. Not the whole repo — the three or four behaviors that carry real consequences.
For each one, recover three things. What must happen. What must not happen. And the edge cases that actually matter. This is the same shape as writing a behavior spec — except you're not inventing it from a clean sheet, you're recovering it from a product that already exists. The answers are sitting in the code that shipped; you just have to read them out and decide whether they're what you meant.
Then make the call, out loud. This is the part only you can do. For each behavior you find, you're either confirming "yes, that's intentional" or catching "wait, I never decided that — the agent picked it and it stuck." Both outcomes are wins. The first makes a decision durable. The second turns an accident into a choice. What you end up with is a product whose behavior you can account for, line of reasoning by line of reasoning.
"Just ask the agent to explain it" doesn't close the loop
The obvious objection: why do any of this by hand when the agent that wrote the code can summarize it for me?
Because a summary you scroll past isn't the same as understanding you hold. Ask Claude Code or Codex to explain your repo and you get a fluent reconstruction of intent — assembled from the same code you're staring at, confident whether or not it's right, and gone the moment the session ends. It reconstructs; it doesn't commit. The next session starts from zero and reconstructs again, possibly differently. The loop closes on itself.
Reclaiming means the decisions land somewhere outside the agent's context window — as their own artifact, written in product terms, tied back to the code that proves each claim. Something you keep, that doesn't evaporate at session end, and that your next agent session can read instead of re-guessing.
That last point matters more than it sounds. Once the product's behavior is written down as something durable, it stops being only your memory problem. It becomes the brief you hand the next agent — so the thing building your product is working from your decisions instead of re-deriving them from whatever's nearest in the file tree.
What you get back
You get the ability to answer the 11pm email without opening the file. You get to walk into a demo and describe what your product promises without hedging. You get to look at a behavior six weeks from now and know whether it was your idea or the agent's.
Vibe-coding got you a real product, fast. Reclaiming it is how you get to own the thing you shipped — not by slowing down, but by going back and making it yours, behavior by behavior.
I built Stewie Reflect to make that re-authoring possible without starting from a blank page. It takes a snapshot of your repo and writes an owner's manual for the product inside it — every behavior in plain language, every claim linked back to the file or function that proves it, and the gaps flagged honestly as gaps. It won't decide what your product is supposed to do; only you can do that. But it lays the evidence out behavior by behavior, so the deciding is a morning's work instead of a month of archaeology. Run it on your repo and see what it surfaces.
