How to trust code
you didn't write.

Why bother: the trust problem

Vibe coding has a blind spot: you didn't type the code, so you can't scan it for mistakes the way you'd proofread your own writing. The AI wrote a hundred lines in four seconds and said it was done. It looks done. It ran once on your screen. But “it ran on my laptop” is a long way from “it works.”

Automated testing is a second pair of eyes that never gets tired. You write down, one time, what “working” means. From then on a computer re-checks the whole app against that definition every time anything changes, for free. Everything below is a variation on that.

You don't have to become a testing expert, and you barely have to write any of this yourself. Your AI sets most of it up and runs it. Your job is to know these safety nets exist, turn on the cheap ones, and refuse to accept “done” until they're green.

The ladder of checks

There isn't one kind of test. There's a ladder of them. Each rung catches a different class of problem, and they get slower and more thorough as you climb. You don't need all five on day one. Start at the bottom, where checks are nearly free and instant, and add rungs as your tool grows up and meets real people.

Read bottom to top: cheapest and fastest at the base, most thorough at the peak.

Linting: spellcheck for code

A linter reads your code without running it and flags mistakes and messiness: a variable you named but never used, a bracket that doesn't close, a risky pattern, an inconsistent style. It works like the squiggly red underline in a word processor, but for code. This is the fastest, cheapest feedback there is, and it shows up right in your editor as you build.

Where it comes from: most modern builders and starter templates ship with it already wired in. If yours didn't, you never have to configure it by hand. Just tell your agent:

TypeScript: bugs caught before you run

TypeScript is regular JavaScript with labels on your data. You (or the AI) mark things: this is a number, this is a date, this is a student record with these exact fields. A type checker then makes sure you never mix them up, like handing a word to something that expected a number. It catches a big group of bugs before you ever click Run.

Picture labeled bins in a workshop. The bin marked “screws” refuses the paint. If you try to force it, something complains right away, instead of three weeks later when a student's screen goes blank and you have no idea why.

There's a tradeoff: TypeScript adds a little friction. You'll see red underlines that feel pedantic when you're moving fast. They're worth it, because that friction is the bug showing up early instead of in front of your class. Satisfying the type checker is also the kind of tidying AI agents are good at, so you rarely fix it yourself:

Turn it on when: any app that stores or moves real data around, which is nearly all of them. Builders like v0 and Bolt default to it. If you're in plain JavaScript, your agent can add it.

Tests that click through your app

Lint and types never open your app. They can't tell you the login button does nothing, or that the quiz submits blank. For that you need a test that behaves like a real student: open the page, type a name, click Submit, check what happened. That's an end-to-end test (E2E): the whole app, run the way a person would use it.

Headless vs. a real browser window

This term sounds scarier than it is. It's the same browser doing the same thing. The only difference is whether there's a window for you to watch.

You don't hand-write any of this. You describe the path, and the agent writes and runs the test for you.

The robot reviewer on every commit

A commit is a save-point in your project's history (see the tools guide). Every time you push one up to GitHub, you can have robots check it automatically before it becomes part of the live app. There are two kinds, and they work well together.

Kind 1: your own checks, run automatically (CI)

“Continuous integration” is a plain idea behind a fancy name: GitHub Actions re-runs your lint, your type-check, and your Playwright tests on every push, on GitHub's servers, headless. If anything fails, the commit gets a red ✗ and you know before it ships. You set it up once (or ask your agent to), then forget it exists until it saves you.

Kind 2: an AI that reads the change like a colleague

These reviewers read your change the way a careful senior teammate would, and leave plain-English comments on the exact lines they're worried about: “this doesn't handle the empty case,” or “this could expose student emails.” A 2026 snapshot of the common ones:

The earliest catch: pre-commit hooks

A pre-commit hook (tools like Husky set these up) runs your lint and formatting the instant you try to commit, on your own machine, so broken code never even leaves your laptop. Optional, but your agent can add it in a minute. Better to catch a typo at your desk than after it's live on the internet.

Claude Code & Codex, out of the box

Your coding agent is already a tester, if you ask it to be. Both Claude Code and Codex will, right out of the box, write tests, run them, read the failures, and fix the code, looping on their own until things pass. They'll run your lint and type-check and clean up what they broke. Claude Code even ships /review and /security-review commands, plus a code-review plugin that runs several review agents in parallel and surfaces only the high-confidence issues.

1 · A memory file (CLAUDE.md / AGENTS.md)

A plain-text note that lives in your project and tells the agent your standing rules. Claude Code reads CLAUDE.md every session, and Codex reads AGENTS.md the same way (that file also works across many other tools). Put your build, lint, and test commands in it, plus one blunt instruction:

This is the most useful habit in the guide. It costs five minutes and turns a fast, sloppy agent into a careful one, every session.

2 · Hooks

Hooks are rules that fire automatically at set moments, with no human in the loop. For example: run the linter before every commit, and reject the commit if the tests fail. Claude Code has the deepest hook system, with a couple dozen points where you can step in, and Codex added its own hooks in 2026. This is how you enforce a rule the agent can't skip, even when it's in a hurry.

3 · The cross-check: one builds, the other reviews

Have one model write the code and a different model review it: the “Claude implements, Codex reviews” pattern. A second, independent model catches the things the author talked itself into. Ready-made plugins automate this loop. When Claude finishes a task, it fires off a Codex review and handles the feedback before you ever see it, so every change gets an independent second opinion.

4 · A Playwright MCP

An MCP is a small connector that gives an agent a new capability. A Playwright MCP lets Claude Code or Codex open a browser and click through your app to check its own work. Instead of guessing whether the button works, it presses the button.

What a strengthened session feels like

Where you're testing: local, preview, live

Before the habit in the next section clicks into place, it helps to know that your app doesn't run in just one place. There are three, and they're not equal. Knowing which one you're looking at is half of testing safely.

Setting up a host like Vercel, wiring it to GitHub, and pointing a domain at it is the whole job of the hosting guide. This is just the testing-shaped view of it: three places your app can run, and the discipline of catching problems in the first two so they never reach the third.

Still test it yourself, often

Every check so far is worth having, and not one of them replaces you opening the app and using it. Automated tests only look for what someone thought to write down. They'll happily confirm the quiz submits and the score saves while staying silent about the questions appearing in the wrong order, the wording that confuses a ninth-grader, or the layout that falls apart on a phone. A green checkmark means “no problem I was told to look for,” not “good.” You're the one who catches the things nobody wrote a test for.

So keep clicking through it by hand, and do it often. The habit that pays off most is a quick human pass around every commit: make a small change, save it, then spend thirty seconds actually using the part you touched. When you check that frequently, a new bug can only have come from the handful of lines you just changed, so it's easy to trace and cheap to fix. Skip it for twenty commits and you're hunting through a week of changes with no idea which one broke things.

This isn't extra work bolted onto the automated checks. It's the other half of the same job: the robots watch the parts you can spell out in advance, and you watch the parts you only recognize once you see them.

A clean starter setup

You don't need the whole ladder on day one. This order leaves you covered without turning testing into a second job.

• Let your builder or template give you TypeScript, ESLint, and Prettier, and don't turn them off to make a warning go away.
• Add a CLAUDE.md (or AGENTS.md) with your three rules: lint, types, and tests must pass before “done.”
• When real users arrive, ask your agent for one Playwright test on the main path, the happy path first.
• Turn on one free AI reviewer on GitHub (Copilot review or CodeRabbit). One is plenty to start.
• Let GitHub Actions run your checks on every push. Green means safe to share.
• Let your host hand every branch a preview URL (Vercel and Netlify do this on their own), and click through that link before you merge to the live site.
• Still click through it yourself, around every commit, not just before a class sees it. Robots miss the human stuff.

You don't need to become a testing expert. You need to know these nets exist, switch on the cheap ones today, and tell your AI to stop pretending it's finished until everything's green.