Vibe coding has a reputation problem, and it earned it. Someone mashing tab in a chat window, pasting errors back at the model until something runs, shipping whatever survives. That happens everywhere, and it produces the software equivalent of wet cardboard. Here is what nobody selling prompt packs will tell you: the model was never the bottleneck. Give the same agent to two builders and one ships a product while the other ships a demo that collapses the first time a real user touches it. Same model, same tools. The difference is everything around the prompt.
The repo is the prompt
The single highest leverage thing I did building this site was not a clever instruction typed into a chat box. It was a CLAUDE.md file sitting at the root of the repo, and a matching one in every project folder underneath it. Conventions, banned patterns, deploy steps, the exact command to run before claiming something works. Once that file exists, every future session inherits it for free.
This site runs a self-hosted component registry, a shadcn-style catalog with its own JSON manifests and a build step local dev does not run. You can browse the result on the components page. Nobody remembers that build rule from memory each time. It is written down once, in the repo, and the agent reads it before it writes a line.
Context is the product
An agent can only be as good as what it can see. Half of running this studio is not writing code, it is deciding what belongs in the context window for a given task: which files to hand over, which memory to load, which old decision matters right now and which one is dead weight.
I keep a memory system outside the repo, project state in one place, hard-won infrastructure traps in another, so the next session does not relearn a lesson I already paid for. Feeding the right eight files beats feeding all eight hundred. Curation is the actual work.
Interview before you build
The worst outcomes I have shipped all started the same way: I described a feature in one sentence and let the agent run. It built something reasonable, technically correct, and not what I meant. Now I make the agent interrogate me first. What is this for, who sees it, what does done look like, what should it never do. A spec built from a short conversation beats a spec guessed from vibes, every time.
Small loops, real verification
Plan a small piece, build it, then verify it yourself before moving on. Never accept a "done" you did not watch run. An agent will tell you a deploy succeeded because the dashboard said so, and the dashboard is wrong more often than you would like. I confirm with a real request against the live site and a real log line, every deploy, no exceptions.
The same discipline applies to reviews. I run dedicated subagents for design and for security before I call anything finished, because a fresh set of eyes catches what the builder session is too invested to see.
Taste is the only moat
Everyone has the same model now. The gap between a good product and a demo is not access, it is judgment: knowing what good looks like well enough to notice when something is off, and refusing to ship it even when it compiles and the tests pass. That judgment gets trained the boring way, by reading the code the agent writes, by noticing the small wrongness before it becomes a pattern, by having opinions and writing them down as rules instead of re-deciding every time.
Ship it scared
None of this matters if it never leaves your laptop. I would rather have a real domain, a real deploy, and real users finding real rough edges than a perfect draft sitting in a branch. Ship before it feels ready, then fix what people actually hit. The polish comes from contact with reality, not from one more pass alone in the editor.
None of this is a trick. It is a management job: set the constraints before the work starts, make the agent prove its claims, and read what actually matters. Do that consistently and the model stops being the interesting part of the story.