How to Test AI-Generated Code Before You Ship

You ask a coding agent to add project archiving. It adds a button, updates the route, and reports that the checks pass.

The useful next question is specific: can an authorized user archive the intended project, and does the rest of the application handle that state correctly?

AI-generated code deserves the same review as any other change. The practical challenge for a founder is keeping the expected behavior independent of the implementation that just appeared. A plausible implementation can make a missing requirement easy to overlook.

This guide uses a fictional archive feature to show how to turn a coding request into a reviewable test plan.

Write the acceptance conditions before reviewing the code

Start with product behavior. For this example, decide that:

• An owner or editor can archive a project in their workspace.
• Archiving removes it from the active list without deleting its data.
• The project remains visible in the archived view after a reload.
• A viewer cannot archive it.
• A project in another workspace cannot be changed through this account.
• Restoring the project returns it to the active list with its existing content.

These are example requirements, not universal archive semantics. Your product might allow only owners to archive or might offer no restore operation. Resolve those choices explicitly.

If the coding prompt said only “add archiving,” the implementation may have selected a policy for you. Review that policy before treating its behavior as the definition of success.

Ask for a change map

Before testing, review what changed. Identify the interface, server operation, data model, permission checks, shared components, and background jobs involved.

A useful review prompt is:

Compare this change with the archive acceptance conditions.
List the files and product behaviors it affects.
Identify assumptions, missing checks, and behavior you could not verify.
Keep the agreed acceptance conditions unchanged.

Inspect the resulting diff yourself. Pay particular attention to broad permission changes, removed validation, ignored errors, and modifications outside the requested feature. A summary from the author is a helpful index into the review; it is not evidence that every statement is correct.

If a database change is required, establish how existing records behave and how the deployment will apply it. A successful browser run against a freshly created record can miss an existing-data problem.

Run the checks closest to the change

Run the repository’s formatter, linter, and type checker, followed by the focused tests the project already uses. Read the failures before changing either implementation or assertions.

For archiving, service-level checks can verify workspace scoping, allowed roles, and state transitions. A component check can cover the confirmation dialog and error display. A browser journey connects those pieces through the actual interface.

A successful type check cannot establish that an archive operation preserves content. A browser check also cannot exhaust every concurrent update or storage failure. Choose checks according to what each layer can observe.

Verify the feature through the browser

Prepare a dedicated editor account and a disposable project containing a recognizable item. Record the starting project identity and workspace.

Use a separate viewer account to verify the denied action. For server authorization, add a direct service or integration check that a forbidden request is rejected without changing the record. Hiding the archive button only tests the interface.

Playwright’s best practices recommend testing what a user can observe. For this example, that means locating the same project in its resulting state rather than asserting only that an event handler ran.

Add the uncomfortable cases

Ask what happens when a valid action is interrupted or repeated. In a controlled test environment, check an archive request that fails and confirm the interface does not claim completion or lose the existing data.

Also review product-specific edge cases:

• A second tab still has the project open when its state changes.
• An archived project is reached through an old bookmark.
• An operation is submitted twice while the first request is pending.
• The account’s permissions change before the operation completes.

Select cases based on the code paths involved. You do not need to add every possible browser scenario to every release, but shared state and authorization deserve deliberate attention.

Retest nearby behavior

An archive filter may affect search, counts, exports, or project selection menus. A shared confirmation component may affect deletion. A changed permission helper may affect unrelated writes.

Use the change map to choose those checks. Keep one or two previously working journeys in the review so the new feature does not receive all the attention. The change-based regression guide provides a worksheet for that decision.

When a check fails, preserve the original expectation unless the product requirement intentionally changes. Weakening the assertion until the suite passes can conceal the exact regression you needed to catch.

Keep a compact evidence record

Before shipping, record the reviewed requirement, version, environment, account role, checks run, and any remaining gaps. Separate “implemented,” “statically checked,” and “observed working” in the release note.

In HiTest, you can turn the reviewed browser journey into actions with expected results. Use Explore to suggest additional cases when useful, then review the drafts against the original requirement. Provider behavior, service permissions, and database correctness still need their appropriate checks.

The goal is to make the finished change assessable: someone can see what the feature promised, what ran, and which result established that the promise held.