The Feature
After this drill, you have added a new feature to your existing app using AI guidance — navigating unfamiliar code with confidence.
Why this matters
Adding a feature to an existing codebase is categorically harder than building from scratch — you need to understand the existing structure before changing it. This drill trains the pattern that every AI-augmented developer uses: understand first (Module 4.2 + 4.3), then plan, then implement in small steps with AI verification at each step. This is also the preview of what Claude Code automates in Module 5.
How to do it
- 1
Choose a real feature to add from your Module 3 to-do list
In Drill 3.3, you identified what you would fix in iteration 6. Pick that. Or add one meaningful thing: a contact section, a save-to-local-storage feature, a dark mode toggle.
- 2
Plan the feature before implementing
Use the feature planning prompt. Let Claude map the implementation before touching code. A 5-minute plan saves 30 minutes of debugging.
- 3
Implement in 3 small steps
Break the feature into 3 changes. Implement one, test it, commit, then move to the next. Never implement all 3 at once.
- 4
Commit each step with a clear message
3 commits, each describing one change. If something breaks, you can revert to the last working commit.
The prompt
I want to add the following feature to my app: Feature: [DESCRIBE THE FEATURE] Here is the relevant part of my current code: [PASTE THE COMPONENT OR FILE WHERE THE FEATURE WOULD GO] Please: 1. Map the implementation: what changes are needed and in which files? 2. List the steps in order (what to build first) 3. Write step 1 for me — just step 1, not all of them After I implement step 1 and test it, I'll come back for step 2.
Success criteria
- ✓You planned the feature before writing any code
- ✓You implemented in at least 3 separate steps with a commit after each
- ✓The feature works correctly in your local browser
- ✓The feature is deployed to Vercel
Common mistakes
Implementing the entire feature in one step
→ A feature implemented in one shot is almost always partially broken. Three small steps with tests between each produces cleaner results and cleaner commits.
Not committing between steps
→ Each commit is a save point. If step 2 breaks step 1, you can revert to the step 1 commit. Without commits between steps, you have no recovery point.