AI review checklist

• Are clickable things real buttons and links? A clickable div does not work with a keyboard or screen reader the way a button does.
• Are the Git flags and SQL functions real too? Made-up options appear outside web pages as well, so check them in the official docs.
• Are you asking for one small piece at a time? Small answers are easier to read and test, and mistakes have fewer places to hide.
• Can you use the whole thing with only a keyboard? Press Tab through the page and check every control can be reached, seen and used.
• Could this code be copied from someone else's work? Ask where longer chunks came from and check the licence before you publish them.
• Could visitors run up costs or hit rate limits? Each request costs money, so limit input size and disable the button while waiting.
• Did it change things you never asked it to change? Look for removed or rewritten parts of your existing work before you accept the reply.
• Did it copy your example too closely or invent items? Look for placeholder text and made-up entries that came from the example, not your data.
• Did the fix leave behind debugging code? Remove stray console logs and test lines before you call the work finished.
• Did the reply answer what you actually asked? Compare it with your request point by point, because answers often drift off target.
• Did the reply keep every limit you set? Check each limit against the answer, because a reply can quietly break one of them.
• Did you ask for the smallest possible fix? A small change is easy to review, while a full rewrite can bring in new bugs.
• Did you commit before letting it change your files? A commit gives you a safe point to return to if the changes go wrong.
• Did you fix one error before moving to the next? Solving errors one at a time shows whether each fix worked or caused a new one.
• Did you paste someone else's personal data? Names, emails and other details about people should be removed or replaced before asking.
• Did you paste the code it needs to see? Without your real code, the assistant guesses at class names and structure that may not exist.
• Did you remove keys and passwords before pasting? Text you paste into a chat may be stored, so swap secrets for clear placeholders.
• Did you say what you expected and what happened? Expected versus actual gives the assistant the gap it needs to find the real cause.
• Did you say what you want the result to do? A clear goal tells the assistant what success looks like, so the answer can aim at it.
• Did you set limits, such as plain HTML and CSS? Limits stop the reply from adding libraries, frameworks or extra size you never wanted.
• Did you share the exact error message? Copy the full message from the console so the assistant can see what really failed.
• Did your follow-up repeat the key details? A long chat can lose earlier details, so restate what matters or start a fresh chat.
• Do you understand every line it gave you? Ask it to explain anything unclear, then check the explanation against what the code does.
• Does copied code need a credit comment? Many permissive licences ask you to keep the notice, so add a short credit with the source.
• Does each form field have a real label? Placeholders vanish when you type, so every input needs a label tied to it.
• Does every CSS property exist? Assistants sometimes invent properties, and browsers skip them silently, so check a reference.
• Does every image have sensible alt text? Screen reader users rely on alt text, and assistants often leave it out or make it vague.
• Does it load a script from an address you don't know? An outside script can change your page at any time, so only load ones you trust.
• Does it put visitor input into innerHTML? Untrusted text in innerHTML can run code, so show it with textContent instead.
• Does it sound sure only because it always does? The assistant predicts likely text, so a confident tone tells you nothing about accuracy.
• Does it suggest a Git command that deletes work? Commands that force, reset or clean can wipe changes, so understand them before running.
• Does it tell you to turn off a security setting? Switching off a safety check hides the symptom, so ask for a fix that keeps it on.
• Does it use eval or build SQL from visitor input? Both let a visitor's text be run as code, which is a common way sites get attacked.
• Does the fix hide the error instead of solving it? Wrapping code to silence an error leaves the real problem in place for later.
• Does the page show loading and error messages? Visitors need to know a reply is coming, and what happened if the request fails.
• Does the page talk to your server, not the service? The browser should send questions to your own address, which then calls the service.
• Has a leaked key been replaced with a new one? Deleting a shared key is not enough, so create a new one and switch off the old one.
• Have you checked git diff after the change? The diff shows every added and removed line, including ones the assistant dropped.
• Have you read the whole reply line by line? Code that seems to work can still hide wrong content, odd lines or leftover junk.
• Have you tested it in the browser, not just read it? Click, type and resize in the preview, and watch the console for errors.
• Is every HTML attribute and JavaScript method real? A believable name is not proof, so look each unfamiliar one up before you rely on it.
• Is the code you pasted still up to date? If you changed the file since pasting it, the reply may be built on old code.
• Is the service key kept on your server, not the page? Anyone can read page code, so the key belongs in server settings that visitors never see.
• Is the text colour contrast strong enough? Pale text on a pale background is hard to read, so test the pair with a contrast checker.
• Is there still a visible focus outline? Removing outlines hides where keyboard users are, so keep or restyle focus styles.
• Is this a job worth asking for at all? A one-word fix is often faster by hand than writing a request and checking the reply.
• Would a short example make your request clearer? One good example shows the shape you want far better than a long description.