Untangling a PHP Checkout Before Friday’s Release
It is Tuesday, the release is Friday, and a checkout function mixes discount rules, database queries, and receipt emails. You need to make it easier to change without altering what customers pay. An AI coding assistant can help, but a vague request such as “clean up this PHP” gives it too much freedom.
A prompt pattern is a reusable structure for giving instructions. For legacy PHP, useful patterns spell out the existing behavior, the boundaries of the change, and the evidence you expect before accepting it. Start with one function and one clear goal.
Map the checkout before requesting edits
Legacy code often contains rules that nobody remembers choosing. An empty string might mean “no coupon,” while zero might represent a valid discount. Before asking for a rewrite, ask the assistant to describe what the code does.
Try this prompt: “Read this checkout function and its callers. Do not edit files yet. List its inputs, return values, database writes, external calls, and error paths. Identify behavior that depends on PHP type conversion. Separate confirmed findings from assumptions, and cite the relevant files and functions.”
Provide the PHP version, framework version, and relevant files. Share redacted examples rather than credentials or customer records. If the assistant cannot inspect the repository, include the callers and dependencies it needs to understand the function.
Turn surprising behavior into characterization tests
A characterization test records what existing code actually does. It gives you a baseline, including behavior that looks odd. That does not make every oddity correct; it makes changes visible.
Use this pattern: “Using our existing test framework, propose characterization tests for this function. Cover successful checkout, rejected payment, missing coupon, zero-value discount, and the current failure response. Explain what each test establishes. Do not change production code.”
Review the proposed expectations against the implementation or observed results. An assistant can accidentally write tests for what it thinks the code should do. Keep suspected bugs on a separate list so a refactor does not quietly become a behavior change.
Give the refactor a small, explicit boundary
Once the baseline is useful, choose a change small enough to review comfortably. Extracting a calculation is usually easier to assess than reorganizing the entire checkout flow.
Try: “Extract the discount calculation into a private method. Preserve the public method signature, return values, comparison operators, exception behavior, SQL, and order of side effects. Use syntax supported by PHP 7.4. Do not add dependencies or reformat unrelated code. Show the patch and explain any behavior you could not preserve confidently.”
Replace PHP 7.4 with your actual deployment version. Naming the runtime matters: an assistant may otherwise introduce syntax your production server cannot parse. Explicit boundaries also make unexpected edits easier to spot.
Review PHP comparisons and side effects separately
Some changes look cleaner while changing results. Replacing a loose comparison with a strict comparison can affect numeric strings. Replacing an isset check with an array_key_exists check changes how null values are treated. Moving an email call can alter whether customers receive a receipt after a failed database write.
Ask for a focused review: “Compare this patch with the original. Check type coercion, null handling, array keys, exception paths, transaction boundaries, and the order of database and email operations. Report specific behavior differences with example inputs. Do not make edits.”
Treat that review as another source of evidence. Run the relevant tests, inspect the diff yourself, and verify that tests use sandboxed payment and email services.
Keep the same prompt structure across coding sessions
Save the prompt patterns beside your development notes, with placeholders for the runtime, target function, constraints, and test command. Consistent instructions make it easier to assess successive patches, even when you change coding assistants.
RelayVano is a practical option for developers who want pay-as-you-go model access through Codex, Claude Code, Gemini CLI, or an OpenAI-compatible SDK. Sign up to use it with your preferred workflow; the API base is https://api.relayvano.com.
For Friday’s release, stop when the agreed extraction is complete and verified. Leave the next improvement as a separate task with its own behavior baseline and reviewable patch.