How to Test AI-Written Code Before You Ship Your SaaS

A demo can show a customer opening their own records. It can't prove they can't open someone else's.

That gap matters when you build software by telling AI what to do. You can describe a feature, watch it work, and still leave the product's most important rules unchecked.

Vibe coding makes that distinction easy to miss. The useful question isn't whether AI wrote your app. It's what you've done to check the result before a customer depends on it.

What is the meaning of vibe coding?

Vibe coding means using plain-language instructions to get AI to write and change software. You describe what you want, run the result, then ask for changes.

The Cambridge English Dictionary defines it as coding with AI's help, using natural language to give instructions. That broad definition covers a conversational way of building software. Instead of writing every line yourself, you direct a tool that writes code for you.

For example, you might ask an AI assistant to build a page where customers can save reports. You inspect the page, notice the save button doesn't work, and describe the problem. The assistant changes the code. You run it again.

The phrase also has a narrower meaning. As MIT Technology Review reports, Andrej Karpathy coined it in February 2025. He described a style of building where you could “forget that the code even exists.”

Those meanings overlap, but they don't describe the same level of care. Using plain language to request code doesn't tell you whether anyone inspected that code afterward.

Someone might use AI to make a disposable personal tool and accept whatever appears to work. You might use the same tools to build a paid app, then review every change and test its behavior.

Both can get called vibe coding. Only the second includes an explicit check before release.

For a SaaS you sell, use the broad definition to explain how you build. Be much more precise about how you decide the software is ready. The name of the workflow doesn't establish whether the result deserves a customer's trust.

How does vibe coding work?

A vibe coding workflow repeats a simple loop: describe a change, let AI write code, run it, and give feedback. Google Cloud describes the builder's role as guiding AI to generate, refine, and debug an application through conversation.

You still make decisions throughout that loop. The AI needs a goal, and you need a way to judge whether it reached that goal.

For a saved-report feature, the loop could look like this:

1. Describe who can create a report and what it should contain.
2. Ask the assistant to build the smallest working version.
3. Run the app with test data and inspect the result.
4. Describe errors or missing behavior, then review the next change.

That explains how the code gets written. It doesn't yet explain how you check it.

“Let customers save reports” leaves important questions unanswered. Can customers open reports from another account? What happens when someone deletes a report? Does an expired subscription still allow paid actions?

You don't need to answer every possible question before trying an idea. But you should answer the questions that define what your shipped product allows.

Keep those rules beside the feature request. “Customers can save reports” describes the feature. “Customers can only read and change reports belonging to their account” describes a boundary the feature must respect.

Then use both when you judge the generated code. Ask whether the feature works and whether the forbidden actions fail.

That makes your feedback more useful than “looks good” or “fix the bug.” You're giving the assistant a clear target while keeping the final decision yourself. A convincing screen is evidence that one route worked, not proof that every important rule held.

Reviewing the code remains your job

Google Cloud separates exploratory “pure” vibe coding from responsible AI-assisted development. In the latter, you review, test, and understand the generated code, and take ownership of the result.

That distinction matters more than which label you put on your workflow. Asking AI to write a function doesn't stop you from checking it. Accepting a working demo without understanding the change does.

Karpathy's original description makes the appeal clear. In the account quoted by MIT Technology Review, he describes seeing, saying, running, and copying things until they mostly work. That's a description of an experience, not a promise that the output suits every use.

If you're selling software, set a stricter standard than “mostly works.” Before accepting an AI-written change, make yourself answer:

• What behavior did the code change?
• Which users and records can it affect?
• Which product rule could this change break?
• What test would catch that break?

You don't have to pretend you understand a change because you requested it. Ask the assistant to explain the relevant code. Follow the path from the user's request to the stored data or paid action.

If you still can't explain who gets access and why, pause the release. Get help reviewing that part rather than asking for a more confident summary.

AI can write the change. You still decide what evidence makes it safe enough to ship.

For a small product, keep that evidence concrete. A readable change, a clearly stated rule, and a test that checks it give you something to inspect. “The assistant says it's fixed” leaves the important question unanswered.

Two test accounts can expose broken access rules

Use two test accounts to check whether your SaaS keeps one customer's records away from another. That's a practical way to apply the review-and-test responsibility described by Google Cloud, rather than a test procedure supplied by its article.

Call the accounts A and B. Create a record under A, then sign in as B. Your rule is simple: B must not read, change, or delete A's record.

Test those actions separately:

1. Try opening A's record while signed in as B.
2. Try changing A's record while signed in as B.
3. Try deleting A's record while signed in as B.

Don't stop at checking whether the interface hides the buttons. Try the request behind the button using the other account's record identifier. If you don't know how, ask your assistant to show you the request and help you build a repeatable test.

Check the stored result as well as the response. After B tries to change or delete A's record, sign back in as A. Confirm the record remains unchanged.

Also check that B can still use B's own records. A test that rejects every request wouldn't prove your access rules work correctly.

Write the expected behavior before running the checks. “The request fails” is incomplete if the record changes anyway. Specify that the other account gets no protected data and causes no change.

Start with the records that matter most to your product. Use test data, not customer data, and run destructive checks somewhere they can't harm paying users.

A successful create-and-save demo won't answer these questions. You have to deliberately attempt the actions your product promises to forbid. Keep those attempts as tests so the next generated change faces the same checks.

Billing tests must cover repeated events and lost access

Test what your SaaS does when a payment event arrives twice and when a subscription ends. These are proposed release checks for a paid product, grounded in Google Cloud's distinction between generating code and taking responsibility for it.

Start by writing your billing rules in plain language. Don't ask the assistant to decide your commercial policy from whatever code already exists.

Your rules might say:

• Processing the same payment event twice must not grant a benefit twice.
• A canceled subscription keeps access until its stated end date.
• After paid access ends, the account cannot perform paid actions.

Those are examples, not universal billing rules. Your product may stop access immediately or keep it until the paid period ends. Choose the intended behavior first, then test against it.

In your billing provider's test environment, replay a payment webhook: the message that tells your app a payment event happened. Check whether the second delivery changes anything it shouldn't. If a payment adds credits, inspect the balance after both deliveries.

Then cancel a test subscription. Check the account before and after the point when paid access should end. Don't treat a canceled badge on a settings page as enough evidence.

Attempt the paid action itself. If your app charges for exports, try making an export. If you charge for running a report, try running one. Test the request behind the screen as well as the screen.

Use a controlled way to test time-dependent behavior rather than waiting for a real customer to reach the end date.

The goal is a checkable answer: the app grants exactly the access your stated policy allows. A working checkout only proves that someone could buy. It doesn't settle what happens afterward.

How should you ask AI to write the tests?

Give AI your product's rules before showing it the code you want checked. Treat that as a way to get a separate set of expectations, not a guarantee that AI will find every mistake.

Google Cloud says responsible AI-assisted development includes reviewing, testing, and understanding generated code. A useful way to carry out that responsibility is to separate what should happen from how the current code happens to work.

Start with a short prompt such as:

Write test cases from these product rules. Don't assume the current code is correct. Account A must never read, change, or delete Account B's private reports. Each account must still be able to manage its own reports. For every test, state the expected response and the expected stored data afterward.

Review those cases yourself before asking the assistant to connect them to your app.

Check whether the proposed tests include both allowed and forbidden actions. Look for a clear expected result. Reject tests that merely repeat a function's output without checking a product rule.

Then provide the relevant code and ask the assistant to implement the agreed tests. If the app makes a test difficult to write, ask why. Don't quietly weaken the expected behavior just to get a passing result.

You can also ask the assistant to explain what each test would catch. A test named “checks permissions” tells you less than one that attempts to delete another account's report and checks that it still exists.

The order matters because you want to judge the code against your rules. You don't want the code to become the source of those rules.

You still need to inspect the tests. Another AI-generated file isn't independent proof merely because its filename ends in “test.”

Keep rule checks in every relevant release

Rerun the checks for account access and billing whenever a change could affect those rules. Google Cloud places testing and ownership inside responsible AI-assisted development; neither ends when the first version launches.

For a solo builder, the goal is a release routine you can actually follow. Avoid writing a long checklist that you'll ignore when you're tired and want to ship.

Keep a small set of checks tied to promises your product makes:

1. An account cannot read, change, or delete another account's private records.
2. Repeating the same payment event cannot repeat a one-time benefit.
3. An account loses paid abilities when your stated billing policy says it should.
4. Allowed users can still complete those actions successfully.

Automate the repeatable checks where you can. Keep any remaining manual steps specific enough that you don't have to reconstruct them from memory.

When a check fails, inspect both the generated change and the test. Don't ask the assistant to “make everything green” without preserving the expected behavior. A passing result is useful only if the test still checks the rule you care about.

Keep changes small enough to review. If one request produces changes across access control, billing, and unrelated screens, split the work before accepting it. You want to understand what you're approving.

A finished demo proves that a route through the product worked. Your release checks must also prove that forbidden routes failed.

Before your next AI-written feature ships, create the second test account. Try opening, changing, and deleting the first account's record. Write down what should happen, check what actually happens, and keep that test for the next release.