Why read code that already seems to work?
An AI answer that renders nicely in the Preview has passed one test: it doesn’t crash. That says nothing about whether the prices are right, whether the buttons do what you asked, or whether the page loads something from another server without telling you. Those problems only show up when you read the code and use the page on purpose.
You are responsible for every line you put on your site, wherever it came from. Reading every line sounds slow. For a reply of thirty or forty lines it takes a few minutes, and it is the only way to know what you are publishing.
What do you look for on a first read?
Read from top to bottom, one line at a time, and ask what each line is for. If you can’t say, that line is either something to learn or something to remove. These questions catch most problems in beginner-sized replies.
In the practice area, the good reply for the bakery menu has three problems hiding in plain sight. One fails the “outside servers” question, one fails the “does it do what you asked” question, and one is a wrong price. All three are easy to miss if you only look at the Preview.
- Does every piece of text, price and date match what you asked for?
- Does any line load a file from another server (
src="https://…"orhref="https://…")? - Does every class in the CSS match an element in the HTML, and the other way round?
- Does every button or link do something when clicked?
- Is there anything you didn’t ask for, such as tracking, pop-ups or extra features?
- Are there leftover test lines, such as
alert()orconsole.log()?
How do you test it in the Preview?
Use the page the way a customer would. Click every button, twice. Fill in every field, including with silly input like an empty box or a very long name. Resize the window to phone width. For the bakery menu, click Sold out on the rye and see what happens.
You asked for the item to be crossed out. Instead it disappears completely, along with its button, so there is no way to undo it. The CSS line responsible is .sold-out { display: none; }. The assistant’s message said the button “marks” the item, which sounds right and hides the real behaviour. Testing caught what the message glossed over.
.sold-out { text-decoration: line-through; color: #8c7a6b; }Why check the content as well as the code?
Your request said the seeded rye costs £3.80. The reply says £4.20. The code is valid, the page looks fine, and the price is wrong. AI tools copy, round and invent details like prices, dates, phone numbers and addresses, and they rarely flag that they changed anything.
Compare the reply against your request word by word for anything a customer would rely on. A wrong price or opening time on a real bakery site causes real arguments at the counter.
What about lines that load outside files?
The reply includes <script src="https://cdn.example.com/tinyquery/…">, even though you said no libraries and the reply itself says everything is self-contained. Nothing on the page uses it. It makes your page depend on another server, slows loading, and runs someone else’s code on your site.
Every src or href that points to another website deserves a question: did I ask for this, and do I trust it? If the answer to either is no, remove it and test again. Here the page works exactly the same without it, which proves it was never needed.
How do the console and the Review view help?
Open your browser’s developer tools and look at the console while you use the page. Errors in red point at the exact line that failed, and they often reveal functions the assistant called but never wrote. A clean console doesn’t prove the code is right, and a red one always deserves a look.
After you make your fixes, open the **Review** view. It shows the assistant’s code next to yours with each changed line highlighted. It is a quick way to confirm you changed what you meant to, and nothing else.
What should you do with a line you don’t understand?
Don’t delete it blindly and don’t keep it blindly. Ask about it: paste the line and ask what it does and whether the page needs it. Then test the answer by removing the line and seeing what breaks.
Over time the list of lines you don’t recognise gets shorter. That is the real benefit of reading every line. Each reply teaches you a little, and you get faster at spotting the parts that don’t belong.
What does this line do, and does my page need it?
<script src="https://cdn.example.com/tinyquery/3.1/tinyquery.min.js"></script>How do you keep reading from becoming a chore?
Keep replies short. A request for one piece of the page gives you twenty or thirty lines, which you can read in a couple of minutes with full attention. A two-hundred-line reply invites skimming, and skimming is exactly how a wrong price or a tracking script gets through.
Read in the same order every time: first the content a visitor sees, then every line that loads something, then the CSS, then the script. A fixed order means you don’t have to decide where to look, and you stop missing the same kind of problem twice.
Finally, test after every fix as well as at the end. If you remove the outside script and the menu still works, you have learned it was unused. If you change the CSS and the item is crossed out, you know the fix is right before you move on.
How is this pretend assistant different from a real one?
Here the same request always gets the same reply with the same three problems, so the lesson can check your fixes. A real AI tool might get the price right one time and wrong the next, or add a different unrequested script. Its replies are often longer, too.
That variation is the reason to read every time. A reply that was fine yesterday tells you nothing about the one you got today. The habit is the same with any tool: read each line, test each feature, compare the content to your request, then publish.
Field notes
- Code that shows up nicely in the Preview has only passed one test.
- Read from top to bottom and ask what each line is for.
- Use the page like a customer would: click everything and try odd input.
- Check content like prices too, since replies can change details without saying so.
Easy to get wrong
A page can look perfect and still hide an item it should cross out, load an outside script or show the wrong price.
The bakery reply says the page is self-contained while it loads an outside script. Summaries describe intentions, and code shows what happens.
Unexplained lines are where tracking scripts, unused libraries and leftover test code hide.
Questions people ask
Do I really need to read every line of a long reply?
Yes, or ask for a shorter reply. If a reply is too long to read, it is too long to trust. Ask for one piece at a time so each answer stays readable.
What if I can’t tell whether a line is right?
Ask the assistant to explain it, look it up in a reference, and test the page with and without it. Two of those three usually settle it.
Are outside scripts always bad?
No. Many sites use trusted libraries on purpose. The problem is a script you didn’t choose, don’t need, or can’t explain.
Why didn’t the assistant mention the price change?
AI tools often don’t notice when they change a detail. They predict likely text, and a different price can look just as likely as yours.