2.2 When to Accept vs Push Back

Time: ~25 minutes

What You'll Learn

• Code smells you can spot without being a developer
• Red flags that mean "don't accept this"
• Green flags that mean "this is probably fine"
• How to push back effectively

The Accept-Everything Trap

The biggest danger in vibe coding isn't that AI generates bad code. It's that you accept bad code because you can't tell the difference.

Bad code works today but creates problems tomorrow. It's the feature that breaks when you add another feature. It's the file that no one understands in a week. It's the bug that takes 3 hours to find because the code is tangled.

You don't need to be a developer to spot bad code. You just need to know what to look for.

Red Flags (Push Back)

1. It's way more code than expected

If you asked for a simple button component and got 200 lines of code, something's off. Simple tasks should produce simple code.

Push back: "This seems overly complex for what I asked. Can you simplify it?"

2. It creates new files you didn't ask for

You asked to edit a component and AI created three new utility files, a custom hook, and a type definition file. That's scope creep.

Push back: "I only need the changes to the existing component. Don't create new files."

3. It ignores your existing code

You told it about your existing useAuth hook but it created a brand new authentication system. AI sometimes "forgets" or ignores context.

Push back: "Use the existing useAuth hook I mentioned. Don't create new auth logic."

4. The code has hardcoded values

Things like specific URLs, API keys, or user IDs directly in the code instead of in variables or configuration:

// Bad - hardcoded
fetch('https://api.mycompany.com/v2/users/12345')
 
// Better - configurable
fetch(`${API_BASE_URL}/users/${userId}`)

Push back: "Move the hardcoded values into variables or environment variables."

5. It has no error handling

The code assumes everything works perfectly. No try/catch, no checking if data exists, no loading states.

Push back: "Add error handling. What happens if the API call fails? What if the data is null?"

Green Flags (Accept)

1. It matches your project's patterns

The new code looks similar to your existing code. Same naming conventions, same file structure, same styling approach.

2. It handles edge cases

The code checks for null/undefined values, has loading and error states, and doesn't assume everything works perfectly.

3. It's readable

Even if you don't understand every line, you can follow the general flow. Variable names make sense. There are comments on the non-obvious parts.

4. It does what you asked -- nothing more

No unnecessary extras, no bonus features, no "while I'm at it" additions. Focused changes are safer changes.

5. It uses your existing code

It imports from your existing files, uses your established patterns, and doesn't reinvent things that already exist.

How to Push Back Effectively

Be specific about what's wrong

Bad: "This doesn't look right, try again."

Good: "This component is creating its own state management but I already have a global store in src/store/. Refactor it to use the existing store."

Ask for explanations

"Before I accept this, can you explain why you chose to create a separate utility file instead of adding to the existing utils.ts?"

Request incremental changes

"Instead of rewriting the whole component, show me just the lines that need to change and why."

Set boundaries upfront

"Only modify src/components/Header.tsx. Don't create any new files or modify any other existing files."

The Review Checklist

Before accepting AI-generated code, quickly check:

• Does the amount of code match the size of the task?
• Does it use my existing files and patterns?
• Does it handle errors and edge cases?
• Are there any hardcoded values that should be variables?
• Did it only change what I asked it to change?
• Can I roughly follow what the code does?

You don't need to check every line. These six questions catch most problems.

Practice

Look at the last piece of AI-generated code you accepted. Run it through the review checklist:

1. Did it match the size of the task?
2. Did it use existing patterns?
3. Does it handle errors?
4. Any hardcoded values?
5. Did it stay in scope?
6. Can you follow the logic?

If you answered "no" to any of these, try pushing back with specific feedback and see how the output improves.

Key Takeaways

• Accepting everything is the biggest danger in vibe coding
• Red flags: too much code, new files you didn't ask for, ignored context, hardcoded values, no error handling
• Green flags: matches your patterns, handles edge cases, readable, focused, uses existing code
• Push back with specific feedback, not vague "try again"
• The six-item review checklist catches most problems

Next Up

You know when to accept and when to push back. But as your project grows, how do you keep it from turning into chaos? Time to talk about project structure at scale.

Continue to 2.3 Project Structure