Before AI changes your legacy app, capture the rules it must preserve

Agree what the existing feature must preserve

Consider a hypothetical order-entry feature. Active accounts can place orders; accounts on credit hold cannot. The rule matters in both the screen and the saved result.

Ask someone who owns that process to review a short set of examples:

• An active account places a valid order and receives an order reference
• A held account receives the agreed explanation and creates no order
• An invalid order is rejected without a partial saved record

The team implements the checks; the business owner decides required behavior and acceptable differences.

Recording existing behavior does not make a legacy bug correct. Mark a discrepancy explicitly: preserve an approved rule, fix an acknowledged defect, or investigate an unresolved requirement. Do not quietly turn every observed result into a permanent requirement.

Check the setup before estimating the harness

Can the team reproduce those scenarios without altering real orders? Before estimating the work, establish whether it can:

• Isolate and reset synthetic accounts and order data
• Observe saved results through a reliable lookup or integration test
• Keep warehouse messages, payments, and other effects inside safe test boundaries

A small scenario set can require substantial preparation. If these capabilities are missing, estimate that enabling work before committing to a harness.

Playwright recommends isolated tests and controlled data. Its browser isolation does not reset the application's database; the team must arrange that separately. Playwright best practices

Give each test its own order reference. Document substitutes too: checking a queued warehouse message does not establish that a real warehouse received it.

Check the business result, including what must not happen

A visible error is incomplete evidence if the application still saves the rejected order.

The following Playwright API test checks both outcomes. It assumes a seeded held account, a configured test-environment base URL, any required test authentication, and an order lookup that returns matching saved records. The endpoint, response code, and message are illustrative contracts to adapt to the application.

const { randomUUID } = require('node:crypto');
const { test, expect } = require('@playwright/test');

test('credit hold prevents a saved order', async ({ request }) => {
  const reference = `baseline-${randomUUID()}`;
  const result = await request.post('/api/orders', {
    data: { account: 'held-account', reference }
  });
  expect(result.status()).toBe(409);
  expect(await result.json()).toEqual({
    message: 'Account is on credit hold'
  });

  const saved = await request.get('/api/orders', { params: { reference } });
  expect(saved.ok()).toBe(true);
  expect(await saved.json()).toEqual([]);
});

Playwright supports API checks alongside browser tests, including checking server-side results. Playwright API testing

The empty result matters as much as the error. This example assumes an immediately consistent lookup. If the real application creates records asynchronously, check the relevant queue or processing outcome with an agreed completion condition; an immediate empty read could be misleading.

Pair the rejection test with an active-account acceptance test. Otherwise, an application that rejects every order could satisfy the rejection scenario. Add browser checks for the visible explanation and entry process where those are part of the change.

Keep the baseline when the implementation changes

Run the scenarios against the existing version first. Resolve unexplained failures before accepting the baseline. Save the application version, test revision, fixture setup, and results together.

Then run the same business expectations against the AI-assisted change. Environment configuration or browser selectors may need adapting. The expected account rules should remain unchanged unless the business has approved a different rule. Playwright projects can apply a shared suite to different configurations. Playwright projects

When a test fails, investigate the difference. Updating the expectation until the run passes removes the comparison you created. A deliberate rule change needs its own reviewed acceptance examples.

What is enough to start?

For the chosen feature, look for:

• Business-reviewed success and exception scenarios
• Repeatable test data and a passing legacy baseline
• Checks of saved outcomes, not just messages
• The same approved expectations applied after the change
• Named gaps and a person responsible for the release decision

A Playwright API-only run against a synthetic in-memory order service checked the same rejection sequence: the held account returned 409 and the order lookup was empty. A companion active-account test created one record. Separate offline rule checks detected save-despite-hold and block-all faults. No real legacy application, database, browser interface, or production integration was validated.

This evidence supports a decision about the agreed order scenarios. Security, performance, recovery, and other integrations need separate checks. After each change, the team can explain which business behaviors stayed the same and which differences need a decision.