At most one email a week. Unfollow anytime with one click.
Transcript
The full narration of this video. The current sentence is highlighted while the video plays; click any sentence to jump there.
Show transcript
Introduction
Hi, and welcome back. The Sunset Coffee landing page is up on Raka's computer, and Laras has new requests. Like any real website, this page will keep growing and will run into problems now and then. In this episode we add two features, then learn to report and fix bugs with Claude in a tidy, tested way.
Step 1: First feature: an open or closed badge
Laras's first request: visitors should know right away whether the shop is open. Raka writes it clearly, including the opening hours, the text, and the colors. Claude explains how: create a new file called script that reads the time on the visitor's device, then add a spot for the badge on the page. The script file contains JavaScript, small instructions that the browser runs. If index is the page content and style is its look, script is the part that lets the page react. Then Claude changes the index file, adding two lines. The change box shows two green lines below the title. The first line is the spot for the badge, named status open. The second line links the page to the script file. Only additions, no red lines, and it sits right below the title. Raka chooses Yes, and does the same for the script file that was asked about before. Before moving on, Raka wants to understand what was just approved, and asks Claude to explain the script file part by part, in simple language. Claude reads the file first. Reading doesn't need permission. The explanation has three parts. First, get the time from the visitor's device. Second, compare it with the opening hours. Third, write a green or gray badge. Claude also adds an honest note: the time comes from the visitor's device, so if the clock on their phone is wrong, the badge will be wrong too. It's important to know limits like this before a feature goes live.
Step 2: Second feature: a floating WhatsApp button
Only after the first feature is done does Raka ask for the second: a round WhatsApp button that always shows in the bottom right corner. One instruction per feature keeps changes easy to read. Claude adds one line for the button in the index file, the page content. Then nine lines in the style file to set its position: stuck to the bottom right corner even as the page scrolls. Raka approves both changes after reading the file names. The summary mentions three things, including that the button's destination follows the WhatsApp rule in CLAUDE.md. The rule we recorded in the previous episode is now used without a reminder. Raka opens the page in the browser. It's ten fifteen in the morning, and a green badge saying open now appears below the title. Raka scrolls down, and the WhatsApp button stays in the corner. Raka clicks it, and the business WhatsApp opens. Finally, Raka checks the older parts: the menu, prices, and colors haven't changed. This habit matters, because a new feature can sometimes break something that was already working.
Step 3: A bug appears: reporting it clearly
A few days later, Laras sends a WhatsApp message. At eight thirty in the morning, Laras opened the website on a phone, and the badge said closed. But the shop opens at eight. Laras also adds a valuable detail: at nine, the badge was correct. This is a bug: a mistake in a program that makes the result different from what you expect. Raka says thanks, because Laras's report is very complete. Notice the notes on the left: what time it was checked, what it should say, and what happened. From Laras's message, we can learn the four elements of a bug report. First, what you did: opened the website on a phone. Second, what you expected: open now is shown. Third, what happened: closed is shown. Write exactly what you see on the screen; don't shrink it down to the word error. Fourth, when and on which device: at eight thirty on a phone, while at nine it was correct. This fourth element is often forgotten, yet it's actually the strongest clue. Compare that with a vague report like the website has an error. That sentence doesn't say which part is wrong, while a clear report says exactly what was shown. A vague report also has no time clue. A clear report says that at nine it was correct. The results are very different. With a vague report, Claude has to guess and might change parts that aren't broken. With a clear report, the cause is found fast.
Step 4: Finding the cause, then fixing
Raka copies the four elements of Laras's report into Claude Code, then adds an important request: find the cause and explain it first; don't change anything. Claude reads the script file, where the opening hours rule is written. The explanation is easy to follow. The code checks whether the hour is greater than eight, not from eight onward. As a result, eight o'clock to eight fifty-nine counts as closed. That's why nine o'clock was already correct. This explanation matches Laras's clue. Raka judges that it makes sense, then allows the fix. The change box is tiny. The greater than sign becomes greater than or equal to. Just one symbol, but it affected a full hour every morning. Raka chooses Yes. Because the cause was explained first, Raka truly understands what's being approved. A fix isn't done until it's tested. Raka asks Claude to test four times around the opening hour limits, then report the results. Claude runs a small test, and the result is four out of four as expected. Let's look at the details. First, seven fifty-nine in the morning: closed. Correct, because the shop isn't open yet. Second, eight o'clock sharp: open now. This is the case that was wrong before, and now it's right. Third, eight fifty-nine at night: still open now. Fourth, nine o'clock at night sharp: closed. Bugs often hide at limits like these, so always test right at the limit, not just in the middle of opening hours.
Step 5: Saving a version and good habits
Everything passed, so Raka saves a new version with a clear note: two new features and the eight o'clock bug fix. A permission box appears because this runs a command. Raka reads it, which says it will save a new version with git, and chooses Yes. The project history now has two entries. If a new feature ever causes a problem, we know exactly which version is still safe. Let's sum up the good habits. First, one feature per instruction, so changes are easy to read and easy to undo. Second, check older parts every time you add a feature. A new feature must not break what already works. Third, ask for an explanation of the cause before fixing a bug. If the explanation doesn't make sense, don't approve the fix. Fourth, test right at the boundary values, such as opening and closing time, or the free shipping limit of two hundred thousand rupiah that we'll meet in the next episode. Fifth, save a version once it passes. The screens in this video are simulations, but these habits apply to any project, including yours.
Done!
The Sunset Coffee website now has an open or closed badge and a floating WhatsApp button. We also fixed the eight o'clock bug by reporting it, understanding the cause, fixing it, and testing at the time limits. In the next episode we build an order form that calculates the total and shipping automatically, then sends the order to Sunset Coffee's WhatsApp. See you there!
Practice exercises
Try these on your own after watching to lock in what you learned.
Add one small feature to your page, one instruction per feature
Write one bug report with four elements: what you did, expected, what happened, device
Ask Claude to explain the cause before fixing, then test at the boundary values
Ask the class material
Type a question or keyword; we find the part of this episode that explains it and jump the video there.
My notes
Notes are saved with the current video time and are only visible to you.
Questions & answers
Stuck on a step? Ask here; the instructor and other learners can answer.
No questions yet.
Your instructor
Cerdas Inovasi Digital Team
Software developers, BIM & 3D engineers, and AI practitioners
53 video classes1,290 episodes
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.
