AWS Builder Center

Builder Center

A Practical Claude Code Workflow: Plan, Build, Test, Review

A beginner-friendly workflow for getting reliable results from Claude Code: write a CLAUDE.md, plan before coding, work in small tasks, test everything, and review every change before it ships.

Introduction

The first time I used a coding agent, I typed a vague request, got a pile of changes across ten files, and had no idea whether any of it was right. The tool wasn't the problem. My workflow was.
After some trial and error, I settled on a simple loop that makes Claude Code far more predictable: Plan, Build, Test, Review. This article walks through that loop with a small example project, so you can copy it for your own work.

What you'll need

  • Claude Code installed (see the official documentation for the current install steps)
  • A small project in a Git repository
  • A terminal opened in the project folder

Step 0: Put your project on Git

Before an agent edits anything, make sure your work is committed. Git is your safety net: you can always see exactly what changed and roll it back.
1
2
3
git init
git add .
git commit -m "Starting point"

Step 1: Give Claude context with CLAUDE.md

Claude Code can read a file called CLAUDE.md in your project root. Think of it as a README written for your AI teammate. Running /init inside Claude Code can generate a first draft by scanning your project, and you can then edit it.
A good one is short and practical:
1
2
3
4
5
6
7
8
9
10
11
12
13
# Project notes

## What this is
A Flask API that stores student notes in SQLite.

## Commands
- Run tests: `pytest`
- Start the app: `flask run`

## Conventions
- Python 3.12, type hints on all functions
- Keep functions under 30 lines
- Never commit secrets or .env files
The payoff is that you stop repeating yourself. Test commands, style rules, and "don't touch this folder" warnings are written once.

Step 2: Plan before you build

For anything bigger than a tiny fix, ask for a plan first. Claude Code has a plan mode where it explores the code and proposes an approach without editing files. You can also just say it in plain language:
1
2
3
I want to add a search endpoint for notes by keyword.
Look at the existing code and propose a plan first.
Don't change any files yet.
Read the plan. This is the cheapest moment to catch a wrong assumption. If it plans to add a new library when you wanted standard tools, say so now, not after the code exists.

Step 3: Build in small tasks

Once the plan looks right, ask for it in pieces instead of all at once:
  1. "Add a search_notes function with tests."
  2. "Now add the /search route that uses it."
  3. "Update the README with the new endpoint."
Small tasks produce small diffs, and small diffs are easy to review. If something goes wrong, you know exactly where.

Step 4: Make it prove its work

Don't accept "done" on faith. Ask Claude Code to run your tests and show the output:
1
Run the test suite. If anything fails, fix it and run again.
Also tell it what "good" looks like. "Add input validation so empty searches return a 400 error, and write a test for that case" gives the agent a clear target to check itself against.

Step 5: Review every change

This is the step people skip, and it matters most. Before you commit:
1
git diff
Ask yourself:
  • Do I understand every change?
  • Did it touch files I didn't expect?
  • Are there hardcoded values, secrets, or leftover debug code?
  • Do the tests actually test something, or do they just pass?
If something looks odd, ask Claude Code to explain it. Then commit in a clean, small step:
1
2
git add .
git commit -m "Add keyword search endpoint"

Common mistakes

  • Vague prompts. "Make it better" gives the agent nothing to aim at.
  • Huge tasks. Break them down; you'll get better code and easier reviews.
  • Skipping tests. An agent that can run tests can also fix its own mistakes.
  • Approving blindly. Permissions and diffs exist so you stay in control.
  • Sharing secrets. Keep API keys and credentials out of prompts and out of your repo.

Using it with AWS projects

The same loop works for cloud work. Ask for a plan for your Lambda function or infrastructure template, build it in small steps, run your tests locally, and read the diff carefully, especially anything touching IAM permissions. Keep permissions as narrow as possible and never let an agent loose with broader credentials than you'd give a new teammate.

What I learned

The agent writes code quickly, but speed only helps when the direction is right. Context in CLAUDE.md, a plan up front, small tasks, and a careful review turned Claude Code from a gamble into something I can rely on. The skills that matter most are the ones we already learn as engineers: scoping work, testing, and reading code critically.

Try it yourself

Pick a small project this week and run one feature through the full loop: plan, build, test, review. Notice where you needed to step in, and use that to improve your CLAUDE.md.

Resources

What does your workflow with AI coding tools look like? Tell me in the comments.
# agentic-ai# claude-code# claude# best-practices
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article