Review and Refine Code

Generating code with AI is easy. Judging whether that code is good — that's the skill that matters. This exercise is about learning to do a code review on AI-generated output: reading it with a critical eye and refining it until it meets your standards. It's the skill that separates someone who uses AI effectively from someone who accumulates a codebase they can't understand or maintain.

The good news is that you already know enough to do this. You've learned HTML, CSS, JavaScript, components, and how real projects are structured. You can read code and understand what it's doing. Now you need to develop the judgment for whether it's doing it well.

What to look for

When you look at AI-generated code, scan for a few things. First, structure: is the code organized into sensible components, or is everything crammed into one massive file? A component should do one thing. If a file is hundreds of lines long, it probably needs to be split. Second, naming: are files, components, variables, and CSS classes named clearly? Can you tell what each piece does from its name alone? If you see names like div1, container2, or data — that's a red flag. Third, semantics: is the HTML using the right elements? A clickable thing should be a <button>, not a <div> with an onClick. Navigation should be in a <nav>. Meaningful structure should use <section>, <article>, <header> — not just generic <div> wrappers everywhere.

You don't need to understand every line. You need to understand the shape — the overall structure, the component boundaries, the naming patterns. Think of it like looking at a floor plan: you don't need to understand the plumbing to tell if the layout makes sense.

Accept, iterate, or restart

When reviewing AI output, you have three choices. Accept: the code does what you asked, reads cleanly, and has no red flags. Ship it. Iterate: the code is mostly right but needs refinement — give specific feedback about what to fix. "The spacing should be 24 not 16" or "This component should be split into two: one for the header and one for the content." Restart: the approach is fundamentally wrong or overly complicated. Instead of iterating endlessly on a bad foundation, describe what's wrong and ask for a different approach from scratch.

Trust your gut here. If something feels over-complicated, it probably is. If the code is hard to follow, that's a legitimate reason to push back.

Work in small chunks

Working in small chunks is essential. Don't let AI make ten changes at once — you lose the ability to judge what's right and what's wrong. Make one change, review it, accept or adjust, then move to the next. Commit frequently with Git so you always have a clean state to return to if something goes sideways. Small, frequent commits with clear Git commit messages aren't just good practice — they're your safety net.

Use components

Component thinking is where your design background shines. When should something be its own component? When it's reused in multiple places, when a file is getting too large to navigate, or when it represents a distinct concept in the UI. This maps directly to how you think about component libraries in Figma: each component has a clear purpose, clear boundaries, and a consistent interface. The same principles apply in code.

Codebase hygiene

Codebase hygiene is the long game. AI is bad at cleaning up after itself — it generates new code but rarely removes what's no longer needed. Unused code (commented-out blocks, unreferenced imports, components nobody uses) clutters the project and confuses both humans and AI tools. Make a habit of deleting what's not needed. Rename things that have poor names. Add comments only when something is non-obvious. Git means you can always recover anything you delete.

Refactoring

Refactoring — restructuring code without changing what it does — is a normal part of maintaining a healthy project. When you notice a component doing too much, a naming pattern that's confusing, or duplicate logic that should be shared, that's a signal to refactor. AI is actually great at this: "Split this 200-line component into a header component and a content component" is the kind of instruction it handles well.