TL;DR: Vibe-coding doesn't make you faster at building products. It makes you faster at shipping code. The product itself — the bag of decisions about what your users get and don't get — grows past your understanding while the deploys stay green. The fix isn't slowing down. It's actively re-authoring what you've shipped, behavior by behavior, until you can speak for it again.
I get an email at 11pm from a beta user. She's asking what happens if her session expires mid-checkout — does the cart persist, does she lose her form state, does she just get bounced back to login.
Real question. Reasonable user.
I open the file to check.
The session middleware is sixty-something lines. Maybe ten of them are mine. The rest came from my agent over four sessions in two weeks. I accepted every change because the tests passed and the user flows worked. I shipped it. I marketed it. It's been in production for nineteen days.
I read every line twice and I cannot answer her question without tracing the actual code path.
That was the moment I realized my product had become a stranger.
The pattern
I'd been doing this for months. Each session: prompt my agent, accept good work, run tests, push.
The code was readable. The features worked. Users were happy. I was shipping faster than I ever had — a feature in the morning, a fix at lunch, a refactor before dinner. I told myself the new normal was "augmented" — same brain, ten times the leverage.
The metrics agreed. Until that email.
What actually broke
The code wasn't the problem. I can read code. I've been reading code for fifteen years.
The problem was that I didn't know the code in the way I used to know it. When I write code, even when I write it badly, I am tracking dozens of small decisions — why this default, what this loop is protecting against, which branch is load-bearing, what failure mode the early-return is preventing. Those decisions live in my head as I write.
When my agent writes code, those decisions live in its context window. The code lands in my repo. The reasoning doesn't.
I'd been treating "accepting the diff" as "absorbing the decisions." It's not. Accepting the diff is the same as merging a PR you never reviewed — the code is in, but the understanding isn't. And unlike a teammate's PR, there's nobody you can ping next week to ask why a particular fallback exists.
So your product grows past your understanding. The deploys still go green. The metrics still tick up. But you stop being the person who can answer the user email at 11pm.
When you can't answer it, three options. Read every line until you can. Punt the email and hope she doesn't escalate. Or pretend.
I tried all three. The third one costs the least time. It costs the most of something else.
Documenting doesn't fix it
The first instinct is to write everything down. AGENTS.md. PRDs. ADRs. Confluence pages.
These help a little. They don't fix it.
You're writing about code you don't fully know. The document inherits your gap — it describes what you think the code does, not what it does. Two weeks later when behavior changes, the doc stays still. Now you have a confidently wrong document.
The agent itself can write the documentation. That's the whole pitch for half the tools shipping in 2026 — generated specs, auto-extracted behaviors, AI-summarized architectures. The output looks great. It captures everything the code already says. It captures none of what the code should say — because the code is what your agent left, and your agent doesn't know what you decided.
Documentation downstream of code only ever tells you what the code is, not what it means. You don't have a documentation gap. You have a decision gap. Documentation about code you didn't decide is documentation about a stranger.
What does fix it
The recovery is unglamorous and known to anyone who's ever written a hard-to-grasp paper: re-author your understanding in your own voice, item by item, with the code as evidence.
Not "describe the code." Not "summarize the feature." Take a candidate behavior, look at it, and decide what it means.
This refund window — is that a product promise or a placeholder? This auth fallback — did I want that, or did the agent default it? This middleware redirect — is it intentional, or did the agent add it because some test expected it? Each decision is small. Each decision is the act that turns a code pattern into a product behavior you can speak for.
This sounds like "writing specs." It isn't. Specs are documents. The thing you need is the act of deciding what your product promises. The artifact is the receipt of the decision, not the decision itself. You can write the document with an agent. You cannot make the decision with one.
The format we open-sourced for this work is .pbc.md — Product Behavior Contract. The format is incidental. The act is the point.
You shipped past your own understanding
The fact that you can ship a product faster than you know it is the new founder pathology. Not laziness. Not bad engineering. Just an asymmetry — your agent's velocity outran your sense-making.
The fix is not to slow down. It's to spend a small, regular amount of time re-authoring what your product means, on top of what your agent shipped. Behavior by behavior. Decision by decision. Until the product stops feeling like someone else's codebase you happen to own.
So when the user emails you at 11pm, you don't have to open the file.
You already know.
