Day 16 of 28 · Vibe Coding Challenge
Refactoring AI Code
⏱ 6 min
📊 Intermediate
AI-generated code works. But "works" isn't always "good." Today you'll learn to spot code that could be better and ask the AI to improve it — without changing what it does.
This is called refactoring: improving the structure of code without changing its behavior.
Why refactor?
Code you'll never touch again? Ship it as-is. But code you'll keep building on needs to be maintainable. Refactoring makes your code:
Easier to modify. When you ask the AI to add a feature later, clean code gets better results than messy code.
Easier to debug. When something breaks, organized code makes it easier for the AI (and you) to find the problem.
Smaller and faster. AI sometimes generates more code than necessary. Trimming the fat makes your app faster.
Knowledge Check
What is refactoring?
A
Rewriting the entire app from scratch
B
Improving the structure and quality of code without changing what it does
C
Deleting old code and replacing it with new code
D
Adding new features to existing code
Refactoring is purely structural improvement. The app does the same thing before and after — it just does it with cleaner, more organized, more maintainable code. Like reorganizing a messy closet — same clothes, better arrangement.
Common AI code smells
"Code smell" is developer slang for code that works but has signs of deeper problems. Here are the ones AI produces most often:
Duplicate code. The same logic copy-pasted in multiple places. If you need to change it, you have to change it everywhere.
Giant components. One file doing too many things. A 500-line component that handles the header, sidebar, content, and footer.
Hardcoded values. Colors, URLs, API keys, and text strings scattered throughout the code instead of defined in one place.
Over-engineering. Abstraction layers, configuration systems, and complex patterns for simple problems.
Review this codebase and tell me what could be improved. Don't change anything yet — just list the issues.
Here's what I found:
🔴 **Duplicate code** — The fetch-and-display pattern is repeated 4 times across Dashboard, Tasks, Projects, and Profile components. Should be a shared hook.
🟡 **Large components** — Dashboard.tsx is 380 lines. It handles data fetching, rendering, and event handling all in one file. Should be split into smaller components.
🟡 **Hardcoded values** — Colors and spacing are hardcoded throughout. 14 different places use the accent color directly instead of a CSS variable.
🟢 **Unused code** — 3 imported modules aren't used anywhere.
Want me to fix these one at a time?
Start with the duplicate code.
Done ✓
Created a `useDataFetch` hook that handles:
- Loading state
- Error handling
- Data fetching
All 4 components now use this shared hook instead of duplicating the pattern. Reduced total code by 47 lines and centralized error handling.
↻ Replay conversation
Knowledge Check
Why is duplicate code a problem?
A
It violates copyright law
B
It makes the app slower
D
If you need to change the logic, you have to change it in every copy — and missing one creates bugs
Duplicate code creates a maintenance burden. If the data fetching pattern needs a change — say, adding a retry on failure — you need to update it in all 4 places. With a shared hook, you change it once and all components benefit. One source of truth.
How to ask for refactoring
These prompts consistently produce good refactoring results:
"Split this component into smaller pieces." — Breaks a giant file into focused, single-purpose components.
"Remove duplicate code and create shared utilities." — Identifies repeated patterns and creates reusable functions.
"Move hardcoded values to a config file." — Centralizes colors, API URLs, and other constants.
"Simplify this code. Remove anything unnecessary." — Trims over-engineering and unused code.
"Make this code consistent with the rest of the project." — Aligns naming conventions, patterns, and style.
The Dashboard.tsx file is 380 lines. Split it into smaller components. Each component should do one thing.
Refactored ✓ Dashboard split into 5 components:
📊 `DashboardStats.tsx` (45 lines) — The stats cards at the top
📋 `TaskList.tsx` (62 lines) — The task list with filters
📈 `ActivityChart.tsx` (58 lines) — The activity chart
🔔 `RecentActivity.tsx` (40 lines) — The activity feed
🏠 `Dashboard.tsx` (35 lines) — Composes the sub-components together
380 lines → 5 focused files, each under 65 lines. Much easier to maintain and modify.
↻ Replay conversation
Knowledge Check
When should you refactor AI-generated code?
A
When you plan to keep building on the code — refactor before adding more features
B
Never — AI code is already optimal
C
Immediately after every prompt — always refactor everything
D
Only before deploying to production
If you're building a throwaway prototype, don't bother refactoring. But if you're going to keep adding features, clean code now saves you hours later. Refactor before major new features, not after every small change.
The refactoring checklist
Before adding the next big feature to your project, run through this checklist:
Are any components over 200 lines? → Split them
Is any code repeated more than twice? → Extract it into a shared function or component
Are colors, URLs, or API keys hardcoded? → Move them to a config/constants file
Are there unused imports or variables? → Remove them
Is the file structure clear? → Can someone (or AI) understand where things are?
You don't need to fix everything. Just address the biggest issues before they compound.
Final Check
What's the purpose of asking AI to "review this codebase" before refactoring?
A
To check for security vulnerabilities
B
To identify specific issues before making changes — so you can prioritize what matters most
C
To get a grade on your code quality
D
To make sure the AI approves of the code
A review gives you a prioritized list of issues. You can then decide which ones matter for your project. Not every code smell needs fixing — but knowing what's there lets you make informed decisions about what to clean up.
🧹
Day 16 Complete
"Working code is the start. Clean code is what lets you keep building."
Tomorrow — Day 17
Version Control Essentials
What if you break something and can't undo it? Tomorrow you'll learn Git — the time machine for your code.