Autonomous Component Development with Claude Code

In this lab, you will direct Claude Code, an agentic AI coding tool, to build one real component of your chosen React project, and you will review its work the way an Engineering Manager reviews a pull request: with a written specification before the work starts and a structured, line-by-line git diff review before anything is committed.

Scenario

You are a developer at a product studio that has begun adopting agentic AI tools. Your engineering lead is comfortable letting an AI agent write a well-scoped component, but only under a strict process: the task is specified in writing before the agent starts, every change the agent makes is reviewed in full before it is committed, and a human signs off on every merge. Your lead has asked you to practice this process on your current project (the Frontend Mentor challenge you selected for this module) by delegating exactly one component to Claude Code and running the review yourself.

This lab is your first structured practice with the AI as Builder role from this course’s AI framework. Claude Code acts as the Builder: it writes the code. You act as the Engineering Manager: you scope the task, observe the work, audit the diff, request revisions, and approve the commit. You will not write the component code yourself. Your deliverables are the specification, the review record, and the decision.

Because the component the agent builds is a real piece of your project, this lab consumes project build time rather than adding new scope. Plan for approximately 45 minutes.

Learning Objectives

Upon successful completion of this lab, you will be able to:

• Specify a React component precisely enough that an AI agent can build it without guesswork.
• Direct an agentic coding tool with a scoped, role-constrained prompt.
• Review a git diff systematically for scope, specification conformance, React correctness, safety, and code quality.
• Request revisions from an AI agent by citing specific findings with file and line references.
• Document a code review in a professional review record and justify an accept or revise decision.

Part 1: Setup (10 minutes)

Prerequisites

Before you begin, confirm all of the following:

• You have selected one of the three project options for this module (IP Address Tracker, URL Shortening API Landing Page, or REST Countries API).
• Your project has an initialized git repository connected to GitHub.
• You have scaffolded your React application and it runs locally.
• All of your in-progress work is committed. Run git status and confirm it reports a clean working tree. A clean tree matters because your review in Part 3 depends on isolating exactly what the agent changes and nothing else.

Step 1: Install Claude Code

Claude Code is a terminal-based agentic coding tool. Install it globally with npm (Node.js 18 or later is required, which you already have):

npm install -g @anthropic-ai/claude-code

You will launch it and sign in during Part 2. When prompted to log in, use your Per Scholas-provided Claude account; the /login command inside Claude Code starts the sign-in flow if you are not prompted automatically.

Step 2: Choose your target component

Each project option has one designated component for this lab. Find your project in the table below. This is the component you will specify and delegate.

Step 3: Create the component configuration file

Create a file named component.config.json at the root of your repository. This file is your written specification: it is what a competent Engineering Manager hands to a team member instead of a vague verbal request. The agent will read this file and build exactly what it describes.

The template below is filled in for Option 1 (ResultPanel) as a complete example. If you selected Option 2 or Option 3, keep all seven fields and replace every value using the table in Step 2 plus the design images and style-guide.md from your starter files.

{
  "componentName": "ResultPanel",
  "description": "A presentational panel that displays the geolocation results for the searched IP address, matching the Frontend Mentor desktop and mobile designs.",
  "props": [
    {
      "name": "ip",
      "type": "string",
      "required": true,
      "description": "The IP address that was searched."
    },
    {
      "name": "location",
      "type": "string",
      "required": true,
      "description": "The city, region, and postal code, already formatted for display."
    },
    {
      "name": "timezone",
      "type": "string",
      "required": true,
      "description": "The UTC offset for the location, for example UTC -05:00."
    },
    {
      "name": "isp",
      "type": "string",
      "required": true,
      "description": "The name of the internet service provider."
    }
  ],
  "internalState": "None. This is a presentational component. All data arrives through props.",
  "behaviors": [
    "Renders one labeled value for each prop: IP ADDRESS, LOCATION, TIMEZONE, ISP.",
    "Renders a double dash (--) in place of any value that is an empty string.",
    "Lays out the four values in a row on desktop widths and stacked on mobile widths, matching the design images."
  ],
  "stylingConstraints": [
    "Use the styling approach already present in this repository. Do not introduce a new styling library.",
    "Follow the colors and typography defined in style-guide.md from the starter files."
  ],
  "accessibility": [
    "Use semantic HTML elements.",
    "Every displayed value must have a visible text label.",
    "All interactive elements must be reachable and operable with the keyboard."
  ]
}

Take a few minutes to make this file genuinely accurate for your project. A weak specification produces weak output, and you will be reviewing that output against this file in Part 3.

Step 4: Checkpoint 1, commit the baseline

Create a feature branch and commit only the configuration file, so that the working tree is clean before the agent runs:

git checkout -b feature/ai-component
git add component.config.json
git commit -m "Add component configuration for AI agent build"

Run git status and confirm the working tree is clean. This baseline commit is the first piece of grading evidence: it proves the specification existed before the agent started.

Part 2: Directing the Agent (15 minutes)

You now delegate the build. Remember your role: an Engineering Manager does not grab the keyboard from a team member. During this part you direct, observe, and answer questions, but you do not write or edit component code yourself, and you do not let the agent commit.

Step 5: Launch Claude Code

From the root of your project repository, run:

claude

If this is your first session, sign in with your Per Scholas-provided Claude account when prompted (or run /login).

Step 6: Issue the directive prompt

Give Claude Code the following prompt exactly as written. This prompt enforces the Builder role boundaries: it scopes the work to the specification, forbids unrelated changes, and reserves all git actions for you.

You are acting as a software engineer on my team, and I am the engineering manager reviewing your work. Read the file component.config.json at the root of this repository. Implement the component it describes as a functional React component in its own file inside src/components/, then integrate it into the application so that it renders with real data where the design calls for it. Follow every prop, behavior, styling constraint, and accessibility requirement in the configuration exactly. Do not modify any file unrelated to this component and its integration. Do not add any new dependencies. Do not run any git commands and do not create any commits; I will review the diff and commit the work myself. When you are finished, list every file you created or changed and briefly summarize the purpose of each change.

Step 7: Supervise the session

Claude Code asks permission before running commands or editing files by default. Read every permission request before approving it, and approve deliberately:

1. Approve edits to files inside src/ that relate to the component and its integration.
2. Question or deny anything outside that scope: edits to package.json, installation of new packages, changes to configuration files, or any git command. If the agent requests one of these, deny the request and restate the constraint in the chat, for example: “Do not add dependencies. Implement the component with what is already installed.”
3. If the agent asks a clarifying question, answer it the way you would answer a teammate: refer it back to component.config.json, the design images, and the style guide.

When the agent reports that it is finished, read its summary of changed files, but do not take the summary at face value. Verification happens in Part 3. As a quick smoke test, you may run your development server (for example, npm run dev) in a second terminal and confirm the component renders.

Part 3: Manual Git Diff Review (15 minutes)

This part is the heart of the lab. Professional teams do not merge unreviewed AI output, and neither will you. Open a second terminal in your project root (or exit Claude Code) so you can run git commands yourself.

Step 8: Inspect and stage the changes

Run the following commands in order:

git status
git add .
git diff --staged --stat
git diff --staged

What each one tells you:

1. git status lists every modified file and every new untracked file. Check the scope immediately: is anything listed that surprises you?
2. git add . stages all of the agent’s changes. Staging is not committing; nothing is permanent yet.
3. git diff --staged --stat gives a per-file summary of how much changed, which is your map for the full review.
4. git diff --staged shows every changed line. Read all of it.

Step 9: Work through the review checklist

Evaluate the full diff against every category in this checklist. These categories mirror the module project rubric, so this review doubles as a quality gate for your own grade.

Step 10: Write the review record

Create a file named REVIEW-ai.md at the root of your repository using the template below. Your review must contain at least three specific observations, each citing a file and line numbers from the diff, each assigned a category from the checklist, and each carrying a verdict: accept, request revision, or manual fix.

At least one observation must result in a change, meaning a verdict of request revision or manual fix. A first-pass diff that earns zero change requests is rare in professional review; look closely at naming, accessibility, styling fidelity to the design images, and edge cases until you find something genuinely worth improving.

# AI Code Review: <component name>
 
**Reviewer:** <your name>
**Date:** <date>
**Branch:** feature/ai-component
**Builder:** Claude Code
 
## Diff Summary
 
<paste the output of git diff --staged --stat here, followed by two or
three sentences describing what the agent changed and why>
 
## Observations
 
### Observation 1
 
- **File and lines:** src/components/<ComponentName>.jsx, lines 12-18
- **Category:** scope | configuration conformance | React correctness | safety | code quality
- **Finding:** <what you found, specifically>
- **Verdict:** accept | request revision | manual fix
- **Action:** <what happened as a result>
 
### Observation 2
 
<same structure>
 
### Observation 3
 
<same structure>
 
## Final Decision
 
<Accepted as delivered, accepted after revision, or accepted after
manual fixes, with one or two sentences explaining why the work is
now safe to merge.>

Step 11: Request revisions when needed

For every observation with a verdict of request revision, return to Claude Code and direct the fix by citing your findings, the way you would comment on a pull request. Use this shape:

I reviewed your diff and I am requesting revisions before I accept the work. In src/components/<ComponentName>.jsx, lines <numbers>: <describe the problem and the required change>. Make only these changes. Do not touch any other files, and do not run any git commands.

After the agent revises, repeat Step 8 and re-review the new diff. Because REVIEW-ai.md exists by this point, it will also appear in the staged diff; it is your own file, so you may disregard it during the re-review. The commit sequence in Step 12 unstages it so that it stays out of the agent work commit. Record the outcome in the Action line of the relevant observation. Reserve the manual fix verdict for small corrections (a typo, a class name, a label) that are faster to make yourself; you will apply those in Step 12.

Step 12: Checkpoint 2, commit the accepted work

Once the diff passes your review, commit the agent’s work with a descriptive message:

git add .
git reset REVIEW-ai.md
git commit -m "Add ResultPanel component built by Claude Code"

The git reset REVIEW-ai.md line unstages your review record so that this commit contains only the agent’s work; you will commit the review record separately in a moment. Use your own component’s name in the message. Then apply any manual fixes you recorded, finish REVIEW-ai.md, and commit them together:

git add .
git commit -m "Add AI code review record and manual fixes"

If you had no manual fixes, this second commit contains only REVIEW-ai.md, and a message such as “Add AI code review record” is appropriate. Your branch history now tells the whole story: specification, agent build, review.

Step 13: Merge through one more review pass

Push the branch and open a pull request against main on GitHub:

git push -u origin feature/ai-component

On GitHub, open a pull request, read the Files changed tab as a final end-to-end pass, then merge the pull request. If your instructor prefers a local workflow, merging locally is acceptable instead:

git checkout main
git merge feature/ai-component

Part 4: Submit (5 minutes)

Step 14: Push and verify

Make sure main on GitHub contains the merged work:

git checkout main
git pull
git push origin main

On GitHub, confirm that your repository shows component.config.json, the component source inside src/components/, REVIEW-ai.md, and a commit history containing the baseline configuration commit, the agent work commit, and the review commit, in that order.

Submission Guidelines

Submit the link to your public GitHub repository (the same repository as your module project) on Canvas.

This lab is graded complete/incomplete. To receive a complete, your repository must show all four of the following:

1. component.config.json committed before the agent session, as evidenced by the commit history.
2. The agent-built component integrated into your application, in a commit whose diff matches the configuration file.
3. REVIEW-ai.md containing the diff summary and at least three specific observations, each citing a file and line numbers and each carrying a verdict (accept, request revision, or manual fix), with at least one observation resulting in a revision request or a manual fix, and a final decision.
4. A commit history showing the sequence: baseline configuration commit, agent work commit, then review and fix (or acceptance) commit.