Starting a new feature with Claude Code: the workflow that avoids rewrites

New features go wrong when Claude starts building before you've agreed on the shape. It picks an approach, builds it out, and then you realize the approach was wrong. Now you have code to undo instead of code to build on.

One extra step before coding fixes most of it.

Step 1: describe the feature, don't spec it

Start with a plain description: what should this do from the user's perspective? Not the implementation — the behavior. "When a user clicks delete, show a confirmation dialog. If they confirm, delete the item and show a success toast. If they cancel, do nothing."

Then ask Claude: "Before writing any code, describe how you would implement this. What files would you change, what new components or functions would you create, and how would the data flow?"

Step 2: review the plan before it builds

Read Claude's implementation plan. Check: does it match how your codebase works? Is it adding something new when it should be extending something existing? Is it creating abstractions you don't want?

This is cheap to fix at the plan stage. It's expensive to fix after 200 lines are written.

If the plan is wrong, correct it here. "Don't create a new component — extend the existing Button component with a confirmBefore prop." Claude will revise the plan and you can check again before it builds.

Step 3: constrain the build

Once the plan looks right, say: "Implement this following the plan. Only create the files and functions in the plan. If you realize something in the plan needs to change, stop and tell me before changing it."

The last sentence is important. Without it, Claude will adapt the plan mid-build and you won't know until you review the diff.

Step 4: test before moving on

Before calling the feature done, have Claude write tests and run them. Then run them yourself. Claude's "the tests pass" is not reliable — it sometimes writes tests that pass trivially. Running them yourself confirms they actually test behavior.

The common failure mode this prevents

Without this workflow: you describe a feature, Claude builds something, you review it, realize it's structured wrong, ask Claude to restructure, Claude produces a second version with different problems, you end up doing a third pass. An hour wasted on rework.

With this workflow: plan review takes 5 minutes, build is usually right the first time, review is fast. Total time is less, output is more predictable.