Making Your First Edit and Building a Small Feature
Having spent time asking Claude Code to explain your project, you are now ready for the step that makes it genuinely useful: asking it to change something. This lesson walks through what happens when Claude moves from talking about code to actually writing it, using a small, low-risk feature or fix as the working example, and it explains how to guide that process well as a beginner.
Choosing a Good First Task
The single biggest factor in a smooth first editing experience is choosing a task that is small and well defined. A good first request has a clear, checkable outcome, such as fixing a specific bug you can describe, adding a small piece of functionality to an existing file, writing a simple new function, or correcting a typo in output text. Avoid starting with something large and vague like “improve my codebase” or “add a login system,” since broad requests are harder for you to review and harder for Claude to scope correctly without more back and forth. Save ambitious, multi-step work for later lessons, once you have practiced the review habits this lesson introduces.
Making the Request
You describe what you want in plain English, the same way you asked questions in the previous lesson, but now framed as an instruction rather than a question. Being specific pays off here even more than it did for explanations, because specificity reduces the chance that Claude solves a slightly different problem than the one you had in mind. Compare a vague request like “make the form better” against a specific one like “add validation so the email field shows an error message if it is left empty,” and you will consistently get more useful, more predictable results from the specific version.
What Happens When Claude Edits a File
When you ask for a change, Claude Code typically works through a short loop: it reads the relevant file or files, works out what needs to change, and then proposes an edit. Because Claude Code asks for your approval before it takes actions that modify your files, you will usually be shown the proposed change, often presented as a diff, meaning a view that highlights exactly which lines are being added, removed, or altered, before it is applied. This is your opportunity to review the change rather than simply hoping it is correct.
| Step | What is happening |
|---|---|
| 1. You describe the task | You explain, in plain English, exactly what you want changed or added. |
| 2. Claude reads relevant files | Claude opens the files it believes are relevant, sometimes searching the project first if it is not obvious which files matter. |
| 3. Claude proposes an edit | Claude shows you the specific change it wants to make, usually as a diff, before applying it. |
| 4. You review and approve | You read the proposed change and decide whether to approve it, ask for a modification, or reject it. |
| 5. Claude applies the change | Once approved, the change is written to your actual files. |
Reviewing the Proposed Change
Reviewing a diff is a skill worth deliberately practicing, especially if you are new to reading code. You do not need to understand every line perfectly to review sensibly. Focus on three questions: does this change do what I actually asked for, does it touch anything I did not expect it to touch, and does it look consistent with the rest of the code around it. If anything looks off, you can simply say so in plain English, for example telling Claude that a change touched a file it should not have, and it will adjust. This back and forth is normal and is, in fact, exactly how you would work with a human collaborator too.
Building a Small Feature Incrementally
Once a single small edit feels comfortable, try extending the exercise into a genuinely small feature, something that might take a human a few minutes to write by hand, such as a simple function with a couple of edge cases handled, or a small new file that does one clear thing. Rather than describing the entire feature in one enormous instruction, it often works better to build it up in a few steps: describe the core behaviour first, review what Claude produces, and then ask for refinements, such as handling an edge case you noticed was missing. This incremental approach mirrors good software development practice generally, and it keeps each step small enough that you can review it properly, which matters more than moving quickly.
Checking the Result Yourself
After a change is applied, it is good practice to actually look at the affected file yourself, not just trust the diff you approved a moment earlier. If your project has a way to run the code, whether that is starting a small script, opening a page in a browser, or running an existing test, use it to confirm the change behaves the way you expected. Claude Code can often run these checks for you too, which the next few lessons will cover in more depth, but developing your own habit of independently verifying results, even briefly, is one of the most valuable habits you can build as a beginner working with an agentic tool.
What You Have Learned
By working through a small edit and a small feature, you have now exercised the full basic loop that underlies almost everything else in this course: describe a task clearly, let Claude propose a change, review that change critically, and verify the result. Every more advanced workflow covered later, from multi-file changes to Git commits to parallel subagents, is built on this same core loop, just applied to bigger and more complex tasks. Getting comfortable with the loop at small scale now is what makes the larger scale approachable later.
