Skip to main content
Test/Chapter 48 · Why Test

Why Test When AI Writes the Code

Share

Share this page

Pass it to someone who needs it.

The agent tells you the feature works, and it does, right up until a real user does the one thing you never thought to try. You cannot click through every path by hand on every change, and when the agent rewrites something next week, you will not remember what to re-check. This chapter gives you the net that catches a break before a user does.

7.1.1Tests are your safety net

A test is a small piece of code that runs part of your app and checks it did the right thing, without you clicking anything. It matters most precisely because the agent writes the code: a test is how both of you know a new change did not quietly break what already worked.

You cannot re-check everything by hand, and you will not want to. A machine re-checks every path on every change and never gets bored.

7.1.2Cover the critical paths first

Do not try to test everything. Test what would hurt most if it broke. The critical paths are the few flows your app exists for: a user logs in, saves their work, pays.

Cover those first and you have protected the parts that lose customers when they fail. A checkout flow earns a test long before a settings toggle does.

7.1.3Let the agent write and run them

You do not hand-write these. You tell the agent the behavior to protect and it writes the test, then runs it on every change. A quick one for a single function, an end-to-end test (with a tool like Playwright) to drive the whole flow like a user:

test("a user can log in", async ({ page }) => {
  await page.goto("/login");
  await page.fill("#email", "[email protected]");
  await page.fill("#password", "secret");
  await page.click("text=Log in");
  await expect(page).toHaveURL("/dashboard");
});

A unit runner like Vitest covers the smaller pieces. Add the test run to the checks the agent must pass before it says done.

7.1.4Green before you ship

Once the tests exist, they catch a regression the moment it appears: the suite was green, your last change turned it red, and now you know exactly what broke. That is what lets you keep changing a live app without holding your breath.

Tests are not the whole job. Before you ship, walk the real flow yourself once, on a phone, as a new user would, because some things (a confusing label, a broken layout) only a human notices.

This prompt sets up the safety net for your app:

Act as a senior engineer adding tests to my app.
Pick the few critical paths that would hurt most if
they broke, and write a test for each: end-to-end for
whole flows, unit tests for tricky logic. Then add the
test run to the checks you do before calling any task
done, and tell me which flows you covered and why.

The critical flows to test:

Do this now: paste the prompt, let your agent cover your critical paths, and make a green test run part of every change from here on.

Discussion

Questions, ideas, and feedback on this chapter.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

ExploreBook a call
Companion RepoContribute
Support me

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish. Copyright & license