Claude, ChatGPT or Codex · Practical walkthrough

Check an AI-built form with missing and awkward inputs

The AI-built request form works perfectly with the tidy example. Then someone types 1.5 into Quantity, or a row of spaces into Owner, and it says thank you.

Task by Task7 min read + practice

What you'll make

a small local form with clear field messages, plus a list of awkward test cases you wrote yourself and the result of running each one.

What you'll need

the form’s business rules written down, a tool that can build and preview a small web page (Claude with artifacts, the ChatGPT desktop app, or Codex), and made-up test values. About 20 minutes.

Example result.

Case	You expected	The form did
Owner A17, quantity 1	Accept	Accepted
Quantity 20	Accept	Accepted
Quantity 1.5	Reject	Rejected: “Quantity must be a whole number from 1 to 20”
Owner is only spaces	Reject	Rejected: “Enter an owner ID”

1. Write the rules and the cases before the build

List each field with its rule: what’s required, the allowed range, whether a number must be whole, and any length limit. Then write the cases yourself, before the AI writes any code. For each rule, include one value just inside it and one just outside: for a quantity from 1 to 20, that’s 1, 20, 0 and 21, plus 1.5 and a blank.

Paste the rules and your cases into the prompt. In Claude, the form opens as an artifact beside the chat. In the ChatGPT desktop app, a generated .html file can open as an interactive preview. In Codex, ask for a single HTML file and open it in your browser.

Build a single-page local form that applies only these rules: [rules].
Use readable labels and a specific error message beside each field.
Don't send the data anywhere; a valid entry just shows a confirmation on the page.
Here are my test cases with the result I expect for each: [cases].
Don't change my expected results, and don't write tests that only repeat what your code already does.
Tell me which cases you actually ran.

[rules] is your field list; [cases] is your own list of inputs and the result you expect.

Why this works: cases written in advance describe the business rule. Cases the AI writes after the code tend to describe the code, mistakes included.

What you should see: a working form in the preview and a short report listing each of your cases.

2. Run the cases yourself

Don’t stop at the AI’s report. Type each case into the form and note what happens. Check that the error names the field and says how to fix it. Try it with the keyboard as well as the mouse: a submit button that greys out with no message leaves people guessing.

For each of my test cases, show the expected result, what the form actually did
and the rule responsible. List any case you didn't run.
Don't describe a case as passing unless you ran it.

Why this works: the comparison table makes a mismatch impossible to skim past, and “list any case you didn’t run” stops a blanket “all tests pass”.

What you should see: one row per case. Every “expected” and “did” pair should match your own run.

Check the result

Every case you wrote appears in the report, with the same expected result you gave.
Your own run in the preview matches the AI’s report for each case.
Each error message names the field and the fix, not just “Invalid input”.
Nothing was filled in for the user: a blank owner is rejected, not replaced with a default.

The usual failure: the form accepts a value it should reject, and the AI’s tests agree with it. The test was written to match the code, so it “passes”. Spot it by comparing the AI’s expected results with your list: if any expected result has quietly changed, that’s the bug.

Case [case] with [input] was [accepted/rejected], but my rule says [rule].
Fix that validation and its field message without adding new restrictions.
Rerun the failed case, the nearest valid case and the exact limit, and show all three results.

[case] and [input] are the failed case; [accepted/rejected] is what happened; [rule] is the rule as you wrote it.

Worked example: an equipment request form

Fictional example. A team asks AI for a quick form to request loan laptops.

Owner ID: required, can't be blank or only spaces (example: A17)
Quantity: whole number from 1 to 20
Note: optional, at most 120 characters
Cases: A17 + 1 accept · quantity 20 accept · 0 reject · 21 reject
       1.5 reject · owner "   " reject · 121-character note reject

First report (wrong): “All 7 cases pass.” Typing 1.5 into the preview shows the form accepting it. The AI’s own test list says “quantity 1.5: accept”, because its number field allowed decimals and the test was written to match.

Repair: the repair prompt above, with case “quantity 1.5”, input 1.5, accepted, and rule “whole number from 1 to 20”.

Repaired report: 1.5 rejected with “Quantity must be a whole number from 1 to 20”; 1 and 20 accepted; 21 rejected.

The AI didn’t lie. It tested its own code, and its code had the bug.
Writing the cases first is what exposed it: “1.5 reject” was on your list before any code existed.
The over-long note is rejected, not quietly cut to 120 characters. A form should ask for a shorter note, not edit one.

Try it

Run the awkward cases

Load a case, predict the result, then check it. Try a CSV of your own made-up rows too.

Write the expected result before you check. A test that changes its expectation to match the code isn't a test.

The example in text

Owner ID required, not blank or only spaces
Quantity a whole number from 1 to 20
Note optional, at most 120 characters
IDs unique when checking a file

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Check a file instead of a form

The same rules work on a CSV export. For a one-off, upload the file to your work AI account and ask it to list every row that breaks the rules, with the row number and reason, then check three of those rows yourself. For a recurring import, ask for a small offline checker. Either way, two things trip up files that forms never see: a name such as “Smith, Jones & Co” contains a comma, so the file must be read as proper CSV rather than split on every comma; and two rows can share an ID even when each row is valid on its own.

Check this CSV against these rules: [rules]. Read quoted commas correctly.
List every row that breaks a rule, with row number, ID, the value and the rule.
Flag duplicate IDs. Don't fix, fill in or remove any row; report problems only.

Say how to count characters

“120 characters” is clear for plain text. If emoji or accented names matter, tell the AI how to count them and include one such case in your list.

Keep browser and server checks separate

Checks in the form give people quick feedback, but anyone can bypass a web page. If the form later sends data to a real system, that system needs its own validation, built and reviewed by the team that owns it. MDN explains the difference. See also clickable prototypes.