Day 18 of 28 · Vibe Coding Challenge
Working with Existing Code
⏱ 7 min
📊 Intermediate
Not everything starts from scratch. Sometimes you need to modify a template, extend an open-source project, or improve code you built last month. Today you'll learn to work with code that already exists — the skill that separates beginners from effective vibe coders.
The reality of existing code
Most real-world coding isn't greenfield (starting fresh). It's working with code that's already there:
- Your own projects from last week that need updates
- Open-source templates you want to customize
- Code from tutorials you want to adapt
- A teammate's work you need to extend
- A client's existing site that needs changes
The approach is different from starting fresh. You can't just prompt "build me X" — you need the AI to understand what exists first.
Knowledge Check
Why is working with existing code different from building from scratch?
B
The AI needs to understand the existing code structure, patterns, and conventions before making changes
C
You can't use AI with existing code
D
Existing code is better than new code
When starting fresh, AI picks its own patterns. With existing code, AI needs to match the existing patterns — same naming conventions, same file structure, same styling approach. Understanding context is key.
Step 1 — Let the AI read your project
Before asking for changes, let the AI understand what it's working with. In Cursor, the AI can index your entire project. In other tools, you might need to share files manually.
I have an existing Next.js e-commerce project. Before making any changes, can you analyze the project structure and tell me how it's organized?
I've analyzed your project. Here's the structure:
📁 **app/** — Next.js App Router
- page.tsx (homepage)
- products/page.tsx (product listing)
- products/[id]/page.tsx (product detail)
- cart/page.tsx (shopping cart)
- checkout/page.tsx (checkout flow)
📁 **components/** — 12 React components
- Navbar, Footer, ProductCard, CartItem...
📁 **lib/** — Utilities
- supabase.ts (database client)
- stripe.ts (payment setup)
- utils.ts (helper functions)
🎨 **Styling** — Tailwind CSS with custom theme in tailwind.config.ts
💾 **Database** — Supabase with products, orders, and users tables
The project follows standard Next.js conventions. What would you like to change?
↻ Replay conversation
Knowledge Check
Why should you ask AI to analyze the project structure before making changes?
A
To check how many files exist
B
To get a grade on code quality
C
To check if the code has any bugs
D
So the AI understands how the project is organized and can make changes that fit the existing patterns
Context is everything. When AI understands your project structure — the framework, the patterns, the conventions — it makes changes that feel native to the codebase. Without this step, AI might use different patterns that clash with the existing code.
Step 2 — Make targeted changes
With existing projects, specificity matters even more. Don't say "improve the product page." Say exactly what you want to change and where.
Add a "Related Products" section to the product detail page (products/[id]/page.tsx). Show 4 products from the same category as the current product. Use the same ProductCard component that's already used on the listing page. Place it below the product description.
Related Products section added ✓
📦 Shows 4 products from the same category
🔄 Reuses your existing `ProductCard` component
📍 Placed below the product description, above the footer
🚫 Excludes the current product from suggestions
🎨 Matches the existing grid layout and spacing
I used the same Supabase query pattern from your products listing page for consistency.
↻ Replay conversation
That response shows the AI matching existing patterns — reusing the same component, following the same query patterns, matching the existing layout. This is what happens when the AI understands the codebase first.
Knowledge Check
Why did the prompt specify "Use the same ProductCard component that's already used on the listing page"?
A
It's a technical requirement
B
The AI can't create new components
D
To ensure consistency — the AI will reuse the existing component instead of creating a new, potentially different one
Without that instruction, the AI might create a new card component with different styling, different props, and different behavior. By pointing to the existing component, you ensure visual and behavioral consistency across the app.
Working with templates and boilerplates
Templates are pre-built projects you customize for your needs. They're a vibe coder's best friend — start with a professional foundation and adapt it.
I downloaded a SaaS template with a dashboard, landing page, and auth. I want to customize it for a fitness tracking app. Here's what I need:
1. Rename the product from "SaaSify" to "FitTrack" everywhere
2. Change the accent color from blue to green (#10B981)
3. Replace the dashboard widgets with: daily steps chart, calories tracker, and workout log
4. Update the landing page copy to be about fitness tracking
Customizing your template...
Done ✓
📛 Renamed "SaaSify" → "FitTrack" across 23 files
🟢 Accent color changed to #10B981 throughout (34 color references updated)
📊 Dashboard widgets replaced:
- Steps chart (daily bar chart)
- Calories tracker (circular progress)
- Workout log (recent activities table)
📝 Landing page copy updated — hero, features, testimonials all focused on fitness tracking
The template structure and auth system are untouched — only the content and styling changed.
↻ Replay conversation
Knowledge Check
What's the advantage of starting with a template instead of building from scratch?
A
Templates don't need deployment
B
AI can only work with templates
C
Templates always have better code
D
You get professional structure, auth, and layout for free — then only customize the parts specific to your project
Templates give you a head start. Auth, responsive layout, navigation, settings pages — all done. You only focus on what makes your app unique. It's like moving into a furnished apartment instead of building a house.
Tips for working with existing code
Don't change everything at once. Make one change, verify it works, then make the next. Existing code has interconnected parts — changing one thing can break another.
Ask AI to explain before changing. "Explain how the checkout flow works" before "Add a coupon code feature to checkout." Understanding first prevents breaking things.
Keep the existing style. If the project uses Tailwind, don't introduce a different CSS library. If it uses TypeScript, don't add JavaScript files. Consistency matters.
Use Git aggressively. Commit before every change. Working with existing code has a higher risk of breaking things. Git makes every change reversible.
Final Check
What's the correct order when modifying existing code?
A
Make changes → hope it works → deploy
B
Delete files you don't understand → build new ones
C
Rewrite everything from scratch → deploy
D
Analyze the project → commit the current state → make one targeted change → test → repeat
Methodical changes are safer. Analyze first (understand the structure), commit (create a safety net), change one thing (reduce risk), test (verify it works), repeat. Each step builds on a known-good state.
🔧
Day 18 Complete
"Understanding existing code is harder than writing new code. But it's where the real work happens."
Tomorrow — Day 19
Testing Without Writing Tests
How do you know your app actually works? Tomorrow you'll learn to test your code — with AI doing the heavy lifting.