Vibe Coding in an Existing Codebase
"Add a login page" means something different in a fresh repo vs. a 50k-line one. See how naming context changes the result.
You assume more context always helps: paste in the whole repository and let the model sort out what matters. That is backwards. There is more code in a real repository than fits in front of the model at once, so somebody has to decide what it actually sees — and if that somebody is not you, it will guess.
The repository does not fit
A fresh project fits inside a single request more or less completely, which is why the first demo everyone tries feels effortless. A real codebase does not. Fifty thousand lines of TypeScript is several times too large to hand over whole, before you have counted the conversation you are already having and the reply you are waiting on.
So the model works from a fraction of the repository: whatever it searched for, whatever you attached, whatever survived from earlier in the conversation. That fraction is rarely the whole picture, and the model has no way to tell you what it is missing, because it cannot see what it cannot see.
“Add a login page” means something very different in a fresh repo versus a 50,000-line one, for exactly this reason. In an existing codebase, the AI can only match your patterns if you tell it what they are. Click each card below to see the difference.
Work in slices, not sweeps
The strategies that follow all come from the same constraint: since the model cannot hold the whole repository, keep every request small enough that what it does hold is enough.
- 1
Let it search before it writes
Most tools can grep or search the repo on their own. Ask explicitly when it matters: "check whether something like this already exists before creating it."
- 2
Point at the entry point, not the whole feature
Name the file that should change and a similar one that already does it right, rather than describing the feature and hoping it finds the same files you would have.
- 3
One module at a time
Scope a request to a single route or component tree instead of the whole app. A prompt that spans the codebase is a prompt nothing can verify against.
- 4
Let a rules file carry the constants
Conventions that apply everywhere do not need to be re-explained per request, which frees the window's budget for what is actually specific to this one.
Before adding a new date formatter, search the repo for anexisting one and reuse it if you find one.Before you prompt, gather context
- →Which files are actually relevant, not just the one you're staring at?
- →Is there an existing pattern, component, or hook to point at?
- →What naming and styling conventions does this codebase already use?
- →What tests or checks should still pass after the change?
- →Does something like this already exist elsewhere in the repo, that you should point at instead of letting it get invented twice?
Key takeaways
- A real repository does not fit in front of the model at once — something has to decide what it sees, and by default that something is you.
- Point at the actual files. Do not make the model search for what you already know it needs.
- Match the conventions that already exist rather than letting the AI invent new ones.
- Scope each request to one module or one slice. A prompt that spans the whole app is unreviewable and unverifiable.
- The failure mode specific to large repos is a second implementation of something that already exists elsewhere. Ask it to search before it writes.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 3 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.