Checking: don't take its word
Lesson 22 of 26 in the course “Vibe coding”. Free, with animations and a quiz.
“Done” doesn't mean “works”
You asked the agent to add monthly stats to your workout tracker. A couple of minutes later: “Done, everything works!” Sounds confident, but the agent may not have run the code, may have checked one case out of many, or may not have noticed it broke the page next door. Remember the loop in the diagram: you describe, AI writes, you check? The last step is yours, and you can't skip it.
Click through the preview
The agent worked in a branch and opened a PR, so there's a preview link: a copy of the site with the new feature, while the live site stays untouched. Open it on your phone and on a computer. First the normal path: log a workout, open the stats. Then the weird stuff: a month with no workouts, a very long name, a double tap on the button. Things usually break on the weird stuff.
Automated tests: robot checkers
An automated test is a small program that checks your code. Example: “if there are three workouts in a row, the streak shows 3”. Ask the agent to write tests for the new feature and run them, often with the command npm test. The payoff: next time AI changes something, the tests instantly show what broke. The trap: a test that always passes. Read the test names: they should describe real behavior.
CI: a check on every PR
CI (continuous integration): GitHub automatically runs the tests and the build on every PR, for example with GitHub Actions. The build is the step that turns your project into the finished site files. You see the result right in the PR: a green check or a red cross, like on the card in the diagram. Red means don't merge: open the log and hand the error to the agent. You can ask the agent itself to set up CI.
Read the diff before merging
The checks are green, but look at the diff anyway. What to look for: deleted code you didn't ask about, like the red line “check removed?” in the diagram. Keys and passwords in the code. New packages with unfamiliar names: stick to well-known ones, since scammers publish fakes with look-alike names. Edits in files that have nothing to do with the task. Found something? Ask the agent “why?” before merging.
Checklist before merging
In short, five points before you merge. The preview is checked on a phone and a computer. Tests are green. CI is green. The diff is read: no keys, no deleted checks, no strange packages. Commit messages are clear. All good: merge, and the host updates the live site. Not good: fix it in the same branch. The rule from the card in the diagram: check first, then merge. Practice in the GitHub simulator.
Check yourself
- The agent says “Done, everything works”. What's next?
Correct answer: Check the preview and the tests yourself. An agent's “done” isn't proof. It may not have run the code or may have checked just one case. The preview and tests show the truth. - What is CI?
Correct answer: GitHub runs the tests on every PR by itself. CI (continuous integration) automatically runs tests and the build on every PR and shows a green check or a red cross. - The diff removes a check you never asked about. What do you do?
Correct answer: Ask the agent “why?” before merging. Green tests don't catch everything: they may miss a removed check. Sort it out before merging, while the change isn't on the live site yet.
← Bugs: reading the error Agent helpers: skills and AI review →