1. Try Start, Back, and Start again in the broken and fixed examples to see why changing a file and checking its behavior are separate tasks.
2. Our actual WordPress work needed checks of cached public pages and reading-link placement even after the code and API checks passed.
3. Report the steps, expected result, and actual result, and record the devices and actions you checked separately from what remains unverified.
The Snackgirls are new to both AI and coding. This dev log follows us as we try things and learn our way through what trips us up. This time, we’ll check an AI’s changes through a small button exercise and actual work on our WordPress site.
Want to try the buttons first? ↓
It says it’s fixed, but the button hasn’t changed
Hey, it’s Red. When an AI ends a long answer with “Fix complete,” it feels good, right? Even if you didn’t understand all the complicated explanation, you figure it should work now.
But closing the window after reading just that can leave something unchecked. Changing a file and making the feature you wanted work properly need separate checks. Today, we’ll press a start button to explore that difference.
A small exercise you can click through
The button is there, but the next screen won’t open?
This is a practice screen made for this article. It isn’t the game we’re actually developing. First press Start in the Broken example, then follow the same steps in the Fixed example.
Start screen
Pressing Start should take you to the practice screen.
Expected result: Pressing “Start” once should display the “Practice screen.”
How much did we check?
In the “Fixed example,” you can check whether Start opens the practice screen and whether you can return to the first screen. Checking those two actions doesn’t mean you’ve checked saving or the display on other devices. This exercise has two versions with different behavior prepared in advance to show the difference.
First, press Start in the “Broken example.” Nothing changes, right? Now press the same button in the “Fixed example.” If the screen changes, try Back too. You can’t tell this difference just by seeing a nice-looking first screen.
I definitely clicked it. You try too, Shiro-chan.
It’s still the same for me too. I’ll note where I clicked.
Our site work records had more things to check too
A tiny button exercise can feel a little abstract, right? I also brought actual records of work on our WordPress site. On September 14, we added a section for continuing to the previous episode, next episode, or full list below the dev logs. Korean articles would lead to Korean episodes, and English and Japanese articles to episodes in the same language.
The code checks and public API checks passed. An API is a way to request and receive data from a site. Here, it let us check which articles belonged in the reading links. But opening the regular public URLs showed that the old view remained on English Episodes 1 and 6 and Japanese Episode 6. Reading that record made me realize that being able to receive the data didn’t mean the reader’s screen had changed too.
The cause identified in the records was caching. A cache is a temporarily stored copy used to show a page quickly. Even after new code is added, readers still see the old screen if the stored page is served. The cache wasn’t manually cleared. The same public URLs were checked again after it refreshed naturally. The September 14 recheck records at 9:46 p.m. KST show that all three articles had the reading section and its automatic refresh script.
| What was actually checked | What that check established |
|---|---|
| Code checks and public API checks | The reading-link logic and delivered data were ready |
| Opening the regular public URLs | Some articles still showed the old view |
| Checking the same URLs again after the refresh | The new section and refresh script were present on those three articles |
| Checking whether scheduled articles appeared | Episodes not yet public were excluded from the reading links |
The placement was fixed separately too. At first, the reading section was below sharing and likes. It was moved directly after the hashtags, and the order was checked again on the actual pages. “The section exists” and “It’s easy for a reader to find while reading” need different checks too. The existing article content and scheduled times were also checked to make sure they hadn’t changed.
The reading section also appears below the hashtags on English Episode 6. Keep this separate from the September view.
So the code could be ready while the screen I see is still the old one.
That can happen. We need to open the same URL again and check how much has changed.
Because of that record, I don’t want to stop at “the button exists” in this exercise either. Let’s check where it takes us, whether we can go back, and whether repeating it gives the same result. And let’s not blame the cache straight away just because the screen hasn’t changed. It was caching in this site work, but a different problem needs its cause investigated again.
What comes after “It doesn’t work”?
Back to the broken-button example. Before asking for another fix, I looked again at where Kirari clicked. It was Start, and nothing changed. We’d checked that much, but still didn’t know why it wasn’t working. First, keep what you observed separate from what you think caused it.
Instead of telling the AI the cause by saying “The button code is wrong,” give it enough information to see the same situation again. Making the problem appear again is called reproducing the issue.
| What to tell it | In this exercise |
|---|---|
| Where | A PC browser, the first screen of the “Broken example” |
| In what order | Open the example and press “Start” once |
| Expected result | The practice screen opens |
| Actual result | The first screen stays as it is |
| Material to include | Relevant files, steps to run it, and a screenshot. If an error message appears, include it exactly as written |
A screenshot shows where you clicked; a short screen recording shows what happened afterward. Copy error messages without arbitrarily shortening them. Hide secrets such as passwords and login tokens before sending them. If no error message appeared, just say that.
“No response” is an explanation too, even if I don’t know the cause.
Yes. If we can check it in the same order, that helps us find the cause.
One change at a time
While fixing the button, I wanted to change its color, add music, and add more menus too. But I held off this time. If we changed everything at once and it stopped working again, I’d be confused about which change to investigate first.
Before making changes, leave a copy you can return to. If there are only a few files, you can copy the working folder. If you use Git, you can check the current changes and save a version. Also record which version it was, what worked, and what didn’t to make comparisons easier after reverting.
Relevant files: [actual file paths] How to run it: [command or steps to open it] Environment: [device / browser or app version] Pressing “Start” once on the first screen should open the practice screen, but the first screen stays unchanged. Refer to the attached screen and error message. First, reproduce the issue in the same order and identify the cause. Only change what is necessary for the Start button and screen transition. Keep the button text, color, position, and other menus' behavior unchanged. After the fix, check Start → Practice screen → Back. Check that Start works again after returning to the first screen. Tell me the environment checked, actual results, and changed files. Leave checks you didn't run marked as unverified.Replace the bracketed parts with your own information. Don’t say you’ve “attached” a screenshot or error message if you haven’t.
If someone else is already working on the same files, say so too. We don’t want an AI reverting to the pre-fix state to erase their work. If unrelated changes are mixed in, review them separately before applying them.
Tests passed? What did you try?
In the fixed example, the screen changes. Are we done? I pressed Back and tried Start again, because returning was part of our goal too. Kirari also suggested narrowing the window to see whether the button got hidden.
If an AI says “Tests passed,” ask what it checked, where, and how. Checks on part of the code alone don’t prove that it actually clicked the button.
| If this is the result | What was checked | What remains |
|---|---|---|
| Files changed | The file contents changed | Whether it runs and how it behaves |
| Runs without errors | It starts in the checked environment | Individual features such as buttons and screen transitions |
| Start and Back checked | The behavior in that sequence | Repeated actions or different conditions |
| Automated tests passed | The conditions covered by the written tests | Untested features, environments, and display issues |
If a test only checks whether a button exists, a button that does nothing when pressed might pass too. Check the result the user expects, such as “Pressing Start displays the practice screen.” Playwright’s testing guidance also recommends checking user-visible behavior. Playwright testing best practices
Working on a PC doesn’t mean it’s been checked on a phone. Narrowing a window and tapping on an actual phone are different too. Check the important actions on the device you want to use, and note any environments you haven’t tried. MDN guide to testing across browsers and devices
Shiro-chan, wanna try it on a phone too? I’ll be looking at it when I’m out.
Yes, let’s. We haven’t tried that yet.
This time, I clicked it first
Now, when I get a “Fix complete” reply, I don’t want to stop there. I’ll repeat the sequence that failed and check the parts I asked it to keep too. If a problem remains, I can note how far it works and continue from there.
If you checked it yourself, you could record the exercise like this: “Checked Start → Practice screen → Back → Start again on a PC. Not checked on an actual phone.” If you haven’t pressed it yet, don’t write that you’ve checked it. Leaving a note about what you haven’t tried tells the next person where to start.
I turned the laptop toward Kirari. This time, I felt confident. When she took the mouse, Nea pulled her chair a little closer too. I was about to explain, but decided just to watch beside them. I wanted to see where they stopped.
Comments
0No login needed. Edit or delete your comment from the same browser.
All comments 0
한국어 · English · 日本語No comments yet. Start the conversation.