Accept, Reject, Redirect

Accepting bad code creates technical debt that haunts you later. Rejecting good code wastes time rewriting something that was already fine. The judgment is telling good enough to ship from looks fine until production.

Three scenarios, each building a different instinct.

Scenario one, the accept

Add a smooth color transition and a subtle glow to the navigation links on hover. Keep it subtle, about 200 milliseconds.

Standard CSS, no extra dependencies, no JavaScript, no animation library bolted on top. The code works, it reads cleanly, and the complexity matches the task.

This is where you accept and move on. Accepting good-enough work is one of the harder professional skills to build, because when the code is fine, the instinct to keep polishing feels like diligence and it is delaying you. Spending ten minutes tweaking a hover transition almost nobody will consciously notice costs you momentum across the entire project.

Scenario two, the reject

The clean version first:

Add a hover animation to the project cards. Make them lift slightly when you hover, like a card being picked up from a table.

Claude writes a few lines of plain CSS, a transform for the lift, a box-shadow for depth, and a transition to smooth it out. No library, no dependency. That restraint is the output you accept, and on a small well-defined effect Claude almost always picks the lightweight tool on its own.

Now deliberately invite the over-engineering, so you can see what catching it looks like:

Redo the card hover using GSAP, a JavaScript animation library.

Watch what happens before you have rejected anything. Claude pushes back. It reminds you the project was set up as vanilla JavaScript with no dependencies, points out the card lift is already pure CSS doing the job for free, and notes that GSAP would add a heavy library for something the browser already handles.

The redirect, sent after pressing Escape to interrupt:

Don't use an external library for this. Use CSS transforms and box-shadow with a transition instead.

Because you interrupted before anything was added, there is nothing to undo.

You have several chances to reject, and all of them are worth knowing. Answer the clarifying question with what you actually want. Press No when Claude asks permission to edit a file. Or press Escape at any point while it is working to interrupt it mid-task.

Adding an outside dependency for something your existing tools already handle is a pattern worth catching every single time. Every dependency makes the project heavier, adds a maintenance obligation, and is one more thing that can break when the library changes or stops being maintained.

Scenario three, the redirect

The proportional ask first:

The contact form has name, email, and message fields. I want basic validation to make sure the email address is formatted correctly.

Claude reads this more carefully than you might expect. It sees the form already does basic validation, spots that the built-in email check is loose enough to accept something like a@b with no real domain, and adds a small check that closes exactly that gap. A few lines and no more. Then it tests its own work against examples that should pass and examples that should fail.

Now invite the works:

Add comprehensive client-side validation to the contact form: a regex check on every field, custom error messages under each input, red error-state borders, a loading spinner on the submit button, and a success toast that slides in after submission.

For a contact form with no backend, this is too much. The form does not send anything to a server, so the loading spinner is animating against nothing, and the success message implies a response that never comes.

The redirect, naming what to keep and what to cut:

This is overbuilt for a form with no backend. Remove the loading spinner and the success toast, they don't make sense without a server. Keep a simple email format check only, and style the error state to match the rest of the site.

Reject or redirect

Reject is "do not keep this". You stop the work midway and send Claude in a different direction.

Redirect is "keep going, but not like that". You let the work finish, look at it, then keep the parts that make sense and cut the parts that do not.

The three questions

Run everything Claude produces through these.

1. Does it work?
2. Can I read and understand the code that was written?
3. Is the complexity proportional to the task I asked for?

If all three answers are yes, accept and move on. If any answer is no, redirect with specific feedback about what needs to change.

The skill underneath all three scenarios is proportionality. Claude can finish a task cleaner than you expected, and it can also reach past what you need on a loose prompt, because it has been trained on production-grade codebases where the heavier solution is often the expected one. Your job is to tell which is which.

This resource is part of

Claude Code: From Beginner to Pro Agentic AI Engineer

by Arun Nagarathanam

Take your skills to the next level with

AI GEO 2026: Get Recommended by ChatGPT, Google, Perplexity

by Arun Nagarathanam