Memuat
Memuat
Want to go deeper?
Join one of our courses or ask us directly on WhatsApp.
Picked from the software, topic, and level of “Claude from Zero to Expert Class #87: Planning Before Changing Code”.
Other ways we can help with Claude.
Learn with a mentor
Scheduled AI & Machine Learning courses with live guidance and a certificate.

Midjourney Course: Create Stunning AI Images from Text
★ 4.9

DALL-E Course: Creating Professional AI Images from Text
★ 4.9

Stable Diffusion Course: AI Art from Beginner to Professional
★ 4.9
Have it built for you
No time to learn Claude? Our team can do the project for you.

AI Image Creation with Stable Diffusion — Unlimited Custom Visual Production
★ 4.9

AI Image & Video Creation with Leonardo AI — All-in-One Visuals for Business
★ 4.9

AI Image Creation with Midjourney — Cinematic AI Art for Business
★ 4.9
Get notified about new Claude classes
At most one email a week. Unfollow anytime with one click.
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Hi, and welcome back. In the previous episode we set up a safety net called Git. Now we learn a habit that keeps us from falling in the first place: planning before changing code. We'll ask Claude Code to draw up a plan without touching any files, review and fix that plan, and then carry it out step by step.
Not every request needs a plan. Changing the WhatsApp number on the website can be requested right away. But now Raka wants to add a menu page complete with a shopping cart. A small change usually touches just one file. A cart feature can touch five files or more: a new page, the styling, price data, and the order form. The risk of misunderstanding is different too. The sentence add a cart can be read many ways: does it need a login, online payment, or is sending through WhatsApp enough? And this feature involves important data: prices and customer orders. For changes like this, the rule is clear: plan first. Raka once tried the quick way in a practice project, writing only add a cart, with no other explanation. Claude worked on it seriously, but read far too much into it. The result: nine files changed, including a customer login system nobody ever asked for. Claude wasn't wrong; the request was simply too short for a job that big. Luckily there was Git, so everything could be undone. But a whole afternoon was lost checking and undoing. From that experience Raka learned: for big changes, agree on the plan first.
Raka prepares the request carefully. The goal part explains what the customer experiences: choosing several products, seeing the total, then sending the order through WhatsApp. The context part names the price source, Sunset Coffee's shipping rules, and two things that are deliberately left out: login and online payment. Saying what you don't want is just as important as saying what you do want. The task part asks for a step-by-step plan, complete with a list of files touched and how to test them. And the limits are firm: don't change any files yet, and ask if anything is unclear. Raka presses Shift and Tab until the bottom of the terminal shows plan mode. In your version of Claude Code it may work slightly differently, so check the official documentation. What matters is the meaning: Claude only reads and proposes. Raka pastes in the request from before. Claude starts by reading the menu data: four products, complete with prices. Then it reads the home page, the styling file, and the existing order script. Notice that every tool used only reads. Not a single file is changed. Before drawing up the plan, Claude asks two questions: what's the maximum quantity per product, and should the customer's address be sent too. Questions like these prevent misunderstandings from the very start. Raka answers: a maximum of twenty per product, and name and address fields before the send button.
Claude presents its plan. Step one creates a menu page that reads price data from the existing file, so prices stay in one place. Step two creates the cart script: add, remove with a limit of twenty, and calculate shipping by Sunset Coffee's rules. Then steps three to five: a name and address form, saving the cart contents in the customer's browser, and adding a menu link to the home page, finishing with a test on a phone. Finally, the file list: two new files, two changed files, and two files deliberately left untouched, including the secret file. A summary like this makes it easy to judge how big the change is. Now Raka reviews the plan with five questions. First, does this plan reach the goal? Yes: customers choose products, see the total, then send it through WhatsApp. Second, which files are touched? Clear and sensible. The secret file isn't touched. Third, is there any step nobody asked for? Yes: step four, saving the cart contents in the browser. It's not a bad feature, but Raka didn't ask for it, and it adds more to test. Fourth, personal data. Customers' names and addresses are sent straight through WhatsApp, not stored on the website. That's what Raka wants, so it's safe. Fifth, testing. Only step five mentions testing on a phone. Raka wants every step to have its own test. Raka asks for two fixes: remove the step that saves the cart, and add a test to every step. We're still in plan mode, so no files have changed yet. The plan now has four steps, each with a test. For example, three one-liter coffees must come to two hundred fifty-five thousand with free shipping. Test numbers like this are easy for anyone to check.
Raka approves the plan and asks Claude to work step by step, stopping each time a step is done. Claude leaves plan mode and creates a task list with four steps. The list gets checked off one by one, so we always know where the work stands. Claude works on step one: writing the menu page. Then it stops and gives a way to test: the page should show four products with prices from the menu data. Raka tests it in the browser. It's right. Raka asks for a commit, then moves on to step two. The commit is saved, and step one is checked off. If the next step goes wrong, Raka can safely return to this point, just as we learned in the Git episode. In step two, something new comes up. The menu data doesn't have the sugar-free hamper yet. Claude doesn't decide on its own; it stops and asks, because this is outside the plan. Raka asks Claude to go back to plan mode to discuss it. This is a good habit: changes to the plan are discussed first, not done right away. Claude gives two options along with a suggestion: add it as a variant at the same price, which takes just one line in the menu data. Raka chooses A and asks Claude to continue. The decision stays with Raka; the work stays with Claude.
Let's sum up the flow. Plan: Claude reads the project, asks questions, then proposes a plan, without changing anything. Review: you read the plan with five questions and cross out what isn't needed. Build: one step, test, commit, then the next step. If something new comes up, go back to the plan. This loop repeats until the feature is done. This habit is useful beyond websites. Dewi could ask for a plan before adding a new section to the monthly report script. Mr. Hendra could ask for a plan before reorganizing a question bank of hundreds of files. And Laras could ask for a plan before replacing the whole price list on the website. The plan mode screens in this video are simulations, so button names may differ in your version. The principle stays the same: for big changes, ten minutes of reading a plan saves hours of fixing.
We learned to plan before changing code: a plan mode that only reads, five review questions, crossing out what wasn't requested, and building step by step with commits. In the next episode, we see how Claude splits a big job across several helpers at once, called subagents, so tasks can run in parallel. See you there!
Try these on your own after watching to lock in what you learned.
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
Notes are saved with the current video time and are only visible to you.
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.

Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
We build software, BIM models, games and AI automations for clients every day, and turn that hands-on work into step-by-step classes: every step is shown on screen and comes with a PDF guide you can keep.
See our clients →